你如何在自由形式的 AI 写作与严格的事实可追溯性之间取得平衡？
摘要
一位实践者分享了自己在长文本生成系统中，难以兼顾大语言模型的自由写作与严格的事实可追溯性的经历，详细介绍了模板和结构化引用方案的失败尝试，并向社区询问：采用事后提取论断并进行核验的架构，在生产环境中是否效果更好。
我正在开发一个长篇大语言模型（LLM）生成系统，要求输出文笔出色、事实准确，并且能够追溯到源文档。难点在于平衡两件事：准确性：每一个财务数字都必须正确，并且能够追溯到原始来源。一个错误的数字就可能让整份申请功亏一篑。写作质量：模型必须写出有说服力的叙述，而不只是重复提取出的事实。应当允许合理推断，但不能编造信息。我们尝试过两种方法。尝试一：严格模板。每个句子都必须由预定义的文案和事实引用构成。数字有了保障，但文字机械、重复，缺乏说服力。模型无法展开像样的论证。尝试二：自由写作，附带结构化引用（当前方案）。Python 提取事实并填充表格。LLM 自由撰写叙述部分，但必须返回 JSON，其中包含正文、句子级脚注，以及每个数值的声明信息。Python 验证器根据数字所声明的来源进行核验。另有独立的 LLM 智能体审阅叙述、修复被标记的句子，并评估最终申请材料。这提高了写作的灵活性，但也带来了新问题。我们目前遇到的瓶颈：记录负担过重：在一次包含 295 个句子的测试中，285 个句子带有脚注，其中 98 个句子根本没有数值。内部元数据占存储字符总量的 52%，比正文还多。核验过于严格：我们的编辑智能体会否决合理推断，因为文档中没有明确写出这些内容。例如，一家公司在 2019 年开展过出口业务，并且有记录证明其在 2024 年和 2025 年也有出口。“该公司自 2019 年以来一直向海外销售产品”这句话会被否决，因为没有明确的文档证明其业务从未中断。内部备注泄漏：模型有时会把它列出的缺失信息清单复制到正式申请材料中。评估缓慢且噪声大：完整运行一次需要 25–45 分钟，而我们的 LLM 评审团对相同文本给出的评分并不一致。我们正在考虑：也许写作与核验应该分开进行：- 让写作模型输出纯文本，不附带引用元数据。- 随后提取原子事实主张。- 将每项主张关联到原始证据。- 使用确定性方法核验数值主张。- 区分直接事实、推导事实、合理推断和缺乏依据的主张。- 独立于生成文本维护一份内部证据台账。想请教构建过类似系统的人：你们是在写作过程中生成引用，还是事后为主张匹配来源？哪种方式在生产环境中效果更好？如何在不强迫写作模型生成来源引用的情况下保证数字准确？如何区分合理推断与缺乏依据的主张，同时又不让写作过于保守？要求逐句输出严格的 JSON，会损害写作质量或增加延迟吗？你们是否改为先生成纯文本，再单独进行一轮结构化处理？当 LLM 评审的判断不一致时，如何可靠地评估长篇生成内容？我不是在寻找提示词工程技巧。我是在质疑我们的架构是否从根本上就有问题。希望能听到真实的生产实践经验，或了解相关研究论文、开源项目，以及解决过类似问题的系统案例。你们尝试过哪些方法，包括那些失败的方法？
相似文章
发布AI生成的软件（8分钟阅读）
一篇探讨发布AI生成软件之影响的博文，起因于 Robert C. Martin 的观点——他表示自己不再阅读AI智能体编写的代码，而是依赖测试和约束条件，文章由此展开了关于认识论、验证以及当大语言模型（LLM）生成代码时的责任归属等问题的讨论。
证据账本裁决：实现主张-证据可追溯性
本文介绍了证据账本裁决（evidence-ledger adjudication），一种用于AI辅助写作中主张-证据可追溯性的工作流，并在基于AVeriTeC、CLIMATE-FEVER和SciFact构建的盲测基准上进行了评估，结果表明基于智能体的方法优于基线方法。
我运营着一个基于AI的事实核查平台，却坚决不让大语言模型给出最终判定。以下是我的理由。
作者详细阐述了不让LLM生成最终事实核查判定的决定，转而采用混合架构：LLM负责数据提取，确定性Python层负责评分，并指出了随机不稳定性和可审计性的问题。
ProvenAI：生成答案中的溯源原生证据追踪
ProvenAI 提出了一种框架，将多跳问答中的透明度分解为三个可独立衡量的层次：答案正确性、引用忠实度和每文档影响力，揭示了一个引用-影响力差距，即被引用的来源可能影响力较弱，而未引用的来源却显著影响输出。
# Agent 安全：溯源标签与致命三角（Lethal Trifecta） ## 致命三角概述 致命三角是指 AI Agent 中三个危险因素的组合： 1. **不可信输入（Untrusted Content）** — 用户输入、网页内容、邮件正文等外部数据 2. **私有数据访问（Private Data Access）** — 本地文件、API 密钥、数据库凭据、内部通信 3. **数据外泄能力（Exfiltration Channel）** — 网络请求、发送邮件/消息、写入外部系统 当三者同时存在时，攻击者可以通过在不可信内容中注入指令，让 Agent 读取私有数据并通过外泄通道发送出去，即 **提示注入（Prompt Injection）导致的数据泄露**。 ## 常见问题 ### 致命三角相关 - **提示注入**：攻击者在网页、文档、邮件中嵌入隐藏指令，劫持 Agent 行为 - **上下文污染**：不可信内容未经区分地混入上下文窗口 - **权限过宽**：Agent 同时拥有文件读取、网络访问和消息发送权限 - **缺乏审计**：无法追踪 Agent 到底访问了什么数据、执行了什么操作 ### 溯源标签相关 - 缺乏对数据来源的标记，难以区分可信与不可信内容 - 难以追溯 Agent 行为链条中的每一步决策依据 - 多 Agent 系统中信息流转缺乏透明度 ## 常见解决方案 ### 破解致命三角 - **打破三角中的至少一条边**： - 限制外泄通道（网络白名单、禁止 Agent 直接发送数据） - 隔离私有数据（沙箱、最小权限原则） - 标记并隔离不可信输入（与可信指令分离） - **人类确认（Human-in-the-loop）**：敏感操作需人工审批 - **能力边界（Capability Boundary）**：通过系统级权限控制而非仅靠提示词 ### 溯源标签（Provenance Tags） - 为每条上下文内容添加**来源标签**（如 `system`、`user`、`web`、`email`） - 使用**标记化（tagging）** 在上下文中明确区分可信指令与不可信数据 - 实现**操作审计日志**，记录 Agent 的每次工具调用和数据访问 - 在多 Agent 架构中使用**消息签名和溯源链**追踪信息流转 ### 最佳实践 - 采用**零信任架构**：默认所有外部输入都不可信 - **最小权限原则**：Agent 只获得完成任务所需的最小权限 - **输出过滤**：在数据离开系统前检测是否包含敏感信息 - **红队测试**：持续对 Agent 进行提示注入攻击测试
一位正在开发 AI 安全库的开发者讨论了解决“来源标记（provenance tagging）”以及“致命三要素（lethal trifecta）”（跨操作的信息流违规问题）的不同思路，权衡了硬编码规则、输出过滤和防护栏（guardrails）等方案，最终将一个原型部署到了 AI 简历筛选工作流中。