RAG 从 Demo 到生产：向量库选型、召回质量与评测闭环

为什么大多数 RAG 项目死在 Demo 阶段

过去一年我看了太多「三天搭出 RAG Demo，三个月上不了生产」的项目。Demo 阶段的共同特征是：知识库几千条、问答靠感觉、指标靠吹。而生产环境的拷问完全不同——数据量涨 100 倍、并发用户涌进来、领导要的是「准确率到底是多少」而不是「效果看起来不错」。

RAG 系统生产化，本质上是三个问题的闭环：检索准不准、生成稳不稳、效果怎么度量。本文按这个框架拆解。

一、向量库选型：先算清楚数据规模和运维账

选向量库之前，先回答三个问题：数据量级（百万级 chunk 以内，pgvector 完全够用；千万级以上再考虑独立向量库）、写入频率（实时索引 vs 每日批导）、运维人力（有没有人愿意多维护一套组件）。

我的建议分三档：

• 百万级以内、已有 PostgreSQL 的团队：pgvector。零新增组件、事务一致、备份链路复用。配合 HNSW 索引，百万级向量召回延迟在几十毫秒内。
• 百万到千万级、检索时延敏感：Milvus 或 Qdrant。Qdrant 单机部署更简单，Milvus 生态更全（内置多租户和流式索引）。
• 纯托管、不想碰运维：云厂商的向量数据库托管服务，贵但省心。

一个反直觉的结论：绝大多数团队换向量库之前，应该先换 embedding 模型和检索策略。召回率的天花板由 embedding 质量决定，而不是由向量库决定的。

二、召回质量：chunk 策略与混合检索

召回差，80% 是 chunk 切分的问题，不是向量库的问题。

chunk 的黄金法则：以语义单元切分，而不是固定字数。固定 500 字切分会把「一个完整的方案描述」拦腰截断。推荐按标题层级（markdown 标题、PDF 章节）切，配合 50 字重叠避免边界截断。代码、表格、JSON 这类结构化内容，单独切并加类型前缀。

混合检索是必须的，不是可选项。纯向量检索对专有名词（型号、API 名、缩写）的召回非常差——这类词在语义空间里容易漂移。生产方案标配：BM25 关键词检索 + 向量检索双路召回，合并去重后过 rerank 模型（bge-reranker 等），把 Top-50 精排到 Top-5。

一个实测数据：混合检索 + rerank 相比纯向量，在我们一个售后知识库上 Recall@5 从 0.71 提升到 0.92，问答准确率从 68% 提升到 84%。改造成本大约是一周。

三、评测闭环：没有指标的 RAG 都是玄学

这是 RAG 生产化最被忽视、也最值钱的一环。

第一步：建 golden set（黄金测试集）。从真实用户问题里抽 200~300 条，人工标注标准答案和对应文档片段。标注质量决定评测可信度，宁可少而精。

第二步：定义指标。检索侧看 Recall@k、MRR；生成侧建议用「答案可判定」的指标——正确答案能判定（选择题式）、关键事实命中率（答案里是否包含标准答案的实体和数字）、以及幻觉率（让模型自评+人工抽检双轨）。

第三步：纳入 CI。每次改 embedding 模型、改 chunk 策略、改 prompt，跑一遍评测集，指标回退就不许合并。这一步能让团队在「感觉变好了」和「真的变好了」之间建立分界线。

四、生产化的三个坑

1. 权限与隔离：知识库里混着内部文档和公开文档时，检索必须带权限过滤，否则就是数据泄露事故。向量检索的 ACL 过滤比 SQL 复杂得多，要在索引设计时就考虑。

2. 上下文超长：Top-5 片段全塞进去，长文场景 token 消耗爆炸。用 rerank 精排 + 相关性阈值 + 按需截断控制上下文预算，必要时做两级检索（先粗后精）。

3. 监控与可观测：上线第一天就记录每个问题的检索片段和答案，埋点用户反馈按钮。没有日志，出了幻觉问题你连复盘的材料都没有。

结语

RAG 生产化的路径很清晰：选型按数据量分档，召回靠混合检索 + rerank 提质量，上线靠评测集 + CI 守底线。把这三件事做扎实，RAG 就能从「demo 玩具」变成「生产工具」。