RAG 系统如何标注信息来源和提供引用？
这道题考的是 RAG 系统"引用溯源"能力的完整理解——怎么让模型回答时有据可查，而不是凭空生成。面试官想看你对 RAG 全链路的掌握程度，从数据处理到检索策略再到生成输出，每个环节都影响引用质量。
我从四个方面来讲：引用溯源的核心原理、分块与 Embedding 对引用的影响、混合检索与重排、以及 RAG 引用能力的演进阶段。
引用溯源是 RAG 的核心竞争力
先搞清楚一件事：LLM 本身不知道它"说"的内容来自哪里。
模型训练时吃了海量文本，输出时"参考"了哪些文档、哪个段落，模型自己都说不清。这就是为什么 LLM 有时会"一本正经地胡说八道"。
RAG 的出现改变了这一点。它让模型从"凭记忆回答"变成"基于检索证据回答"。
具体流程是这样的：
用户提问 → 系统去知识库检索 → 找到相关文档片段 → 把这些片段和来源信息一起拼给 LLM → LLM 生成答案时明确标注"这条信息来自某文档的某部分"。
举个例子。用户问"公司年假多少天"，RAG 系统会先检索到 HR 文档中关于年假的段落，然后把这段话连同"来源：HR_policy_v3.pdf 第5段"这样的元数据一起给到模型。模型输出的答案就会带上这个引用标记。
没有引用的 RAG 就像开卷考试却不给参考资料——你知道有参考资料能用，但不知道哪份才是正确答案。
引用能力让 RAG 区别于普通搜索。传统搜索返回一堆链接，用户自己判断哪个有用；RAG 直接把证据塞给模型，模型替用户消化后给出带出处的答案。这就是"生成式"和"检索式"的本质区别。
引用质量由分块策略和 Embedding 决定
引用准不准，最底层的影响因素是两个：怎么切分文档、用什么向量模型表示。
分块策略
文档进来第一步是切成小块（chunk）。切得太大，混入无关信息，模型容易被噪声带偏；切得太小，丢失上下文，引用可能断章取义。
常见做法是固定 token 数切分，比如每 512 个 token 一切。但问题来了：语义可能被拦腰截断。比如一段话前半句在讲"用户增长策略"，后半句突然转到"成本控制"，切在中间就尴尬了。
更合理的做法是按语义切分，或者用重叠策略——相邻 chunk 之间重叠 20-50 个 token，让上下文有所延续。
想象从一本被撕碎的书里找答案。撕得太碎，单个碎片信息残缺；撕得太粗，碎片里混入乱七八糟的内容。分块就是在找那个"刚刚好"的粒度。
Embedding 模型
分块之后，每个 chunk 要转成向量才能做相似度检索。Embedding 模型的选择直接影响"召回的东西对不对"。
中文场景下，通用 Embedding 对专业术语、垂直领域词汇的理解可能不够。比如医疗文档里"浸润性生长"和"外生性生长"，通用模型可能分不清，导致检索召回错误内容。
实际项目中，往往需要在通用 Embedding 基础上做领域微调，或者直接用针对垂直场景优化过的模型。
Embedding 不准，引用就是空中楼阁——检索阶段就找错了片段，后面再怎么优化都没用。
混合检索 + 重排是引用准确性的保障
检索环节是引用质量的关键。单一检索方式总有缺陷，工业级 RAG 系统通常采用混合检索 + Rerank 的组合。
混合检索
向量检索根据语义相似度找内容，擅长"语义相近但表述不同"的匹配。关键词检索根据字面匹配，擅长精确术语和专有名词。
两者结合叫混合检索。向量检索先大海捞针，关键词检索再精准打捞，互相补位。
类比一下：先让图书馆系统初筛（向量检索找到所有可能相关的书），再让图书管理员根据关键词复核排序（关键词检索调整相关性），最后只给你有权限区域的资料（权限过滤）。
Rerank 重排
初筛结果往往不够精准，需要 Rerank 模型做二次排序。
Rerank 模型的思路是：用更大的模型、更精细的语义理解，重新计算每条检索结果与 query 的相关性分数，然后调整排序。
这一步直接影响引用的是"最佳答案"还是"差不多能用"。
元数据过滤
引用还有个容易被忽视的问题：权限。
如果用户 A 查到的内容引用了用户 B 无权访问的文档，就会造成数据泄露。元数据过滤在检索阶段就要过滤掉无权限的内容，而不是等生成阶段再处理。
RAG 引用能力的三阶段演进
RAG 系统的引用能力经历了三个阶段，不同阶段解决的问题不同。
Naive RAG
最基础的形态：用户 query → 检索 → 直接拼给 LLM → 输出。
这套架构适合 Demo 和 POC，能快速验证 RAG 概念。但引用质量不稳定，检索稍有偏差，答案就可能张冠李戴。
Advanced RAG
加入了 Query 改写、混合检索、Rerank、上下文压缩等优化。引用准确性大幅提升。
Query 改写是为了弥合用户表达和专业文档之间的语义 gap。用户说"电脑蓝屏咋整"，专业文档可能写的是"系统崩溃（BSOD）故障排查"。Query 改写把口语转成文档语言再检索。
上下文压缩是去掉检索结果里的冗余信息，只保留最核心的段落，减少 token 消耗同时提升引用精准度。
Modular RAG
模块化设计，根据业务场景动态组合不同模块。最灵活，引用能力也最强。
复杂 Agent 场景下，Modular RAG 可以按任务类型路由——简单问答走轻量检索，复杂分析走深度检索 + 多步推理。
金融、医疗、法律这些场景，引用是硬需求。答错了要担责，所以引用必须精准、可溯源。选型时要考虑的不是"要不要引用"，而是"引用精度要到哪个级别"。
长上下文的误区
有人觉得：有了 128K 上下文的大模型，把整个知识库都塞进去不就行了？
不行。塞太多无关片段会导致注意力稀释，模型在海量信息里找重点的能力下降。而且 Token 开销和延迟会爆炸。
RAG 的核心价值不是"给模型更多 context"，而是"给模型更准的 context"。引用机制正是这种精准性的保证。
面试怎么答
基础版
RAG 系统通过将检索到的文档片段及其来源信息传递给 LLM 来实现引用溯源。每个检索到的 chunk 都会携带元数据（文档 ID、chunk 位置等），在生成阶段这些信息会作为上下文的一部分，让模型在回答时明确标注信息来源。
引用质量主要受两个因素影响：一是分块策略，chunk 太大引入噪声、太小丢失上下文，需要根据业务场景调整粒度；二是 Embedding 模型的选择，垂直领域建议用微调过的模型。
生产环境推荐用混合检索（向量 + 关键词）结合 Rerank 提升相关性，同时要做好权限过滤避免数据泄露。
加分版
引用能力不是一次性做好的，需要建立评测闭环持续优化。可以从召回率、精确率、引用准确率等维度量化评估。
架构选型上，金融、医疗等强合规场景建议用 Modular RAG，按业务需求动态配置检索策略。引用成本也需要权衡——文档片段越多，Token 消耗和响应延迟越高，要找到精度和性能的平衡点。
RAG 的本质是"给模型更准的 context，不是更多的 context"。长上下文模型不能替代 RAG，塞太多无关内容反而会影响模型判断。
一句话总结
RAG 的引用能力靠的是精准的分块 + 合适的 Embedding + 混合检索与 Rerank 保障召回相关性，最后用 Modular 架构按场景灵活配置。