AI房产搜索助手：从对话到图片理解的垂直搜索MVP实战

这次看一个很有意思的房屋搜索产品形态。它来自 Hacker News 上的 Show HN 展示，作者的表达很直接：搜房不应该只是筛户型、筛价格、翻列表图，而应该像聊天一样，用户问“我想找通勤 30 分钟内、带书房、月成本控制在 8000 以内的小两居”，系统能理解这句话，能看懂房源照片里是不是真有书房，还能把每月的持有成本估算出来。

标题里三个能力点很值得拆开看：对话式搜索、照片级多模态理解、月度开销估算。前两个是现在 AI 应用里最常见的能力组合，第三个“月度成本估算”才是这套产品的差异化所在。它意味着系统不只做排序，还要做推理和归因，把不确定的持有成本拆成可解释的明细。

这篇文章会做三件事：先把这个产品形态背后的技术链路拆清楚，再给出一套可以在本地跑起来的 MVP 验证流程，最后把部署、接口、资源占用和合规边界一起盘一遍。如果你正在做房产信息类工具、智能体应用，或者想了解多模态模型怎么落地到垂直搜索场景，这篇可以直接收藏。

1. 房屋搜索 AI 助手的核心能力速览

从项目标题能推断出核心能力是三条链路，不是单点功能：

需要注意，标题是产品展示而非完整开源仓库文档，所以表格里的“推荐配置”“接口路径”不等于官方参数。实际要跑通这个产品，还需要结合具体数据源和模型版本核实。

2. 这个产品形态解决什么问题

传统房产搜索的体验已经被固定了：选城市、选户型、拉价格区间、看列表图，然后用户自己判断照片里的装修、采光、房间实际用途。这套流程有两个明显问题。

第一，搜索表达是碎片化的。用户很难用连续的自然语言描述“我想找一套朝南、客厅能放下投影幕布、离地铁站步行不超过 800 米的房子”。传统筛选项支持价格、面积、居室数，但很难支持“客厅能不能放投影幕布”这种需要看图和估算的条件。

第二，筛选粒度停留在字段层，没有进入内容层。房源列表页通常会写“3 室 2 厅”，但只有看了图片才知道第三个房间是书房、儿童房还是储物间。如果系统能理解图片内容和房间关系，就能把搜索精度提高一个层次。

月度成本估算的价值更直接。买房或租房的真实开销不只是挂牌价，还包括按揭、物业、水电网、保险、维修分摊。标题里用“est. monthly costs”而不是简单写“价格”，说明作者想提供一个更接近用户决策的计算能力。

那这类工具适合谁？如果是有真实房源数据的平台，它可以作为“智能选房助手”的交互入口。如果是独立开发者，它可以做一套小规模 MVP，先验证对话、图片理解和成本估算三个子任务能不能串起来。如果是在做 Agent 应用，它的技术链路也足够通用：多模态输入到参数抽取、检索到调用外部计算，最后把结果组织成自然语言返回。

也要说清不适用的情况。如果房源数据量小且字段很规范，传统筛选足够，没必要引入多模态模型。如果产品要处理的是真实用户隐私和交易数据，却没有明确的数据合规方案，也不建议直接上线。这类 AI 房产搜索能做得很“聪明”，但聪明的前提是数据来源合法、图片内容有授权、成本估算公式透明可复查。

3. 标题背后其实是四个技术模块

拆开看，一个“会聊天、会读图、会算月成本”的房产搜索助手，至少有四层模块。

3.1 自然语言转查询

用户聊天输入不能直接进数据库。需要把“我想找海淀区 500 万以内、通勤方便的电梯房”转成结构化的过滤条件。常用做法是让大模型做工具调用，输出统一的 JSON Schema：

{ "city": "北京", "district": "海淀区", "max_price": 5000000, "features": ["电梯房", "通勤方便"], "sort_by": "match_score" }

这个 JSON 再转成后端查询。问题在于“通勤方便”“采光好”这类主观词没法直接映射，必须先做语义检索或再走一轮模型判断。

3.2 多模态房源图片理解

图片理解的目标是把室内图、户型图变成可检索的结构化信息。比如识别出客厅、主卧、厨房的边界，判断是否有阳台、是否有独立书房、整体装修风格、空间是否局促。

这类任务可以用视觉语言模型（VLM）来实现。输入一张房源图和一个 prompt，输出结构化描述：

{ "room_type": "living_room", "space_feeling": "open", "has_balcony": true, "furniture": ["sofa", "tv_console", "bookshelf"], "lighting": "bright", "description": "客厅朝南，采光好，带阳台" }

户型图比实拍图更难一些，因为涉及墙体、门窗、面积比例关系，部分模型只能做粗略判断。稳妥点的方法是先走普通 OCR 抽取面积和房间数标注，再做视觉问答。

3.3 月度成本估算引擎

月度成本不能靠模型“拍脑袋”生成，更适合写成一个计算函数，由规则引擎决定。结构上通常包括输入变量、费用分母和说明输出三部分。

输入变量包括房屋总价、首付比例、贷款年限、当前利率、物业费、保险、预估水电燃气、年均维修分摊。输出则要把每一个子项拆给用户看。

如果直接让大模型生成成本结果，容易产生数字幻觉。更推荐的做法是让模型从房源数据里提取关键字段，然后把字段传给一个确定性的计算模块。成本估算的核心是透明度，不是计算复杂度。

3.4 对话编排与结果解释

最后一层是把上面三个能力串起来。用户的每一轮提问，系统要决定先检索文本，还是先看图，再决定是否需要调用成本计算。这种典型场景适合用 Function Calling 或 ReAct 式 Agent 来组织。

比如用户说“这套房月维护大概多少”，系统需要先定位当前房源，再读取房源详情，然后调用费用估算函数。如果用户问“这个客厅放得下双人沙发吗”，系统需要先读取这张客厅图的尺寸描述，再做空间关系判断。整个过程就是工具调用 + 多轮记忆，并不需要特别复杂的架构，但要把路由规则和上下文管理做好。

4. 本地验证的环境准备

在没有官方一键包的情况下，本地搭一个验证环境并不复杂。核心思路是：文本检索用轻量级向量库，图片理解接开源多模态模型，成本计算先写死规则函数，最后用 FastAPI 把这些模块暴露出来。

建议按下面的清单准备环境:

先检查硬件：

# Linux 或 macOS 检查 GPU 工具 nvidia-smi # 检查 Python 版本 python --version

如果本机没有可用 GPU，方案就要调整：图片理解任务换成 API 调用，或者用 CPU 版的小型多模态模型，速度会明显变慢，只适合做功能验证，不适合批量。

5. 搭建一个可运行的最小原型

下面给的不是原项目官方命令，而是一套用于理解该产品形态的最小实现模板。假设已经有一个houses.json数据文件，字段包括房源 ID、标题、价格、城市、户型字段，并有一个图片文件夹photos/。

5.1 安装依赖

pip install fastapi uvicorn pydantic requests

如果要用 Embedding 模型和向量检索，再装向量库。假如选择 Chroma：

pip install chromadb

5.2 定义核心数据结构和成本计算函数

from typing import List, Optional from pydantic import BaseModel class House(BaseModel): id: str city: str district: Optional[str] = None title: str total_price: float area: float rooms: int living_rooms: int bathrooms: int has_elevator: bool = False has_balcony: bool = False class PhotoDescription(BaseModel): house_id: str rooms_detected: List[str] balcony: bool bright: bool description: str def estimate_monthly_cost(house: House, down_payment_ratio: float = 0.3, loan_years: int = 30, annual_rate: float = 0.045, hoa_fee: float = 0.0, insurance: float = 0.0, utilities: float = 0.0) -> dict: loan_amount = house.total_price * (1 - down_payment_ratio) monthly_rate = annual_rate / 12 months = loan_years * 12 if monthly_rate > 0: mortgage = loan_amount * (monthly_rate * (1 + monthly_rate) ** months) / \ ((1 + monthly_rate) ** months - 1) else: mortgage = loan_amount / months monthly_cost = { "mortgage": round(mortgage, 2), "hoa_fee": hoa_fee, "insurance": insurance, "utilities": utilities, "maintenance_reserve": round(house.total_price * 0.0005, 2), "total": round(mortgage + hoa_fee + insurance + utilities + house.total_price * 0.0005, 2) } return monthly_cost

成本估算函数本身不需要大模型，只要输入数据可靠，结果就是确定性计算。这里的利率、首付比例只是示例，真实场景应该从用户配置读取，并且明确告知贷款利率会影响最终月供。

5.3 图片理解函数

图片理解这里用一个占位函数。真实项目中，这个函数内部会调用多模态模型，输出房间类型和特征。这里先保留调用结构，方便后续接入模型或云服务：

def describe_house_photo(house_id: str, image_url: str) -> PhotoDescription: # 这里应替换为真实多模态模型调用。 # 示例输出结构用于表示模型返回后的清洗结果。 return PhotoDescription( house_id=house_id, rooms_detected=["living_room", "kitchen", "bedroom"], balcony=True, bright=True, description="客厅明亮通透，带朝南阳台，地面铺设木地板。" )

生产环境中，需要在函数内部加错误处理。图片模糊、暗光、角度很偏都会影响识别结果，最好在描述里带一个confidence字段，低于阈值的图片不能进入搜索召回。

5.4 对话解析与搜索装配

对话查询先让大模型输出结构化参数。为了保持模块简单，这里用一个parse_query函数代替完整的模型调用：

from typing import List def parse_query(user_input: str) -> dict: # 真实环境使用大模型 + Function Calling # 示例返回表示从“找海淀500万以内带电梯的两居”抽出的参数 return { "city": "北京", "district": "海淀", "max_total_price": 5000000, "rooms": 2, "require_elevator": True } def search_houses(query: dict, houses: List[House]) -> List[House]: result = [] for h in houses: if query.get("city") and h.city != query["city"]: continue if query.get("district") and h.district != query["district"]: continue if query.get("max_total_price") and h.total_price > query["max_total_price"]: continue if query.get("rooms") and h.rooms < query["rooms"]: continue if query.get("require_elevator") and not h.has_elevator: continue result.append(h) return result

这里用的是规则匹配，更完整的方案是接入语义检索和向量召回。要理解的是架构分界：自然语言转结构化是模型层，检索房源是数据层，成本估算是规则层，最后统一由编排层响应。

5.5 组装 FastAPI 服务

from fastapi import FastAPI app = FastAPI(title="AI Home Search API") houses_db = [] @app.post("/api/search") def chat_search(user_input: str): query = parse_query(user_input) matched = search_houses(query, houses_db) return {"query": query, "results": matched} @app.post("/api/photo/describe") def photo_describe(house_id: str, image_url: str): desc = describe_house_photo(house_id, image_url) return desc @app.post("/api/estimate") def estimate(house_id: str, hoa_fee: float = 0, utilities: float = 0): house = next((h for h in houses_db if h.id == house_id), None) if house is None: return {"error": "house not found"} cost = estimate_monthly_cost(house, hoa_fee=hoa_fee, utilities=utilities) return cost

启动服务：

uvicorn main:app --host 127.0.0.1 --port 8000

启动后，可以先访问http://127.0.0.1:8000/docs看接口列表。这个过程可以作为本地验证的第一步：先别接模型，用假数据和函数把链路跑通，再逐步替换成真实模型，排查会容易很多。

6. 功能测试与效果验证

这套 MVP 最需要验证的并不是代码能不能跑，而是三个核心任务的效果是否达标。建议准备一个只有 5 到 10 套房源的小数据集，跑下面三类测试。

6.1 对话式搜索测试

测试输入可以这样写：

• “北京海淀 500 万以内，两居室，要求带电梯”
• “不需要电梯，但希望有阳台”
• “预算再低一点，450 万以内”

预期结果是系统能把连续几轮限制条件记录到上下文，并生成准确的结构化查询。判断标准是看解析出来的 JSON 是否完整覆盖价格、地区、户型、特殊要求。最容易出问题的地方是“再低一点”这种需要结合上一轮上下文才能理解的描述，所以要重点测多轮对话。

6.2 图片理解测试

选择三种典型图片：室内客厅实拍图、户型图、光线很暗的手机随手拍。

预期结果是客厅图能识别出是否带阳台、空间是否开阔、有没有明显家具；户型图能识别出有几个卧室和客厅；光线很暗的图应该提示图片质量低而不是强行返回一个不靠谱结论。

判断标准是结构化输出和人工标注的差异。实际测试不需要追求识别和人工完全一致，关键是看错误是否集中在某类图上。如果暗光图错误率特别高，就在工程上做图片清晰度预检，过滤低质量素材，而不是把所有压力都交给模型。检查显存或 CPU 占用时可以观察推理过程。

6.3 月度成本估算测试

用同一套房源，分别给三组不同首付比例和利率，看输出明细是否合理。判断标准是总额等于各分项之和，并且贷款月供随利率上行而上升。

这里建议测试一个极端值，比如全款买房，此时贷款月供应该为 0，成本只剩物业、水电和维修分摊。这类边界测试最能暴露公式写错的问题。成本估算引擎不能直接交给黑盒模型，必须做单元测试。

7. 接口 API 与批量任务设计

如果前面 MVP 跑通，下一步就是把接口按业务场景拆细。

建议拆成四类接口：

7.1 curl 调用示例

对话搜索接口示例：

curl -X POST "http://127.0.0.1:8000/api/search" \ -H "Content-Type: application/json" \ -d '{ "user_input": "北京海淀500万以内带电梯两居", "session_id": "user-001" }'

图片解析接口示例：

curl -X POST "http://127.0.0.1:8000/api/photo/describe" \ -H "Content-Type: application/json" \ -d '{ "house_id": "house_001", "image_url": "https://example.com/photos/living_room.jpg" }'

月成本估算接口示例：

curl -X POST "http://127.0.0.1:8000/api/estimate" \ -H "Content-Type: application/json" \ -d '{ "house_id": "house_001", "hoa_fee": 300, "utilities": 450 }'

7.2 Python 调用示例

import requests BASE_URL = "http://127.0.0.1:8000" payload = { "user_input": "北京海淀500万以内带电梯两居", "session_id": "user-001" } resp = requests.post(f"{BASE_URL}/api/search", json=payload, timeout=30) print(resp.json())

7.3 批量任务建议

房源图片解析是典型批量任务场景。一个小区可能一次导入几百套房源，每套房 5 到 10 张图。如果逐张调用，网络和模型推理都会成为瓶颈。

工程上建议加一层任务队列。任务结构可以用 JSON 表示：

{ "job_id": "batch_20250101_001", "house_ids": ["house_001", "house_002", "house_003"], "tasks": [ {"type": "photo_parse", "house_id": "house_001", "image_urls": ["url1", "url2"]}, {"type": "cost_update", "house_id": "house_001"} ], "webhook_url": "https://example.com/callback" }

批量任务必须有日志和重试。图片下载失败、模型接口超时、返回 JSON 解析异常都要单独记录，不能让整个队列停下来重跑。状态设计可以拆成 pending、processing、success、failed 四类，每个任务单独标记，便于断点续跑。

8. 资源占用与性能观察

AI 房产搜索的性能瓶颈主要集中在图片理解和自然语言解析两个模型推理环节，传统数据库筛选和规则成本计算几乎不占资源。

从技术上判断，这个产品的核心开销可以分成三层：

本地观察 GPU 资源：

nvidia-smi

如果同时起多个模型进程，比如一个文本模型负责对话、一个多模态模型负责图片，显存会叠加。更稳妥的做法是按需加载模型，或者用支持多模型常驻的推理服务统一管理。

分辨率对推理速度的影响最直接。图片不能直接拿原始像素尺寸进模型，需要先做预处理，长边通常压到 1024 或 768 级别。分辨率越接近模型训练尺寸，推理越快，结果也越稳定。如果要支持大图识别，可以做切片，把一张户型图按区域切成多块再分别识别，效果往往好于直接缩放整图。

批量并发时要注意任务排队。图片理解接口如果设计成单模型常驻，默认只能单张顺序处理。要让吞吐提升，需要做推理服务层的并发控制，而不是简单开多个 Python 线程，因为模型显存和线程锁很快会成为瓶颈。一个可行方案是前端用 Redis 做任务队列，后端消费任务并控制并发数，尽量保证单卡推理服务每秒处理数量稳定。

CPU 推理能不能用？取决于选什么规模的模型。纯尺寸不大的 OCR 或者文本分类模型在 CPU 上可以做，但完整的多模态图片理解加对话，CPU 推理延迟会很高，只能做小流量验证。如果本机没有 NVIDIA 显卡，建议优先考虑调用合规的云模型 API，而不是硬扛本地推理。

9. 常见问题与排查方法

下面这组排查表可以直接照搬，用来处理这个 MVP 最常见的坑。实测环境不同，问题不一定完全相同，但排查顺序都是一样的。

实际调试时最值得记住的一条经验是：把模型调用和业务逻辑解耦。模型返回的非结构化结果先转成统一 JSON，再交给下游逻辑，整个过程记录一次原始返回。这样即使某张图识别错了，也不至于让整个房源进入错误排序。

10. 产品上线前的合规与使用边界

做房产搜索 AI 工具必须把边界想清楚，不能只关注模型效果。

房源数据是典型的强版权和高隐私数据。图片内容通常来自中介平台、业主或经纪公司，没有授权的情况下，不能把图片随意抓取后用于模型训练或对外展示。做 MVP 时建议使用公开可授权的数据集，或者自己模拟数据。涉及用户输入的小区、预算、通勤条件等偏好信息，也属于敏感信息，存储时要脱敏并限制访问范围。

成本估算天然带有财务建议属性。示例代码里的折算利率、物业费等参数不能作为投资建议。产品界面应展示公式和参数来源，并提示用户最终费用需要结合银行、物业和税务机构的信息进行确认。一旦涉及贷款、税费等专业结论，最好增加免责说明。月成本估算要做到可解释，不能只给一个“约 7000 元/月”的数字，要有 mortgage、物业费、水电等拆分项。

还有一个容易被忽略的合规点：图片识别可能会识别出人脸、门牌号、儿童房和室内私人物品。房源图通常不希望暴露原住址和隐私物品，所以在做批量解析时，应优先做去标识化处理，并限制图片的可见范围。

11. 从标题到落地，真正值得验证的三件事

这类“AI + 垂直搜索”产品最怕的不是模型不够聪明，而是用户问完一轮后发现回答解释不了，或者推荐结果不知道为什么出现。

第一件值得花时间验证的事是对话质量。用户会换很多种说法描述同一需求，系统要能在多轮对话里稳定抽取条件。这个测试不需要大样本，准备 30 到 50 条真实找房语句，反复调 prompt 和解析逻辑，就能看出模型在短句、长句、否定表达上的差距。

第二件值得验证的是图片理解的准确率边界。搞清楚模型在客厅图、厨房图、暗光图、户型图上分别什么表现，能否过滤低质量图，输出的房间类型和设施标签是否可用于检索。只要这一步稳定，搜索结果质量就会有明显提升。

第三件是成本估算的可解释性。把公式写清楚，让用户能看懂为什么是这个月成本，比把数字预测得精确更重要。与其让模型生成一个看起来精准但解释不了的数字，不如让规则引擎把每个分项算得明明白白。这个设计思路也适合扩展方继续做税费计算、学区距离、通勤时间等更多结构化能力。

如果你想拿这个方向做产品，这套 MVP 是足够快的起点：FastAPI 做接口、规则函数做成本计算、多模态模型做图片解析、大模型负责自然语言路由。先把链路跑通，再逐步替换模块，比一开始就搭建完整 Agent 系统更容易控制风险。