当 AI 能告诉你“答案来自哪”，它不只是变得更聪明，而是更可信。本文深入解析 AI 回答背后的“溯源机制”——从检索增强生成（RAG）到引用链路构建，揭示它如何在技术上实现“有出处的智能”，也如何在产品上重塑用户信任。

你是否注意到，在与 AI 智能体互动时（比如开启搜索功能），有些答案会附带明确的来源说明？这样的标注不仅增强了答案的可信度，也方便你随时回溯原始信息，验证内容是否准确。如下图所示：

看到这个功能，你是否也会好奇：它到底是怎么实现的呢？

接下来我会结合自己做的一个示例，来一步步讲解它背后的实现原理。

我们先来简单梳理一下这个功能的基本逻辑：

当用户提出问题后，应用会基于本地知识库生成对应的答案。在生成答案的同时，系统还会明确标注其来源——也就是答案具体来自知识库中的哪一部分内容。

基于这个功能，我们先把能想到的问题抛出：

1、我们知道，最终的答案是由大模型基于知识库生成的。那么，[1]、[4] 这样的引用标识是如何生成的？

2、即使大模型能够生成这些标识，它们又是如何准确关联到具体的来源内容的？

3、为什么引用的是 [1] 和 [4]，而不是其他位置的内容？

4、本地知识库的结构是怎样的？是不是就像显示的来源那样，以一问一答的形式进行存储？如果所有问答对都存在一个文档中，那系统又是如何精准定位到最相关的那个问答对呢？

……

你是否也有类似的疑问？或者更多其它的疑问，可以先思考一下，再继续往下看。

接下来，我会通过代码的方式，逐步拆解这个功能的底层原理。整个功能的实现过程依赖于大模型、向量检索技术和RAG（检索增强生成）机制。如果你对这些名词还不太熟悉，也不用担心——你可以先关注整体的实现流程，理解“是什么”和“怎么做”的过程，不必纠结于具体的术语细节。

下面是最终的代码结构：

注：以下所有代码均由 AI 生成。从零开始搭建，到实现最终的视频效果，整个过程总共耗时约 2 小时。

通过这个目录结构，我们可以清楚地看出，整个实现大致分为三个部分：源数据的向量化处理、后端接口的开发，以及前端页面的构建。

接下来，就正式进入正文部分。

还记得我们最开始提出的那些问题吗？现在，带着这些疑问，继续读下去，你会逐步找到答案。

我们先来看一下源知识库中内容的存储格式。

注：这些问答对是由大模型自动生成的。简单来说，我将一篇文章交给大模型，让它会根据文章内容，自动生成若干组相关的问答对，作为后续知识库的基础。

源数据的向量化处理

其中，\n\n 表示换行符。

最终用于向量化的输入示例如下：

doc = Document( page_content=”Q: 什么是 Embedding？nA: 是将对象转换成向量…”, metadata={“source”: “doc1.txt 第1问”})

在向量化的过程中：

• page_content会被用于生成embedding，例如转化为[0.12,-0.43,…,0.88]这样的向量，用于后续的相似度检索。
• page_content与metadata会一并存储，用于在匹配成功后展示原始内容及其来源，方便用户追溯。

因此，我们可以看出，在完成向量化处理后，每条知识库数据通常包含以下几类信息：

1、由问答内容生成的一组有序数值（即“向量”）。当用户提出问题时，系统会将问题也转化为向量，并通过计算它与知识库中现有向量之间的相似度（如余弦相似度），快速找到最相关的内容。

2、原始的问答内容和其对应的来源信息（例如：来自哪篇文档、第几问等）。这些信息会被完整保留下来，用于向用户展示答案的同时，也提供清晰的出处说明。

这，正是我们在结果中看到“引用来源”功能的底层支撑机制。通过向量化实现快速匹配，通过保留原始内容与元信息，实现清晰可追溯的答案来源展示——既提升了回答的准确性，也增强了用户对答案的信任感。

后端接口的开发

了解了向量化存储格式后，我们再来看这一功能在接口层面是如何实现的。下面这段代码展示了核心的请求逻辑：如何从向量数据库中检索相关问答、构造带来源标注的上下文，并最终将这些信息一并传入大模型生成回答。

具体的context内容格式如下：

接口最终输出的结果如下：

前端页面的构建

最后，我们来看前端页面是如何展示这些内容的。从图中可以看到，前端通过解析接口返回的answer和sources字段，不仅展示了生成的回答，还实现了对引用编号的高亮和点击事件处理，用户点击如 [1]、[4] 时，即可查看对应的原始问答内容及其来源。

这样整套流程就串联起来了：从文档构建知识库 → 向量化处理 → 后端相似度检索与引用格式构建 → 前端展示与交互补充，一整套功能就实现了。

最后，我们再来梳理一下整个功能的实现逻辑：

首先，需要明确一点：最终返回给用户的内容，全部是由大模型生成的，包括[1]、[4]。为了让答案具备可追溯性，前端层面在生成内的[1]、[4]引用编号上增加点击事件，展示它们对应的问答对及来源信息。

基于上面的流程，现在你是否已经对整个实现逻辑有了更清晰的理解？回到我们一开始抛出的那些问题，看看你现在是否已经有了答案：

1、我们知道，最终的答案是由大模型基于知识库生成的。那么，[1]、[4] 这样的引用标识是如何生成的？

2、即使大模型能够生成这些标识，它们又是如何准确关联到具体的来源内容的？

3、为什么引用的是 [1] 和 [4]，而不是其他位置的内容？

4、本地知识库的结构是怎样的？是不是就像显示的来源那样，以一问一答的形式进行存储？如果所有问答对都存在一个文档中，那系统又是如何精准定位到最相关的那个问答对呢？

如果你现在心中已经有了答案，说明你已经掌握了这套基于 RAG 技术的问答系统实现原理。希望这篇拆解能帮助你少走弯路，把一个看似复杂的功能，变得真正“看得懂、做得出”。