最近很多团队在讨论RAG落地时，都会遇到一个非常实际的问题：为什么在实际项目中，像信息抽取、RAG这类任务，要特别强调引文生成和来源定位？背后的核心逻辑是什么？有没有具体的落地案例？技术上又该如何实现？

今天是2025年6月24日，借此机会，我们一边拆解落地过程中的难点，一边回顾RAG这两年的发展脉络，看看2025年的趋势究竟指向哪里。

一、RAG、抽取等落地场景的定位问题思考

1、为什么需要引文生成？

根本原因在于，包括大模型在内的深度学习方案，生成数据的原理都是基于概率模型，这就难免产生“幻觉”——也就是虚构事实或缺乏依据的结论。而引文标注来源，就是给用户提供一种验证答案是否基于真实数据的手段。

以RAG为例：模型在生成答案前会检索外部知识库，并将检索到的文档片段作为依据输出。这样一来，用户不仅能查看答案，还能点击核对原始资料，相当于给系统装了一个“可追溯的开关”。

在实际场景中更直接：在医疗或金融领域，如果回答政策问题时没有标注具体条款来源，很可能误导决策；而引用“《XX政策》第3.2条”这样的具体章节，可信度就完全不同了。

除了技术层面的可信度，还有一层人的因素：这些模型的决策过程缺乏可解释性，引文相当于提供了一个“解释层”，让用户理解答案的生成逻辑。尤其在B端和G端，这个需求比想象中更强烈。

2、有哪些典型的定位例子

先说RAG场景。定位可以细到chunk级别，也可以定位到某个具体的文档页面。这在RAG产品和开源项目中已经非常常见。

一个是magi，知识图谱抽取中的引文生成。这个出现得比较早，在知识图谱构建时，系统会标注抽取的实体或关系来自哪个段落，并用线条把来源和结果连接起来。

另一个是典型的RAGflow中的chunk定位：系统会记录问题答案所在的chunk，以及这个chunk在文本中的索引位置，从而实现精准定位。

再进一步，还可以拓展到多模态任务上，比如答案定位VQA（Visual Question Answering）。这里不仅要求系统回答问题，还要在图像中圈出支持答案的证据区域，结合了图像理解和NLP的能力。

3、从技术上看实现策略

以RAG中的引文生成为例，可以拆成两个层面：一是让系统知道答案来自哪个文档（引文生成），二是精确定位到文档中的具体信息（来源定位）。

第一个问题依赖大模型的能力。可以通过微调或者强化学习来解决，简单粗暴的方法是在prompt中给相关文档打上标记，比如数字标引，让标引和chunk一一对应。然后提示LLM在生成答案时带上这些标引。

第二个问题通常用物理方式解决。既然拿到了上一步关联的chunk，就可以跟离线阶段呼应起来。比如在构建向量数据库时，每个文本片段（chunk）都关联一个唯一标识符（文档ID、起始位置、结束位置、URL等）。用Chroma或FAISS存储向量时，元数据字段可以包含doc_id、chunk_index、file_path等信息。

如果要进一步在原文档中渲染高亮，那就需要前端配合了。

至于信息抽取中的定位，其实更自然——抽取过程本身就从某个段落出发，而段落原文本来就有offset，只需要预先记录即可。

二、RAG-2025发展温故而知新

回顾2024年RAG的发展，有篇文章总结得不错（这里就不贴链接了），其中几个关键点值得拿出来聊聊。

1、从2023到2026年的RAG与LLM发展预判

从2024年的文档解析、GraphRAG，到2025年的多模态RAG以及结构化、非结构化的统一抽取——这个方向目前确实在加速推进。

2、RAG的三个挑战定性不变

还是老问题，三个：非结构化多模态文档的问答效率低下，现有LLMOps方案基本只支持纯文本场景；PDF、PPT或图文混排的文档无法充分发挥潜力；纯向量数据库导致召回率和命中率低——RAG的核心是搜索能力，只有能根据用户查询“搜索”出答案，才算真正发挥作用。

3、RAG中的文档多模态Embedding

所以现在大家都在卷embedding，单模态或多模态。单模态的代表如qwen3-embedding，多模态用得比较多的是colqwen、colpali这类方案。

好处在于绕过了OCR和chunk，直接做问答——这是在做加法，减少中间环节的损耗。

4、RAG中的文档解析演变

数据质量决定输出质量，所谓garbage in, garbage out，这个道理讲了很久。典型的路线是pipeline方式，社区里已经讨论很多了。

预测2025年，基于编码器-解码器架构的研究有望取得进一步进展。这一判断已经应验——今年出现了统一的多模态文档解析模型，能把各种非结构化文档转换为文本内容。

最近的monkeyocr、dolphin、mineru2.0等方案都在朝这个方向发展，直接推动了当前多模态RAG的落地。

参