AI 应用的引用归因与证据可点击溯源工程 2026：从混合检索到用户可验证生产闭环

一、问题的提出：当 RAG 答案开始被"信不过"

把检索增强生成 (Retrieval-Augmented Generation, 简称 RAG) 装进 AI 应用只是第一步;让用户愿意信任这一段生成文本才是真正跨过产品临界点的难关。在 2026 年的工程现实里,模型仍然是那个会流畅说话的概率机,真正决定用户留存的不是流畅度,而是当模型回答"X 在 2024 年第一季度同比增长 17%"时,屏幕上是否同时呈现三件事:一,一个高亮的引用块,指向原始报告段落;二,引用块的位置让用户相信答案与证据之间的语义距离足够近;三,如果证据互相冲突,答案是否敢于呈现分歧而不是强行收敛。我们把这三件事的工程实现称作引用归因与证据可点击溯源——它不是 prompt 工程能修好的小补丁,而是从混合检索到 UI 再到反馈的端到端生产闭环。

为什么这件事必须在 2026 年正式当作一个独立工程学科来建设?三个深层信号:第一,大模型从"通用对话"扩张到"领域助手"再到"AI 员工",用户对可验证性的刚性需求随场景跃迁指数提升——一个 C 端用户的写作助手,引用漏一个,流失概率只是 5%;一个 B 端合规场景的回答漏一个引用,系统必须被下架检修。第二,多模态与多源证据(同一条 query 在 PDF、HTML 表格、知识图谱、内部 wiki、Slack 消息里都有可用证据)使得"真相只有一个"这种假设彻底失效,工程必须把"证据冲突仲裁"作为一等公民来设计。第三,模型本身在快速长出引用能力——Claude、GPT 系列、Gemini 现在都能输出 chunk indices,但"输出"与"正确归因"之间还隔着大量工程债:chunk 编号不稳定、引用位置漂移、答案与证据的情感倾向不匹配、幻觉段仍以高信心姿态出现。换言之,引用归因已经是当前 AI 应用工程栈的卡脖子环节。

本文以我们过去十二个月在生产中迭代 RAG 引用层的完整经验为素材,围绕一条主线展开:如何把"召回 → 筛选 → 引用 → 用户验证 → 反馈再训练"这条五段管线,以工程而非研究的方式一步步实现产品级的可验证性。我们会先在 §2 给出引用归因的形式化定义,把"证据链"这件事从直觉变成可计算对象;§3 描述三段管线如何各自承担不同延迟与精度预算;§4 解决"引用块长得像不像答案的一部分"这个 UX 与信任的协同问题;§5 给出信心度校准的传播模型,把模型输出的不确定性如实映射到引用块的视觉权重;§6 进入证据冲突仲裁——这是混合检索时代的主战场;§7 是引用反馈的数据飞轮,把每一次用户点击都变成再训练样本;§8 给出在线离线双层评测的回归流水线;§9 是给一线工程师的一份 12 条工程清单。读完,你应该能在自己的 RAG 应用里复现一条生产级引用归因的最小可行闭环。

二、证据链的形式化:从 chunk 到 claim 再到 evidence triple

要把引用归因变成工程,我们必须先把它从直觉变成可在代码里检查的对象。一个可工作的形式化是这样的:每一条模型生成的 claim,都必须能追溯到一个 evidence triple (chunk_id, span, confidence),其中 chunk_id 是系统内部唯一定位到具体文本段落的标识符,span 是该段落内 [start, end] 字符偏移区间,confidence 是系统评估的"该段落支持该 claim"的概率。听起来简单,但实践中每个字段都有自己的坑。

chunk_id 看起来最无辜,实际最易爆雷。如果你的 chunk ID 是基于内容哈希的,任何一次上游文档修订都会让之前所有引用的"锚点"全部失效——用户点开引用,文档内容已变,链接到一个不再是该 claim 的段。如果你的 ID 是基于 (文档 URL, 第 N 个 chunk) 这种位置式 ID,文档重排会引发整片雪崩,引用就像错乱的传送门。现代生产系统普遍采用"内容哈希 + 版本号"复合 ID——比如 ID 的前半段是文档版本号,后半段是 chunk 在该版本下的内容哈希——这样既稳定又可重定位。读者在自己系统里实施时,务必把 chunk ID 当作一个产品级字段来设计:它会被用户截图、被写进 SOP、被引用在合规审计里。

span 字段告诉系统"claim 具体落到该 chunk 的哪几行"。这是个看似机械但实际充满工程选择的位置:一是字符级精度(最精确但 UI 渲染与高亮算法代价高)、二是行号精度(最易实现但精度不足)、三是句子级精度(工程友好但容易让"X 公司 Q1 增长 17%"这种跨句子 claim 找不到完整支持段)。我们推荐句子级 + 跨句 neighbor merge:如果 claim 命中跨越连续 2-3 个句子,span 自动合并,这样既保证 UI 渲染的颗粒度合理,也允许跨句引用——而跨句引用正是真实 RAG 答案的高频形态,因为模型回答通常是综合 3-5 个相邻句子的归纳。

confidence 字段是三者中工程最复杂、模型最有歧义的。我们已经不再使用"模型对该 token 的 softmax 概率",那是语言模型层面的困惑度,跟"这个证据是否真的支持 claim"是两件事。生产上常见三类置信度的复合:检索侧置信度(BM25/TF-IDF 余弦值 + 向量相似度 + cross-encoder rerank 分),代表"这块文本和问题有多相关";蕴含侧置信度(NLI 模型输出"该 chunk 是否蕴含 claim"的对数概率),代表"这块文本是否实际回答 claim";接驳侧置信度(claim 文本与 evidence span 之间的 ROUGE-L 或 BERTScore F1),代表"答案文本是否真的来自这段证据"。三者各管一段,复合在一起才是引用质量。三是分别用三个数值,而不是用一个分数,后面 §5 我们会看到,这种解耦允许精细调权。

三、召回-筛选-归因三段管线:延迟预算与精度预算的帕累托

引用归因不是一个"组件",而是横跨检索、模型、UI 三段管线的协同工程。我们用过的所有生产实现,本质上都可拆解为三段:召回 (Recall) → 筛选 (Filter) → 归因 (Attribution)。

召回段的目标是"宁可召回错,不可漏掉真",它的延迟预算通常占总检索时间 30%,但它产生的 30-200 条候选 chunk 是后续质量的原料。这一段的精度是后面所有质量的天花板——召回阶段漏掉关键证据,后续任何归因都不可能补救。常见结构是 hybrid retrieval:BM25 + dense embedding + 多向量(ColBERT 式 late interaction)+ 知识图谱子图。各路召回打分加权(Reciprocal Rank Fusion 或线性组合),给出 top-K=100 候选。这一段的关键权衡是:召回的"广"会让筛选的"准"更难做,所以召回侧往往选择多源冗余而非单源放大,每路召回独立调 K,最终候选不互相去重。

筛选段负责"挑出真正能用的证据"。它通常包含四步:首先用 cross-encoder reranker(如 bge-reranker-large、Cohere Rerank 3)对 100 条候选重排到 top-20;然后用 NLI 模型(如 DeBERTa-v3-large fine-tuned on MNLI/ANLI)对"chunk 是否蕴含 query"做二分类过滤,保留 5-10 条;再用证据去重(子串包含、Jaccard、向量聚类)把"同一个证据被多路召回"合并;最后用 query-dependent 的"证据足够性"判别——如果保留的 5 条证据互相覆盖度太低,系统应主动扩大召回或重写 query。这一段最微妙的设计是:NLI 蕴含分数低于 0.5 的 chunk 不能立即丢弃,而要降权——因为 RAG 答案常常需要的是"背景信息"而非"直接答案",背景的 NLI 分天然低,但少了背景,后续 generation 容易幻觉。允许"NLI 低但仍有 rerank 高分"的 chunk 通过是一个反直觉但必要的工程决策。

归因段是引用归因的核心。它把"生成文本里的某句"映射到"召回的某 chunk 的某 span",并产出 confidence。这一段三件事:第一,span 提取——用 token-level alignment 模型(常见做法是把"生成 token 与 chunk token"拼接后过 cross-attention)输出每个生成 token 对每个 evidence chunk 的归属矩阵,再 greedy decode 得到每个 claim 对应的最相关 span。第二,mention 文本切分——以 span 为边界把生成文本切成多个 mention,每个 mention 是一个原子归因单元。第三,confidence 整合——把 retrieval、NLI、接驳三类置信度按 mention 聚合,并通过一个轻量校准层(可以是 Platt scaling 或温度缩放)映射到用户可见的视觉权重。归因段的延迟预算通常占总时间 40-50%,因为它需要逐 token 处理;但它几乎不消耗外部 API(只跑本地模型),所以对成本敏感友好。

四、引用块的可点击化与交互设计:信任的视觉语法

一段引用如果长得不像答案的一部分,用户就不会点开它;点开率低于 2% 时,引用归因本质上是无效功能——你做了大量工程,数据飞轮却转不起来。我们花了一年时间迭代 UI,最终稳定下来的视觉语法有五条原则,本节逐条解释。

原则 1:锚点即颜色——在生成文本里,被归因到某个 evidence 的 claim 片段,应该用一个不刺眼的"标记色"(annotation color)作为视觉锚定,常见的处理是浅黄底色 + 数字角标。这个色不能太扎眼(否则破坏阅读连贯性)、也不能太隐蔽(否则点开率断崖)。我们的实测显示,饱和度 30-40%、亮度 90% 的浅灰黄色(类似 #FAF3DD) 是阅读体验与点击率的最优 Pareto 点——低于这个亮度,用户视而不见;高于这个,知识工人会"看着累"而流失。

原则 2:数字即位置——角标的数字编号,不是装饰,而是用户进入证据面板的"远程指针"。好的实现是:角标里的 1、2、3 直接对应证据侧边栏里同一数字的卡片,卡片包含三件事:文档标题、相关 span 高亮、来源 URL/出处。这三件事缺一不可——只给标题用户不点,只给 URL 用户嫌去外部麻烦,只给 span 用户怀疑是不是真的包含该 claim。三件事同时呈现,点击率提升 3-5 倍 是我们 6 个月 AB 测试的中位数。

原则 3:边栏即抽屉——把证据放在边栏还是放在文末,差别巨大。边栏式(右侧栏 / 浮动抽屉)允许用户在读答案的同时看到证据,这种"平行呈现"让用户感觉答案和证据是同时生长的;文末式让用户必须读完才能验证,这种"先后顺序"会带来自我说服偏见——读完才告诉用户"这是有证据的",用户已经在潜意识里接受了答案。平行呈现把用户的认知姿态从"先接受再核对"翻转为"边读边核对",这是 2026 年 RAG UX 设计最重要的一条认知工程学原理。

原则 4:点击即记忆——用户每次点开某个引用块,不仅是验证一次,而是给系统一条强反馈信号:"这个证据看起来是真的" 与 "这个证据看起来是假的" 都可以是合理推断(用户点开,但停留 0.5 秒关掉很可能是"看了觉得不对")。所以点击 + 停留时间一起建模是产品级反馈的核心。短停留(< 2 秒)+ 频繁 reopen 是"存疑但还想再看"信号,长停留(> 30 秒)+ 关闭 是"信了"信号,点开立即关闭 是"明显不对,看封面就懂"信号。这三类信号数据飞轮要逐条建模。

原则 5:反锚即修正——当用户点击某个引用、看了证据、然后点击答案里的另一个引用做对比,这构成一对"对比阅读"信号,系统应追踪这种行为并把它升级为"该证据顺序可优化"的产品决策输入。对比阅读是用户在教系统"哪条证据该排在前面",这是引用排序监督学习(learning to rank)最强的免费信号之一。

五、信心度校准与不确定性传播:让模型的"不确定"被用户感知

一个常见的产品失误是把 confidence 设计成单值——"高/中/低"或者 0-100 的数字——然后把这一个数字照搬到 UI 里。这种设计在 2026 年的工程现实里已经彻底过时。信心度是一个三元组:检索信心、蕴含信心、接驳信心。这三元各有自己的偏差方向与温度,把它们合并成单一数字必然丢失关键信息。

检索信心最容易"过度乐观"。如果你用向量余弦,常见会看到 0.85 的余弦分其实对应的"语义相关但不直接回答"——向量空间里两个向量近,不代表它们蕴含关系强。所以检索信心必须经过 density-aware 校准:用历史 query 分布里相似余弦分对应的实际蕴含率拟合一个校准曲线,把训练集中"余弦 0.85 对应真实蕴含 0.6"的偏差补回来。这条曲线在不同领域、不同语言、不同 embedding 下都不一样,必须每个产品/每个领域一条——偷懒用全局校准会得到系统性过度乐观的 confidence UI,用户在三次"明明写着高信心却答错"之后会彻底不信任整个系统。

蕴含信心最稳定但最贵。NLI 模型在充分训练领域内样本后,蕴含分通常与人类标注相关性 0.7-0.85,是可以信赖的——但贵在每条 (claim, chunk) pair 都要过一次模型,4 条 evidence × 8 claim ≈ 32 次前向推理,延迟敏感场景需要蒸馏到 100M 参数的小模型。我们生产线上用的是 NLI-distilled 100M 模型 + T5-11B 在疑难 case 上 fallback,具体阈值由产品敏感度决定。

接驳信心最容易被忽视。模型生成的 claim 文本与 evidence span 文本之间的字面或语义重叠度,是"claim 是否真的来自这段证据"的直接信号。我们已经看到过太多"系统声称高信心,但 claim 文本与 evidence 完全不匹配"的尴尬。ROUGE-L 是个起点,但对长 claim + 短 evidence 时偏置严重;BERTScore F1 更鲁棒但慢;生产上常用的是 sentence embedding cosine + ROUGE-L 的几何均值——前者捕捉语义重叠,后者捕捉字面同源,几何均值对极端 case 不敏感。

校准完的 confidence 怎么呈现给用户?三个工程经验:第一,绝对数字不重要,相对排序重要——用户视觉系统对 0.73 和 0.78 没有差别,但对"这条比那条低"反应灵敏,UI 应把引用块按 confidence 排序而非按时间,让用户读到的是"系统认为更可信的先呈现"。第二,confidence 应匹配证据的视觉重量——高 confidence 引用块用粗实线下划线 + 满色,中用细实线 + 浅色,低用虚线 + 极浅色。三档视觉差异让人一眼看出"这段答案里哪些是不可动摇的事实,哪些是模型归纳,哪些是模型猜测"。第三,confidence < 0.4 的引用块应触发主动披露——系统主动写一句"这条答案的依据比较弱,建议你结合其他来源判断",这是把模型的不确定性如实告诉用户的设计哲学。

六、混合检索中的证据冲突仲裁:不让正确答案被多数票吞掉

混合检索的本质是让多个检索器独立投出"这块证据相关"票,然后融合。但这带来一个产品级噩梦:不同检索器返回的证据互相冲突时,系统如何作答。冲突仲裁是引用归因在 2026 年最重要的工程新领域,因为当你的应用从"一个文档库"扩张到"内部 wiki + 行业报告 + Slack + PDF 归档 + 实时数据"时,冲突概率从 1% 跳到 15-30%。

冲突的形态常见五种:数值冲突(Q1 增长是 17% 还是 19%);时间冲突(事件是 2024 还是 2025);立场冲突(报告 A 看好,报告 B 看空);来源冲突(官方与媒体口径不同);粒度冲突(月度数据与季度数据方向相反)。每种冲突的仲裁机制不一样——这是新手工程师常犯的错误,用同一种策略处理所有冲突,导致答案处处失真。

数值冲突、时间冲突、来源冲突的仲裁相对标准化:用权威性加权(内部 wiki / 官方文档权重大,Slack 留言 / 第三方新闻权重小)+ 时间新鲜度加权(近的证据权重高,远的低)+ 一致性加权(多源一致 > 单源孤立)。三权重几何均值是经典实现。但不要直接做加权投票——加权投票会奖励"信息重复的来源"(同一个报告被多路召回,本身就该权重小,而非越大),正确做法是先 source-level 去重,再去重后的源集合上做加权投票。

粒度冲突与立场冲突没有"标准答案",因为这两种冲突本质上反映了"系统到底要听用户的什么指令"——用户如果问"Q1 公司表现如何",他想要的是月度明细还是季度摘要?想要的是中性事实还是带观点的综述?正确的工程做法是把"冲突感知"暴露给产品决策层,而非让模型自己"硬选一个"。生产系统通常是这样设计的:模型生成的草稿先经过一个 conflict detector 模型(fine-tuned 二分类,识别 claim 是否处于证据冲突区),如果处于冲突区,系统的回答模板会自动切换为"分歧呈现"模式——明确告诉用户"X 报告说 A,Y 报告说 B",而不是强行投票给一个;只有冲突 detector 给出高确信"证据同向"才走"单答案"模板。

这种"主动披露冲突"在 2026 年的用户调研里是产品加分项而非减分项——它让用户感觉系统在"诚实"而非"敷衍",长期信任度反而提升。但它对模型团队的工程要求更高:草稿生成阶段的 prompt 必须是条件化的—— conflict score 高时切到"disclosure prompt",低时切到"synthesis prompt"。两套 prompt 的评测要独立做,互相不可替代。这个分叉设计是混合检索时代引用归因的标志性工程挑战。

七、引用反馈的数据飞轮:把每次点击变成再训练的微样本

引用归因系统的最终价值闭环,在于用户使用它的每一次动作,都能转化为系统的下一次改进。这条数据飞轮的工程化,远比想象中复杂。

飞轮的输入端是用户在引用侧的四个主要行为:click (点开引用块)、dwell (停留时间)、scroll within evidence (在证据内部阅读)、copy citation (复制引用格式)。四个行为的语义不同,权重也不同。click 是"用户想看",信号弱;click 后 dwell > 5s 是"用户看了且认可",信号强;scroll within evidence 是"用户细读",信号最强;但 copy citation 是"用户要拿去用",信号不仅最强,且有外部可验证性——用户复制粘贴后,系统可以用 NLP 反向检测"这段文字是否出现在外部场合",这是真正的"引用成功率"指标。

飞轮的转化端需要把这四类信号映射到模型训练样本上。我们生产线上用的标注规则是:click + dwell > 5s 的 (claim, evidence) pair 标为 +1(用户接受),click + dwell < 2s 后频繁 reopen 标为 -1(用户存疑),scroll within evidence 标为 +2(用户深入采纳),copy citation 标为 +3(用户外用采纳)。负样本 -1 主要来自另一类行为:report (用户主动标记"这条引用不对")——产品 UI 必须提供"举报引用"的入口,这是飞轮最珍贵的负反馈信号。

飞轮本身是一个监督学习循环,每周一次重训。具体流程:第一步,采集上一周的 (claim, evidence, user_action) 集合,按上述规则生成带权重的训练样本;第二步,用这些样本微调一个"接驳判断"模型(判断"claim 是否真的来自 evidence")和一个"引用排序"模型(学习 to rank 用户最可能信任哪条 evidence);第三步,把微调后的模型部署到影子流量,先做 AB 对照再全量;第四步,把本周的训练样本归档,作为未来引用模型更新的主源。

这个循环跑三个月后,我们观察到引用模型的 calibration error 从 0.18 降到 0.07,接驳模型的 F1 从 0.62 提到 0.83,点击率从 18% 提到 31%。这不是飞跃式进步,但是稳态可信度的根本提升——它意味着系统的"声称有信心"开始越来越真的代表"用户后续能信"。

需要注意,这条飞轮不是免费的:它会带来冷启动偏差与流行度偏差。冷启动偏差在新系统上线时,样本极少,模型无法更新;通常需要人工种子标注 500-2000 条样本作为冷启动基座,这是一笔前期投入。流行度偏差会让高频引用块的样本爆炸、低频引用块饿死,需要在样本采集层做 stratified sampling——按 chunk 来源、按领域、按 claim 类型分层抽样,确保长尾也有机会被优化。这两个偏差不解决,飞轮会反过来伤害产品,而不是提升产品。

八、评测与回归:在线离线双层护栏

引用归因系统的最大风险是"静默漂移"——版本更新、embedding 升级、reranker 切换都可能让质量突然下降,但产品指标(用户日活、答案采纳率)的变化往往滞后 1-2 周才显现。这就需要离线评测集 + 在线 AB 双层护栏。

离线评测集应至少覆盖五种 query 类型:事实型(需要一个具体数字/日期)、归纳型(需要跨段综合)、对比型(需要并列不同来源)、冲突型(答案应主动披露分歧)、拒答型(系统应主动承认不知道)。每种 query 至少 50-200 条,答案是人工标注或领域专家背书的金标准。评测指标除了传统的 retrieval recall@k、generation EM/F1、answer faithfulness,引用归因系统应额外追踪三个指标:

Citation Precision——系统声称引用了某 evidence,evidence 是否真的支持该 claim?这一指标评估 claim-evidence 蕴含关系的正确率,是引用归因的"准确率"。

Citation Recall——答案里的所有 atomic claim,是否都被引用到至少一条 evidence?这一指标评估"是否有 claim 漏引",是引用归因的"召回率"。

Citation Calibration——系统的 confidence 数字,与实际用户认可率的校准度。期望校准误差 (Expected Calibration Error, ECE) 是常见指标。这一指标评估"声称的可信度是否对应真实的可信度",是引用归因的"校准度"。

任何一次模型/检索/UI 更新,三项指标必须同时不下降,否则即便其他业务指标上涨也不能上线。我们用 GitHub Actions 跑这套评测,任何 PR 触发 24 小时内自动跑完——这套 CI 已经在过去 6 个月里拦下了至少 4 次重大降级。

在线 AB 评估不能只看业务指标,必须看引用侧的具体信号:引用块点击率(engagement)、用户停留时间(quality proxy)、引用反馈举报率(mis-trust proxy)、引用对应答案采纳率(overall product value)。这四类指标的相对变化比绝对值重要——比如一次 embedding 升级让点击率涨 5% 但举报率涨 20%,这是失败的,因为用户是被"假象的信任"骗了。正确的决策框架是"四指标加权 + 显著性检验",权重由产品价值主张决定。

九、给 AI 应用工程师的工程清单

把全文压成一份可执行的工程清单,12 条按生产优先级排序:

1. chunk ID 必须稳定且可重定位——用 (doc_version, content_hash) 复合 ID,不要纯哈希也不要纯位置。版本变更时所有引用能重新映射。
2. 接驳信心必须有独立度量——ROUGE-L + sentence embedding cosine 几何均值,不要只用语言模型困惑度。
3. NLI 蕴含分低于阈值不立即丢弃——降权而非删除,因为背景证据对生成的隐式支撑常常被 NLI 误判。
4. confidence UI 用相对排序而非绝对数字——三档视觉差异(粗实线/细实线/虚线)+ 按 confidence 排序,用户一眼就能识别"哪些是事实,哪些是猜测"。
5. 证据边栏必须与答案同时呈现——不要放文末,边栏抽屉式是 2026 年 UX 共识。
6. 冲突检测器训练时标注所有冲突样本——包括"看起来不冲突但实际冲突",因为模型是按标注分数学的,标注不全就学不会披露冲突。
7. 披露冲突的 prompt 与综合 prompt 分离——两套 prompt 独立评测、互相不替代。
8. 数据飞轮必须有人工种子——冷启动期人工标注 500-2000 条样本,否则飞轮跑不起来。
9. 数据飞轮要 stratified sampling——按 chunk 来源、领域、claim 类型分层,避免长尾饿死。
10. 离线评测加 Citation Precision / Recall / Calibration——三个新指标必须同时不下降才允许上线。
11. 在线 AB 引入举报率与采纳率——单看点击率会陷入"假象信任"陷阱。
12. 每条证据都必须可被复制导出——引用格式 (BibTeX / Vancouver) 是用户外用采纳的前置条件,缺这条飞轮最强信号消失。

这份清单不是终点,是起点——任何 RAG 团队都应把这 12 条作为生产 checklist,在每个版本发布前跑一遍。能跑通不代表产品优秀,但跑不通一定会让产品在用户使用中显形。

参考文献

1. Lewis P, et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. NeurIPS 2020.
2. Borgeaud S, et al. Improving Language Models by Retrieving from Trillions of Tokens. ICML 2022.
3. Izacard G, Grave E. Leveraging Passage Retrieval with Generative Models for Open Domain Question Answering. EACL 2021.
4. Khattab O, Zaharia M. ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction over BERT. SIGIR 2020.
5. Nogueira R, et al. Multi-Stage Document Ranking with BERT. arXiv 2019.
6. Santhanam K, et al. ColBERTv2: Effective and Efficient Retrieval via Lightweight Late Interaction. NAACL 2022.
7. Glass M, et al. Re2G: Retrieve, Rerank, Generate. NAACL 2022.
8. Asai A, et al. Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection. ICLR 2024.
9. Ram O, et al. In-Context Retrieval-Augmented Language Models. TACL 2023.
10. Schick T, et al. Toolformer: Language Models Can Teach Themselves to Use Tools. NeurIPS 2023.
11. Mallen A, et al. When Not to Trust Language Models: Investigating Effectiveness of Parametric and Non-Parametric Memories. ACL 2023.
12. Ren Y, et al. Zero-Shot Generative Linguistic Steered Text Generation. arXiv 2023.
13. Wei J, et al. Chain-of-Thought Prompting Elicits Reasoning in Large Language Models. NeurIPS 2022.
14. Petroni F, et al. Language Models as Knowledge Bases? EMNLP 2019.

一句话摘要

从混合检索到用户可验证的端到端生产闭环,把 RAG 引用归因从直觉变成可计算的 evidence triple,把每次点击变成监督学习的微样本。