RAG 的冷启动问题：没有历史数据时怎么建好检索系统

冷启动的"缺"其实是三种缺

"没有历史数据"是所有新 RAG 系统共同的起点，但这个说法把问题说得太大也太笼统。拆开看，冷启动缺的是三种性质完全不同的数据，各自卡住系统建设的不同环节，补法也完全不同：缺查询（不知道用户会怎么问）卡住评测与优化——没有真实查询分布，任何检索优化都没有锚点；缺标注（没有 query 与正确文档的配对）卡住模型适配——embedding 与 reranker 的领域微调无从下手；缺反馈（上线后没有点按信号）卡住迭代——系统的持续改进失去数据来源。三种缺的严重性排序也值得注意：缺查询最致命，因为它让"好不好"这件事不可判断；缺标注次之，因为它限制优化手段但通用模型还能跑；缺反馈只是时间问题，上线自然会来。

这个分解的第一个实践含义是：不要试图用一种手段补三种缺。最常见的错误是大规模生成合成查询数据，然后指望它同时解决评测、微调、优化三个问题——合成数据对不同缺口的适配度差异很大，下面分别讨论。三种缺与三种补法的关系如下图：

flowchart LR
    subgraph 缺
        A[缺查询<br/>卡评测与优化]
        B[缺标注<br/>卡模型适配]
        C[缺反馈<br/>卡持续迭代]
    end
    subgraph 补法
        A --> A1[挖掘工单 / FAQ / 服务台记录<br/>真实分布的查询资产]
        B --> B1[LLM 合成 query-chunk 对<br/>四道质量闸 + 难负例挖掘]
        C --> C1[人工抽检 + 金丝雀查询集<br/>代理指标过渡]
    end
    A1 --> E[封存的评测集<br/>50-100 条五类覆盖]
    B1 --> T[训练集<br/>检索器 / 重排器适配]
    C1 --> W[每周回归<br/>故障查询回灌哨兵集]

缺标注：合成数据是主粮

从语料合成 query-chunk 对

合成的基本形态：对每个 chunk 让 LLM 生成"会以这个段落为答案依据的查询"，构成正样本对。这条路线的学术背书很扎实：InPars（Bonifacio 等人 SIGIR 2022）证明少量示例驱动的查询生成可以有效训练检索器；Promptagator（Dai 等人 ICLR 2023）进一步证明，用大模型做 few-shot 查询生成，再训练出的中小型检索器与重排器，能在多个基准上达到甚至超过用大规模人工标注数据训练的基线。对领域场景这套方法格外有价值：领域知识在语料里，而不在标注预算里——领域专家标注一千对数据的成本，足够支撑数千条合成对的生成加抽检。

但合成对的质量决定一切，不合格的合成对会教坏检索器。质量控制有四道闸：

def qc_synthetic_pair(query, chunk) -> bool:
    """合成对的四道质量闸，任一不过即丢弃"""
    if not (8 <= len(query) <= 60):
        return False                       # 闸一：长度——太短像关键词，太长像摘要
    if not any(q in query for q in ["什么", "怎么", "哪些", "为什么", "如何", "？"]):
        return False                       # 闸二：疑问形态——合成的是查询不是标题
    if not evidence_check(query, chunk):   # 闸三：可答性——答案依据确实在该段落
        return False
    if near_dup(query, synthetic_pool, threshold=0.85):
        return False                       # 闸四：去重——同一段落只留最优变体
    return True

第三道闸（可答性）最关键也最容易省略：让另一个 LLM 判断"仅凭这个段落能否回答该查询"，不能就丢弃。省略它的后果是训练出"宽容"的检索器——学会了把语义相近但不含答案的段落排前，这正是 RAG 最典型的失败模式。可答性闸的成本（每对一次小模型调用）远低于它拦截的训练污染。

种子语料：合成质量的上游

合成查询的质量受制于种子语料的质量——从噪声语料合成的查询对，质量闸再严也救不了内容本身的问题。冷启动期的语料选择有四条标准：权威性（选官方文档与正式制度，不选散落的个人笔记）；覆盖度（按主题分布抽样，确保核心主题都有代表文档，合成的查询分布跟随语料分布）；自包含性（优先选不依赖大量前置上下文就能读懂的文档——强依赖上下文的文档合成出的查询，在孤立检索场景下不可复现）；时效性（选现行有效的内容，别把过时文档合成进训练集，否则检索器会学会把过时内容排前）。四条标准过一遍之后，往往十分之三的语料承担了九成的合成价值——先选料再合成，比先合成再过滤便宜得多。

合成负例与难负例

正样本对只是训练数据的一半，对比学习的另一半是负例。in-batch negatives 是免费的起点，但真正涨点的是难负例：用当前检索器跑一遍合成查询，把排序靠前但非 gold 的段落挖出来做难负例（RocketQA 验证过的路线，本系列反馈循环那篇也用到同一机制）。注意难负例要过一道人工或模型抽检——有些"非 gold"段落实际上也包含答案（一个问题的答案散落在多个段落），把它们当负例是灾难性的标注错误。

合成数据的固有偏差：模型问的是模型关心的问题

合成数据有一个必须正视的系统性偏差：LLM 生成的查询分布偏向语料的显式内容——它从段落里能看到什么就问什么，问法工整、信息完整；而真实用户的问题常常是模糊的、带上下文的、甚至基于错误前提的。合成的"问题—答案"对描述的是"语料理想读者"的分布，不是你真实用户的分布。缓解手段有三个：persona 混合（生成时给 LLM 不同的用户人设——新员工、一线客服、外部客户，让问法分化）；难度混合（显式生成一部分模糊查询、口语化查询、多跳查询）；以及最重要的——把合成数据当训练粮，把真实查询当评估准绳，两者地位不能颠倒。第 20 篇会回到这一点：真实查询可以从别处挖到，不必完全依赖合成。

缺查询：挖掘"前 RAG 时代"的查询资产

企业里的查询不是零，是散落各处

"没有历史数据"的企业通常 overlooked 一个事实：用户的信息需求早已存在，只是没有以查询日志的形式存在。客服工单与 FAQ 是最富的矿——每一条用户求助就是一个真实查询，只是措辞是自然语言描述；销售与技术支持的内部群聊记录、IT 服务台的请求分类、历史培训材料里的"常见问题"章节，都是查询的变体来源。挖掘流程是：批量抽取 → LLM 标准化改写成独立查询（工单原文往往冗长带上下文，改写去掉无关细节）→ 去重聚类 → 人工抽检频次分布。这批资产的价值是双重的：作为评测集，它的分布天然贴近真实用户（比合成查询的分布可信得多）；作为检索优化的靶子，高频工单对应的知识缺口就是内容补齐的第一优先级。

首日评测集的最小规模

上线前的评测集不必贪大。实践验证过的最小规模是50 到 100 条，覆盖五类信息需求（类型划分参考查询理解那篇的五分类）：宁可小而全（每类 10 到 20 条），不要大而偏（400 条全是事实型）。这个规模足够支撑两类决策：上线前的检索器选型对比（几条之差就能区分候选方案的排序质量），以及上线初期的回归基线。评测集在冷启动期要保持"封存"纪律——它是评估的准绳，不要拿它做任何调参决策的依据，调参用另外构造的开发集。这个纪律在评测那篇讲过，冷启动期尤其要守：因为整个系统都在这 50 条的评估之上起飞，基准被污染的代价被放大。

缺反馈：上线后的信号补给

冷启动期的代理指标与人工抽检

反馈按钮的信号要几周才积累到可用量级，冷启动期用代理指标过渡：检索命中率的人工抽检——上线前两周，每天抽 20 条真实查询，人工判断"top-3 里有没有答案依据"，20 条的数据足够发现趋势性问题（某类文档集体失灵、某类查询集体失败），不足以支撑细粒度调参（这正好符合冷启动期的需要）。抽检结果按查询类型分桶记录，命中率的类型分布直接指出下一段优化的方向。

金丝雀查询集：自动化的质量哨兵

在人工抽检之上架一层自动化：金丝雀查询集——从评测集和首批真实查询里选 30 到 50 条"哨兵查询"，每日定时跑全链路，记录每条的 top-1 命中与分数。它的作用不是评估（评测集干这个），而是波动告警：索引更新后某条哨兵的分数大幅下跌，往往意味着这次更新破坏了某类内容的可检索性（比如新分块策略对长段落不友好）。金丝雀机制把"上线后质量悄悄劣化"从被动等待用户投诉，变成每日自动发现的工程事件——这是冷启动期最划算的一笔基础设施投入。

哨兵查询的选取还要刻意覆盖"曾经坏过"的查询——每次故障修复后，把故障查询补进哨兵集，让哨兵集成为故障记忆的载体；这个约定让同类问题二次发生时能在每日巡检里被当场抓住，而不是等用户再次投诉。

用户教育也是冷启动工程

最后一个常被归为"产品"而非"算法"的环节：冷启动期的首日体验决定用户信任，而信任决定后续反馈的质与量。两条具体的工程动作：一是空结果必须显式说出——检索无命中时回答"知识库中没有找到相关内容，建议咨询 X"，而不是让模型硬编；硬编一次被用户抓住，之后用户的反馈行为会整体退缩（"反正它瞎说，不反馈了"）。二是查询引导——首屏给出知识库擅长的问题示例，把用户的提问风格往系统能力范围内引导，冷启动期系统"接得住"的比例越高，正向反馈积累越快，飞轮启动越早。

小结

冷启动的正确打开方式是把"没有历史数据"拆成三种缺，分别对症下药。缺标注用合成数据补：Promptagator 与 InPars 证明了查询生成训练检索器的可行性，但四道质量闸（长度、疑问形态、可答性、去重）缺一不可，其中可答性闸防止训练出"宽容检索器"；难负例靠当前检索器自挖掘加抽检；正视合成数据的分布偏差——它是训练粮不是评估准绳。缺查询去企业里挖"前 RAG 时代"的资产：客服工单、FAQ、服务台记录里存着真实的用户信息需求，LLM 标准化改写后就是天然贴近真实分布的评测集；首日评测集 50 到 100 条、五类覆盖即可起飞，封存纪律必须守住。缺反馈用代理指标过渡：前两周每日人工抽检 20 条看类型化命中率，金丝雀查询集做每日自动化的波动告警，把质量劣化变成工程事件而非用户投诉。最后一条非算法的要点：空结果显式说出、查询引导上手，首日体验决定信任、信任决定反馈飞轮的转速。冷启动不是一个等待数据的被动阶段，而是一套主动制造数据、挖掘数据、守护数据的工程动作——做得好的团队，三个月就能走完别人一年的数据积累。