当用户问「黄渤是干啥的」却得到跑题答案时，问题往往不在模型本身。本文揭示了一个关键盲点：知识库中的原始资料格式决定了检索效果。通过拆解RAG系统的工作原理，你会发现真正需要优化的是让入库内容「长得像问题的答案」。文章提出「数据蒸馏」的实操方案，教你如何重构知识片段，使其在语义地图上占据更中心的位置，从而显著提升问答命中率。

用户在你的知识库产品里打了一句「黄渤是干啥的」，系统回了一段「黄渤主演的某部电影上映那年成绩不错」。意思沾点边，但没人会觉得这是个好回答。

大多数人遇到这种情况，第一反应是「模型不行」或者「prompt 没写好」，然后回去换模型、调 prompt、加几句「请准确回答用户问题」。我看到过好几个团队都卡在这一步，折腾一大圈，发现基本没用。

因为问题常常根本不在模型那一层。

它在你存进知识库的那段原文身上——那段话，长得不像「用户那句问题应该得到的答案」。检索这一步压根没把它捞出来，模型手上拿到的就是一堆跑题材料，它再聪明也只能基于跑题材料硬答。这事我也是被一个做 RAG 的工程师朋友点醒的，下面尽量用人话讲清楚，讲得不一定全对，你可以挑着看。

先说清楚：检索这一步，不是「读懂问题再去找答案」。

很多产品同学脑子里默认的模型是这样的：用户问一句，系统理解了这句话的意思，然后去库里翻出对应的知识，交给大模型组织语言。听起来很合理，但中间那步「理解了意思去翻」，实现方式和你想的不太一样。

主流做法是这样：每一段资料在进库之前，系统会把它换算成一串数字，你可以理解成给这段话在一张巨大的地图上插了一面旗。这串数字（也就是这面旗插在哪）由这段话的内容决定。用户的问题进来，也被换算成同样的一串数字，也在这张地图上插一面旗。

然后系统做的事情，特别朴素：它不读内容，它只量距离。看用户这面旗，离库里哪几面旗最近，就把那几面旗对应的原文，原样捞出来，塞回给大模型。

就这么简单。它不判断「这段话能不能回答问题」，它只判断「这段话和这个问题，像不像」。

数学上是怎么算「像不像」的，我专门问过那个朋友，他说说白了就是两个向量的点积、或者夹角余弦，夹角越小就认为语义越近。公式细节产品上其实不用记，记住一句话就够用了：比的是「问题」和「你存进去那句话」之间的相似度，不是「答案对不对」。

这句话是这篇里我觉得最值钱的一句。它解释了几乎所有「答非所问」的怪现象。

回到黄渤那个例子，看库里到底发生了什么。

假设你的库里关于黄渤，散落着三段创作者写的内容：

第一段，是一篇影评，里面有一句「……黄渤是演员……」，但这一句前后跟着一大段在聊别的导演、聊那部片子的镜头语言。这段话的旗，被那一大段「别的」带偏了，插在了「影评 / 镜头」那一片区域。

第二段，是某个剧情解析帖，「黄渤参演过 XXX」这句信息，夹在一长串剧情复述中间。这段的旗，插在「剧情复述」那一片。

第三段，是个粉丝帖，「有人说黄渤是世界上最好的男人」，周围全是彩虹屁。这段的旗，插在「粉丝情绪」那一片。

三段里，其实每一段都「埋着」一点关于黄渤的真信息。但请注意：每一段的旗，都没插在「黄渤是干啥的」这个问题该指向的位置。它们各自被自己周围那一大堆别的内容，拽到地图的犄角旮旯去了。

用户问「黄渤是干啥的」，他这面旗，孤零零插在地图中间一个很「正」的位置。系统一量距离——三段原文的旗，没有一面离他足够近。于是要么捞回来一段跑题的，要么干脆没捞到合适的，模型只能现编。

你看，模型一点没错。错在那三段话，没一段长得像「这个问题的答案」。

蒸馏，干的就是「把旗重新插正」这件事。

所谓蒸馏，落到操作上没那么玄。就是在数据进库之前，让 AI 先把这些散落的、各自跑题的原始片段，归并、改写成一句中性的、信息密度高的话。比如把上面三段，熬成这么一条：

「黄渤，演员，代表作 XXX、XXX，凭 XXX 拿过 XXX 奖，有人称他是……」

这一条，本身就长得像「一个关于黄渤的问题，应该得到的标准答案」。它没有影评的废话，没有剧情复述，没有彩虹屁。它句式中性，把「他是谁 / 演过啥 / 有啥名号」这几件事，压在一句话里。

这条话的旗，会插在地图上一个非常「中心」的位置。

然后神奇的地方来了：「黄渤是干啥的」这面旗，离它很近；「黄渤演过什么电影」这面旗，也离它很近；「黄渤有什么外号」这面旗，还是离它很近。

一条顶原来三条，而且对每一种问法，夹角都小。

这就是为什么大家都在强调要做「百科式」的数据。不是因为百科这个形式有什么魔力，是因为百科那种「中性、信息密、把一个实体几件核心事压在一起说」的写法，天然就处在「各种问法都离它近」的那个中心位置上。检索比的是相似度，而百科式写法，跟真实提问的相似度，就是高。

（顺便插一句跟主线关系不大的：我一开始很抗拒「让 AI 改写原始数据」这件事，总觉得改写会丢信息、会引入二次错误。后来想通了一点——原文你可以留着备用，蒸馏出来那条只用于「被检索到」，捞到之后还可以再带上原文。这个我后面会说。这层顾虑大多数 PM 其实没那么必要，先往下看。）

这件事还顺手解释了一部分「幻觉」是从哪来的。

创作者数据稀疏，是模型瞎编的原因之一。什么叫稀疏？就是你那个「字典」里，关于某个东西的词条，要么是空的，要么虽然有、但埋得太深，检索那一步根本捞不出来。

这种时候，模型不会老老实实跟用户说「这个我库里没有」。它会顺着问题的语气，把那个空格给填上。填出来的东西，语法通顺、语气笃定、看着特别像那么回事——这就是幻觉。

百科化，某种程度上就是在干「补词条」这件事：把那些空的、或者埋太深捞不到的条目，改写成一条「中性、好被捞到」的话，塞到检索够得着的地方。

我现在的理解大概是这样，不一定对：它不解决全部幻觉。它堵的是「明明库里有这个信息、就是因为写得太散捞不出来」这一类。至于那种库里压根没有、模型纯靠想象的，这套办法管不着，那是另一个问题。

那作为产品同学，具体能做点啥。

有个不太需要你懂多少技术、但很可能立竿见影的动作：别再把原始资料一刀切成块、直接丢进库。在「入库」前面，加一道工序。

这道工序就一件事：让模型把每一份原始资料，按「关于这个实体 / 这个问题，用一句中性的话说清楚」的要求，重写一遍。重写出来那条进库、用于被检索；原文不删，挂在旁边备用，捞到那条之后把原文也一并带给大模型。这样既拿到了「容易被捞」的好处，又没真丢掉原始信息。

做完这一道，别拍脑袋觉得变好了。拿一批真实用户问过的 query，跑一遍改写前、改写后，对比一下命中——就看你想要的那段，到底有没有被捞回来。

这块我也只是说个我自己想过的方向，不一定对。我能比较确定的是：这套东西在「实体类、事实类」的问题上，提升会比较明显，就是那种「X 是谁」「X 有啥」「X 和 Y 啥关系」的问法。但碰上「需要跨好几段综合推理」的问题，光靠改写出一条百科句，多半不够，得另配别的招。这部分我没想透，网上讲检索优化的文章也已经讲烂了，我就只挑了「为什么会答非所问」这一个点说，其他的我不班门弄斧。

说句实在的：这思路一点不新，而且它没跳出原来那个框。

把创作者数据进一步压缩、蒸馏，熬出更密的数据，再让 AI 把蒸馏出来的东西归一遍——这个想法 arxiv 上有论文提过类似的（感兴趣可以去翻 2603.25737 那篇）。我看到行业里好几个团队，也在做差不多的事。这不是谁的独门秘籍。

而且要诚实地讲：它没跳出 RAG 这个框子。整个流程还是「切块—变成向量—按距离检索—塞回给模型」，蒸馏只是把「切什么、存什么样的句子」这一步做得聪明了一点，让旗插得更正。它没回答一个更根上的问题——为什么非得让模型隔着「检索」这一层，去够它要用的数据。那是另一个话题了，这篇先不展开。

所以你别指望靠这一招解决所有检索问题。它就是个挺有效的、针对「答非所问」的局部修法。能用上的场景用，用不上的别硬套。

你现在就可以做一件具体的事：去翻一下你那个知识库里，命中最差、用户最容易骂的那条 query，把它对应的那段原文拎出来，自己读一遍，然后问自己一句——这段话，像不像「这个问题的答案」？

十有八九，你会发现它根本不像。它像一篇影评、像一段剧情复述、像一个彩虹屁。怎么改，我上面说了一种思路，不一定对，欢迎你来打脸。