一个房产领域的知识库问答系统：把政策、流程、FAQ 这些资料做成可检索的知识库，用户提问时检索相关内容再生成回答。这类系统的难点从来不是”接个大模型就能答”，而是检索得准和答得不能错。我把重心放在检索质量和评测体系上。
检索：不是单路，是混合加重排
整条检索链路是：
文档 → 归一化 → 切 chunk → 同时建 BM25 索引和向量索引(Qdrant)查询 → BM25 召回 + 向量召回 → RRF 融合 → reranker 重排 → 交给生成为什么不只用向量检索？因为房产场景里有大量精确词（政策文号、专有名词、押金/二房东这类术语），纯语义向量容易把”意思相近但不是同一个东西”的内容召回上来；BM25 对精确词命中更稳。两路各有所长，用 RRF 融合，再上一个 reranker 做精排，召回质量明显比单路好。
数据管道真实跑通：25 个文档归一化、切成 59 个 chunk，同时写入 Qdrant 向量库和 BM25 索引。
评测：这套 Eval 是真正的护城河
大多数 RAG demo 做到”能跑通”就停了，但没有评测，你根本不知道改一个 chunk 策略、换一个 embedding 是变好还是变坏。所以我亲手构造了一套评测集：30 条查询，覆盖 5 种意图 × 7 种场景标签，指标用纯函数实现、和生成层解耦。
有了这套 Eval，检索策略的每次调整都能量化对比，而不是凭感觉。这部分我没有交给自动生成，是自己一条条把关的——它是整个项目里最能体现”做过真 RAG 工程”的地方。
一个内存受限下的真实决策
部署时撞上硬约束：机器只有 1.9G 内存，而本地跑 bge-m3（2.3G）加 bge-reranker（1G）加 Qdrant 加 Python 服务，必然 OOM。
我没有硬上 docker 拉一堆模型，而是把 embedding 从本地 bge-m3 换成 Qwen 的 text-embedding API：本地零模型占用，拿到的还是真实语义向量，代价只是多写约 50 行 backend。这个切换其实早在方案里就埋了伏笔——“内网 GPU 不足时换 API embedding”——现在内存限制正好让它落地。约束不是只能妥协，有时它逼你把一个本来就更干净的方案提前做了。
几个工程细节
- UI 通过 HTTP 调 API，不直接 import pipeline：模拟真实生产架构（无状态 UI vs 重模型后端），reranker 和 Qdrant 连接只在 API 进程加载一次。
- 数据诚实：demo 用的是占位语料，每条 chunk 标了
source_type=synthetic。这个岗位对信息准确性要求很高，我宁可坦诚说明”这是占位、入职接真实源”，也不假装它是真实数据——一旦面试官随手查一个文号查不到，整个项目的可信度就塌了。 - 8 个冒烟测试：健康检查、正常问答、拒答、空 query 返回 422、未知 provider 返回 400 等，把 API 的边界行为都钉住。
小结
RAG 工程真正难、也真正分水岭的地方，是检索质量和评测体系，而不是把大模型接进来。这个项目我最看重的是那套自建 Eval——它让”我觉得变好了”变成”数据上变好了”。