RAG项目上线后效果翻车，检索准确率暴跌，大佬们怎么排查的？

先别急着调chunk，拿那批崩了的query做个golden set跑一遍，看下是召回问题还是排序问题，大概率是embedding对口语化query天生不友好。

我之前也踩过类似的坑，后来发现问题多半出在chunk切分和query预处理上。固定200字确实容易把语义拦腰切断，建议先按段落或标题做结构切分，再配合rerank试试。另外golden set一定要建，拿线上真实query去跑，别只看top-k，得看最终回答质量。你换BGE-large没用，可能是没做query改写，口语化输入先转成书面语再检索会稳很多。

这个情况太典型了，我上个月也踩过类似的坑。你先把chunk切分从固定字数改成按语义段落或者标题层级来切，200字很容易把“发放时间”和“计算规则”这种强关联信息拆散。排查顺序我建议先看召回结果里到底混进了什么无关内容，再决定是调embedding还是加rerank——BGE对口语化query确实一般，但很多问题其实出在query改写上，可以试试让LLM先把用户问题转成标准检索词。golden set得建，不用太复杂，拿线上真实query抽个50条，人工标好应该命中的文档，跑个召回率对比，比凭感觉调参靠谱多了。

我之前也踩过类似的坑，后来发现问题多半出在chunk切分上，固定200字太粗暴了，语义边界一断，embedding再强也白搭。建议你先按标题或段落结构切，或者用递归字符切分器，保留上下文完整性，然后再看检索效果。另外rerank确实值得加，但别一上来就上，先拿线上失败的query做个mini测试集，对比一下不同切分和embedding组合的召回率，比盲目调参靠谱得多。

我之前也踩过类似的坑，线上query口语化程度真的比测试集高太多，BGE对长尾表达不敏感挺常见的。你提到固定200字切分，这个我强烈建议先改掉，我后来按语义段落切，再配合滑动窗口重叠，召回效果明显稳了。另外golden set一定要建，别偷懒，从线上日志里抽几百条真实query，人工标好正确答案，跑个召回率对比，比凭感觉调参靠谱得多。至于rerank，我觉得先别急着上，你检索源头就歪了，rerank救不回来。可以看看你们是不是没做query改写，比如“工资什么时候发”这种，先映射到“薪酬发放时间”再检索，命中率会高很多。还有个细节，检查下chunk里是不是有太多无关信息，比如制度文件里一堆“目的、适用范围”这类废话，会把向量带偏，我后来加了权重过滤才好转。

先别急着动chunk和embedding，拿你那几个翻车query做个bad case分析，八成是query和文档里“工资发放”这种词压根对不上，先做同义改写或加关键词扩展试试。

说实话你这个情况我太熟了，上线前用标准测试集跑得漂漂亮亮，一接真实用户就现原形。我建议先别急着动chunk和embedding，你那两个怀疑方向其实都是表象，核心问题多半是query和文档之间的语义鸿沟——用户口语里“工资什么时候发”对应的是制度文件里“薪酬支付周期”这种书面表述，embedding模型对这类改写本来就弱，换BGE-large不解决根本问题。我当时的排查顺序是先抓badcase，把线上检索失败的query攒下来，人工看召回结果里到底混进了什么，这时候你会发现很多问题是chunk边界切碎了关键句子导致的，比如“薪酬”和“发放时间”被拆到两个块里，那召回自然乱套。所以我会建议你先做一个快速实验：把固定200字改成按段落或者语义切分，配合100字重叠，看badcase有没有明显变化。另外rerank不是银弹，但如果你检索集够大，加一个cross-encoder做第二遍重排通常能救回不少分。评估这块，golden set必须建，但别用官方文档里的标准问答，找运营同事帮忙收集真实用户问题，每个问题标注对应正确文档段落，先拿20-30条就能跑通流程，用hit@5加MRR看趋势，比你自己拍脑袋试参数靠谱多了。最后提一句，LangChain默认的retriever配置对生产环境太天真了，你最好把检索链路拆开单独测试，别套着框架黑盒调。

先别急着切chunk，用真实query建个golden set跑一遍，看看是不是embedding对口语化表达不敏感。

我之前遇到类似问题，最后是加了query改写和rerank才救回来，光调chunk真不够。

你这情况太典型了，我猜大概率不是embedding的锅，而是query和文档的表述粒度不匹配。先别急着调chunk，建议拿20条真实用户query去库里手动标出正确答案，算一下召回率到底跌在哪一层。我上次也是固定切分导致“工资发放”这种语义被拆成两半，后来改成按章节标题+段落切，配合关键词过滤器，效果立竿见影。Rerank可以后置，等基础召回稳了再加，不然容易掩盖真正的问题。另外golden set别光用标准问法，多塞点口语变体，比如“啥时候打钱”这种，模型才能暴露短板。

线上翻车太常见了，我上次也是类似情况，最后发现是query预处理没做，比如“工资什么时候发”这种口语问法，得先做实体识别或意图改写，把“工资”映射到“薪酬”再检索。chunk大小我个人建议别死守200字，按章节或语义段落切，配合滑动窗口重叠试试，比盲目调rerank更直接。你先别急着换模型，拿100条真实用户query构造个golden set，用召回率加命中位置两个指标卡一下，能快速定位是切分问题还是embedding表达问题。

说实话你这情况太典型了，我上次上线也栽在chunk上，固定字数切会把“发薪日”和“离职结算”这种强关联上下文活活拆开。建议先别急着动embedding，把chunk改成按章节或语义段落切，再配合一个轻量级rerank模型，效果立竿见影。golden set一定要建，别偷懒，拿50条真实用户query去测，top5召回率低于70%就说明切分或检索策略有问题，上线前跑一遍能省好多事。

说实话你这情况我太熟了，固定200字切分基本等于把语义拦腰斩断。我会先拿几个典型翻车query做个bad case分析，看看是召回阶段就没带出来还是排序问题。如果召回就没命中，优先考虑改切分策略，比如按标题和段落结构来切，而不是死磕字数。另外建议你搞个50条左右的golden set，线上跑之前先离线算召回率，别等上线再翻车。

口语化query和文档表述的gap确实容易被忽略，你换BGE还不行，可能问题不在embedding本身，而是query改写没做。试试先加一层意图识别或同义改写，把“工资什么时候发”映射到“薪酬发放时间”这类文档用词再检索。chunk固定200字肯定不行，语义截断太致命，建议按段落或标题层级切，再叠加重叠窗口。排查顺序我一般先看召回，用golden set跑一遍看是召回阶段就丢了还是排序阶段排错了，别急着上rerank。

口语化query和文档表述之间确实有gap，光换embedding模型治标不治本，query改写那块得加上，比如先让LLM把“工资什么时候发”改写成“薪酬发放时间规定”再检索。chunk切分建议按语义或标题层级来，固定200字肯定截断严重，可以试试递归切分加overlap。排查顺序我一般先看query改写和chunk质量，再上rerank，不然垃圾进垃圾出，rerank也救不回来。golden set一定要提前构造，至少覆盖高频问法和边界case，不然线上翻车只能靠用户投诉发现。

口语化query和文档书面语的语义gap确实容易被忽略，BGE-large换了也没用说明问题可能不在模型本身。建议先别急着调chunk，把线上真实query捞一批出来，人工标注下哪些该召回哪些不该，跑个recall@k看看baseline到底多差。chunk按固定字数切确实容易把条文腰斩，试试按标题层级或语义段落切，配合overlap能救回不少。另外加个rerank（比如bge-reranker）通常比死磕embedding立竿见影，但前提是粗排得把正确文档捞进候选里。

先拿真实query构造golden set跑一遍，看是召回还是排序的锅，别急着调chunk。

口语化query和文档用词gap太大确实是重灾区，光换embedding模型治标不治本。我之前也踩过这坑，后来加了一层query改写，把“工资什么时候发”扩成“薪资发放时间 薪酬制度”，召回立马好转。chunk建议别死磕固定长度，按标题层级或语义切，再配个bge-reranker精排，效果提升很明显。golden set一定要提前建，哪怕先手工标个几十条，上线前跑一遍能省很多返工。

口语化query和文档语料天然有gap，embedding换再大也难救，得在检索前加一层query改写或者同义扩展。chunk按200字硬切确实坑，试试按段落或语义切，重叠留个20%别心疼。上线前搞个几十条的golden set跑recall@k和MRR，比拍脑袋调参靠谱多了。另外rerank别急着上，先把召回阶段的问题定位清楚，不然就是把垃圾排得更整齐而已。

“工资什么时候发”这种query和《薪酬管理制度》里的书面表述之间gap确实大，光靠换embedding模型不一定救得回来。我踩过类似的坑，最后发现最大问题出在chunk上——固定200字切分把“工资发放时间”这句和上下文里的“每月15日前”直接切散了，检索出来自然是一堆碎片。你可以先把chunk改成按语义或段落切，再带一点overlap，看看召回有没有变化。另外rerank值得加，BGE-reranker对口语query的排序提升挺明显的，但前提是召回阶段别把正确文档漏掉。评估这块，建议你从真实日志里抽一两百条query，人工标好应该命中的doc id，跑recall@k和mrr，比拍脑袋调参靠谱得多。还有个容易忽略的点：线上query往往很短很口语，可以考虑做query改写或扩写，把“工资什么时候发”补成“薪酬 发放 时间 规定”再检索。如果这些都没用，那可能要回头看看文档解析阶段是不是把表格里的发薪日期搞丢了。

这坑我踩过，感觉你问题大概率不在embedding模型上，BGE-large对口语query其实已经算能打了。你说“工资什么时候发”召回了离职流程，这更像是chunk切分把“薪酬”和“离职”混在了同一个固定窗口里，200字硬切很容易把不同条款缝在一起。建议先别急着换rerank，把原始文档的chunk打出来人肉看几条，确认是不是切分把语义边界搞没了。另外线上query和本地测试分布差很多，用户口语里会带“啥时候”“发工资”这种词，光靠向量召回确实容易飘，加一层关键词或BM25混合召回会稳不少。评估这块我觉得golden set必须建，但别只标“正确文档”，要标“正确chunk”，不然你调半天都不知道是召回问题还是切分问题。最后提醒一句，top-k命中率本地看着行，很可能是因为你本地query写得太像文档原文了，线上真实问法才是照妖镜。