嘿，老友们，今天聊聊RAG里引用总是错位的坑。你们说这玩意儿真是让人抓狂——答案kan起来好像靠谱，却一点也没Neng找到原文出处。别急，我这就拆解一下背后到底有啥道理。

先说个事实：RAG本质上是把“检索”和“推理”拼接在一起。检索拿到的是一堆小片段，推理再把它们拼成答案。问题来了检索拿到的小片段可不是完整的章节，而是碎碎念。所以当模型输出答案时它只Neng凭自己的语言模型去补全上下文，结果就变成了自己胡编乱造的“证据”。

说实话，模型那边并没有任何“原始文档定位”的信息。它只知道这些chunk里出现过哪些词，却不知道这些词到底在哪个章节、哪页、哪段落。于是当你要求它给出引用时就只Neng随便挑几个evidence_id，然后打上假装有页码的标签。

我们往往用Tika之类一次性把文件读进来然后按固定长度切块。假设一句法律条款被切成两块，那后面就会出现“一半被检索到，一半被忽略”的情况。模型kan到前半句，就会开始推断后半句到底怎么写，结果引出了错误引用。

哈哈，这种Zuo法简直就是让模型在迷宫里玩捉迷藏——你给它一个线索，它却跟着线索跑进了另一条路。

向量库想要高召回，所以喜欢小块；而回答需要完整语义，所以又想要大块。这两件事自然冲突。若你让所有chunkdouhen大，你的向量空间会变得稀疏，召回率下降；若你让所有chunkdouhen小，你得到的上下文就不完整。

我曾经尝试把整个章节作为一个大chunk直接写进Milvus，但效果极差——因为每个查询dou要匹配整章，让系统连同一条问题dou找不到合适答案。

于是我改了一下架构：先把文件拆成父块，再从父块切出子块。子块只负责检索；父块则携带完整上下文和元数据。流程大致：

上传 → Tika解析 → 父层切分

父层 → 子层切分

子层向量化 → 写入Milvus；父层写入MySQL

查询时先检索子层 → 聚合同一parent_id → 再取对应父层内容填充prompt

生成答案时仅Neng使用Yi返回的evidence_id，否则直接拒绝或重试

这样Zuo的好处：

准确溯源：