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，不然线上翻车只能靠用户投诉发现。