数据中心 / RAS 算法 / 基价模型
数据中心 / RAS / 基价模型是澜思房地产数据产品体系的底层价格中台项目。它把新房、二手房、挂牌、楼盘、板块、区域、户型图和恒星楼盘等数据组织成可计算、可校验、可复用的价格体系，为一房一万、挂牌查价、城市地图、红盘系统、科东预估等产品提供稳定的数据底座。
项目定位
这个项目是澜思房地产数据产品背后的 价格与指标中台，服务多条前端产品线。
房地产数据产品表面上展示的是楼盘、地图、价格、趋势、筛选和报表，真正决定产品可信度的是底层数据：价格从哪里来，口径是否统一，缺失数据如何补全，异常价格如何识别，不同时间、不同区域、不同楼盘之间是否可以比较。
RAS 和基价模型解决的核心问题，就是把分散的房地产价格信号转成一套可长期复用的基准体系。它既服务 C 端用户对房价的理解，也服务 B 端客户对楼盘、板块、城市和项目价值的判断。
项目背景
房地产价格数据天然复杂。新房、二手房、挂牌价、成交价、评估价、安居客价格、链家小区价格、五大中介挂牌均值等数据都能反映市场，但每一种数据都有自己的局限。
| 数据问题 | 具体表现 | 对产品的影响 |
|---|---|---|
| 来源分散 | 新房、二手房、挂牌、外部平台、内部成交和评估数据并存 | 同一个楼盘可能出现多套价格口径 |
| 覆盖不均 | 有些楼盘成交活跃，有些楼盘长期缺少成交案例 | 不能只依赖真实成交，否则大量楼盘无法计算 |
| 波动异常 | 单月成交、挂牌结构和低价房源进入会造成价格跳动 | 用户和客户会质疑价格可信度 |
| 时间不可比 | 不同月份、不同市场阶段价格差异明显 | 历史复盘、趋势判断和估值都需要统一时间口径 |
| 对象关系复杂 | 区域、板块、楼盘、小区、房屋、户型、室号之间有多层关系 | 模型结果需要落到具体产品对象上，才能被使用 |
如果没有统一的价格中台，一房一万无法稳定向购房者解释楼盘价格，挂牌查价无法给出可参考的二手房价格，CityMap 也难以让开发商基于同一套口径做城市、板块和楼盘比较。
项目目标
项目目标可以拆成三层。
第一层是 建立价格基准：通过 RAS、楼盘基价、区域指数、板块指数和房屋基价，形成多层级价格指标体系。
第二层是 提升覆盖和稳定性：对有案例楼盘建立价格计算规则，对无案例楼盘通过空间距离、竣工年代、学区、动迁、板块和区域等相似关系补全。
第三层是 让模型结果产品化：把复杂算法逻辑转成业务能理解、产品能展示、客户能解释的价格结果和数据说明。
对应到建设内容，核心目标包括：
- 建立从全市、区域、板块、板块同类型到楼盘、房屋的价格链路。
- 将新房、二手房、挂牌等价格来源按规则组织到同一体系中。
- 用异常剔除、涨跌幅限制、样本扩展和历史倒推提升价格稳定性。
- 建立恒星楼盘、板块得分、楼盘评价、户型图等数据资产，作为价格体系的补充支撑。
- 支撑一房一万、挂牌查价、CityMap、红盘系统、科东预估等多条产品线复用。
我的角色
在这个项目中，我承担的是 数据产品 / 产品侧协同角色。算法模型由算法和数据团队主导，我重点负责理解模型逻辑、梳理业务口径、转译产品表达，并推动模型结果进入具体产品场景。
| 工作方向 | 我承担的工作 |
|---|---|
| 业务理解 | 理解新房、二手房、挂牌、楼盘、板块、区域等对象在产品中的使用场景 |
| 口径梳理 | 将价格来源、计算链路、数据限制和异常处理转成业务可沟通的规则说明 |
| 产品转译 | 把 RAS、基价算法、恒星楼盘、板块得分等底层能力组织为产品模块和展示逻辑 |
| 跨团队协同 | 与算法、数据、前后端和业务团队沟通模型边界、字段含义和落地方式 |
| 应用落地 | 推动价格数据在一房一万、挂牌查价、CityMap、红盘系统等产品中被使用和解释 |
这类工作很考验数据产品能力：既要能读懂算法和表格，又要能回到用户场景中判断“这个结果该怎么展示、怎么解释、怎么让业务相信”。
核心价格体系
RAS 和基价模型的核心，是把房地产市场拆成多层级价格对象。价格从城市和区域层面逐步下钻，最终落到楼盘和房屋。
全市指数
-> 区域指数
-> 板块指数
-> 板块同类型指数
-> 楼盘基价
-> 房屋基价这条链路的意义在于：当某个楼盘自身成交不足时，可以用板块、区域和同类型楼盘的信息补足；当某个房屋需要估值时，也可以从楼盘基价出发，再叠加面积、楼层、户型等修正。
| 价格层级 | 解决的问题 | 产品价值 |
|---|---|---|
| 全市指数 | 判断整体市场涨跌趋势 | 支撑市场周期判断和城市级趋势观察 |
| 区域指数 | 判断不同区域价格变化 | 支撑区域对比和板块归因 |
| 板块指数 | 判断板块内部价格走势 | 支撑购房、投资、拿地和竞品分析 |
| 板块同类型指数 | 处理不同物业类型和楼盘类型差异 | 提升同类楼盘比较的公平性 |
| 楼盘基价 | 形成每个楼盘的参考价格 | 支撑楼盘详情、挂牌查价和估值类应用 |
| 房屋基价 | 将楼盘价格进一步落到房屋层面 | 支持室号、面积、楼层等维度的细颗粒判断 |
RAS 计算逻辑
RAS 的基础思路，是先把不同来源的案例价格进行预处理，再按照区域、板块、板块同类型、楼盘和房屋逐层计算。
| 环节 | 关键逻辑 | 数据产品意义 |
|---|---|---|
| 案例获取 | 选取近一个月新房、二手房和挂牌案例，过滤非住宅、极小面积和异常低价案例 | 保证进入模型的数据有基本质量 |
| 价格修正 | 对案例做面积修正、楼层修正和时间修正 | 让不同房源之间具备可比性 |
| 区域指数 | 按新房、二手房、挂牌等来源计算区域价格 | 形成区域层面的市场基准 |
| 板块指数 | 在区域基础上继续下钻到板块 | 支持用户按板块理解市场 |
| 同类型指数 | 按物业类型、楼盘类型做进一步区分 | 避免不同类型产品混在一起比较 |
| 楼盘基价 | 根据近 2-6 个月案例、相似楼盘和权重规则计算 | 把价格结果落到用户真正关心的楼盘 |
| 房屋基价 | 基于楼盘基价叠加面积、楼层等修正 | 为更细颗粒的估值和查询提供基础 |
其中，案例不足是模型中最现实的问题。资料中提到，库内公寓类楼盘量级超过 1.4 万，近 5 个月有新房、二手房或挂牌案例的楼盘约占 85%，但二手成交案例达到一定数量的楼盘比例明显更低。这意味着模型不能只依赖成交数据，必须建立补全和扩展机制。
基价算法 3.0
基价算法 3.0 更强调价格来源优先级、无案例楼盘补全和历史价格倒推。它把不同类型楼盘拆开处理，让计算结果更贴近真实数据条件。
| 楼盘类型 | 有价格案例时的优先级 | 无价格案例时的补全逻辑 |
|---|---|---|
| 二手公寓 | 五大中介挂牌均值、城市房价评估当月、安居客小区当月价格 | 先找 1km 内相似楼盘，再扩展到 2km、同板块、同区域 |
| 二手别墅 | 城市房价评估当月、安居客小区当月价格、五大中介挂牌均值 | 按地理距离、竣工年代、学区、动迁等相似条件补全 |
| 新房 | 新房批次最新价、上月 RAS 基价 | 结合新房批次和历史价格维持连续性 |
相似楼盘的核心判断条件包括 地理位置、竣工年代、学区、动迁、板块和区域。这些变量很产品化，因为它们也是用户和客户判断楼盘价值时最容易理解的因素。
算法 3.0 还增加了稳定性控制：当月价格如果出现超过阈值的异常涨跌，会继承上月价格，避免单月异常案例影响整体价格体系。对于历史数据，则通过样本筛选、异常剔除和插值方法倒推价格。
资料中有一个很重要的目标：倒推 2018.01-2021.12 的二手公寓楼盘历史价格。这个目标让楼盘价格具备时间轴，支撑历史走势、市场复盘和长期分析。
恒星楼盘模型
恒星楼盘是价格体系中的稳定样本池。它的作用类似“锚点”：从大量楼盘中筛出成交更活跃、更具代表性、更适合观察市场变化的楼盘，帮助模型和产品获得更稳定的参照物。
原始资料里可以看到，早期恒星楼盘标准存在不一致的问题，例如有的标准看一年内每月是否有成交，有的标准看区域成交排名，有的标准加入特选小区。这会导致样本覆盖、动迁比例、楼盘年代和板块分布不稳定。
因此，后续模型把恒星楼盘从经验筛选推进到评分模型。
| 模型要素 | 说明 |
|---|---|
| 样本池 | 8881 个楼盘样本 |
| 核心变量 | 成交套数、成交总金额、累计成交月份、动迁标识 |
| 模型方法 | 对变量归一化后建立得分模型，用得分筛选稳定楼盘 |
| 模型 1.0 | 主要使用成交套数、累计成交月份、成交总价 |
| 模型 2.0 | 在 1.0 基础上加入动迁标识，降低样本中动迁房占比 |
资料中模型对比显示，得分模型 2.0 筛选出约 1004 个恒星楼盘，覆盖 112 个板块，动迁房比例从得分模型 1.0 的 27.6% 降到 7.8%。这个结果很能说明模型迭代的价值：筛选目标从数量扩张转向样本稳定性和市场代表性。
板块得分与楼盘评价
价格中台除了计算楼盘价格，还需要支撑板块和楼盘层面的比较。资料中的板块得分模型和楼盘评价体系，说明数据中心不只关心“多少钱”，也关心“为什么值这个价格”。
板块得分模型基于多年基础数据，从价格、成交和物理属性中抽取核心指标：
| 指标 | 权重 | 作用 |
|---|---|---|
| 板块均价 | 35% | 衡量板块价格水平 |
| 板块套均总价 | 35% | 衡量购买门槛和客群能力 |
| 板块房龄中位数 | 20% | 衡量板块房屋结构和产品新旧程度 |
| 板块换手率 | 10% | 衡量市场活跃度和流动性 |
楼盘评价体系则进一步把楼盘价值拆成区位、房屋、楼盘、交通和生活配套等变量：
| 评价方向 | 典型变量 |
|---|---|
| 区位属性 | 区域、环线、板块、到市中心距离 |
| 房屋属性 | 开发商、房龄、装修、建筑形态、竣工年代 |
| 楼盘属性 | 容积率、绿化率、车位配比率 |
| 交通指数 | 轨道交通距离、站点数、公交站距离 |
| 生活配套 | 学校、医院、商业中心、公园、物业管理费 |
这些变量让价格体系更容易解释。对于用户来说，楼盘价格需要放回城市、板块和产品语境中理解；对于 B 端客户来说，价格背后需要能够拆解为区位、产品、流动性、配套和市场活跃度。
数据验证与资产沉淀
数据中心项目还有一类很重要的工作，是用表格和样本持续验证模型结果。
资料里有“挂牌价与基价的差异”表，用于对比新房楼盘、二手房楼盘、距离、楼盘基价、挂牌中位数价格、挂牌价与基价差异、世联价格、成交均价等字段。这类表格的价值，是把模型结果放回真实市场中校验。
| 验证对象 | 核心字段 | 价值 |
|---|---|---|
| 挂牌价与基价差异 | 楼盘基价、挂牌中位数、差异比例、成交均价 | 判断基价是否偏离市场 |
| 恒星楼盘对比 | 成交套数、成交金额、成交月份、动迁比例、板块覆盖 | 判断稳定样本池是否合理 |
| 户型图数据 | 新房户型图、二手房户型图、通用户型图、抽样核验 | 支撑房屋级产品表达和后续估值 |
| 中介集中度 | 公司成交量、市占率、HHI、CR8 | 支撑二手房市场结构分析 |
| 税费计算 | 新房税费、二手房税费、交易规则 | 支撑 C 端和经纪人作业工具 |
这些表格看起来不像前端界面，但它们是数据产品最关键的底层工作。只有持续做校验、抽样、对比和口径修正，模型结果才会逐渐接近业务可用状态。
数据如何驱动产品
这个项目的数据链路可以概括为：
多源价格数据
-> 清洗与异常处理
-> 指数体系
-> 楼盘基价 / 房屋基价
-> 产品模块
-> 用户判断 / 客户决策在一房一万中，基价和成交数据帮助购房者理解楼盘价格是否合理；在挂牌查价中，基价体系可以为二手房查询提供参考；在 CityMap 中，价格和指数支撑开发商做板块、土地、新房和二手房判断；在红盘系统中，价格数据又成为营销操盘和竞品比较的基础。
这一项目最有价值的地方，是把价格从“单个字段”变成 跨产品复用的数据资产。数据一旦具备稳定口径，就可以被多个产品、多个页面、多个业务场景反复调用。
成果与价值
- 建立了支撑澜思多条产品线的 底层价格与指标体系，覆盖区域、板块、楼盘、房屋等多层级对象。
- 将新房、二手房、挂牌、外部平台和内部评估等数据源组织进统一价格框架。
- 通过基价算法 3.0、相似楼盘补全、异常涨跌控制和历史价格倒推，提升楼盘价格的覆盖度和稳定性。
- 沉淀恒星楼盘、板块得分、楼盘评价、户型图、税费计算和市场集中度等数据资产。
- 支撑一房一万、挂牌查价、CityMap、红盘系统、科东预估等产品的价格展示、趋势判断、楼盘比较和估值场景。
- 对我个人来说，这个项目强化了 从数据模型到产品表达的转译能力：我需要理解复杂模型，也需要让模型结果能被业务、客户和用户真正使用。
个人能力沉淀
这个项目让我进一步确认，数据产品的难点并不只在“有数据”，而在于数据能否被稳定理解、持续校验和长期复用。
RAS、基价和恒星楼盘这些工作，最终沉淀的是三种能力：
- 复杂口径理解能力：面对多来源、多口径、多时间维度的数据，能拆清楚每个字段、每个指标和每个结果的适用边界。
- 模型产品化能力：能把算法逻辑翻译成业务人员看得懂、用户能理解、产品界面能承载的表达。
- 数据资产意识：理解数据需要长期清洗、关联、校验和复用，真正有价值的是一套能反复支撑业务判断的底层系统。
这段经历也和我后来做紫微斗数数据化解读系统形成了连接。无论是房地产价格模型，还是传统知识解读系统，本质上都需要把复杂经验拆成结构化数据、规则和可验证结果。用户愿意相信一个系统，核心在于背后是否有稳定口径、可追溯依据和持续迭代能力。