摘要
检索增强生成为 Naly 的文章流水线提供了一种研究记忆，它比单靠模型权重更新鲜，也更可审计。对于每个工程笔记或市场情报文章任务，系统可以搜索网页和 arXiv，将来源 URL 与生成产物一同保留，要求模型先给出答案，再将结果渲染为 HTML。重点不是为了自动化而自动化；而是发布读者可以追溯的声明。
论点很简单：用于文章写作的 RAG 应被视为生产级证据系统，而不是聊天机器人模式。聊天机器人给出薄弱回答还可以被原谅；已发布文章则会成为持久的信任界面。因此，Naly 的实现需要三个不变量：起草前先检索、发布后仍保留的来源记录，以及既保留可读 Markdown 又避免不安全 HTML 的渲染器。
它在 Naly 中的位置
Naly 的文章任务位于研究获取和公开发布之间。任务从选定主题开始，生成搜索意图，抓取网页和 arXiv 材料，将结果规范化为来源记录，然后要求模型基于这组有限证据撰写答案优先的文章。输出不只是散文，而是一个包：Markdown 内容、渲染后的 HTML、来源 URL、来源标题、来源类型，以及足以解释每个来源为何被使用的元数据。
这关系到 Naly 的信任循环。Naly 更广泛的编辑姿态是发布别人隐藏的内容：决策备忘录、校准限制、失败，以及声明背后的证据。有来源支撑的生成让这种姿态变成可操作流程。读者不应被迫猜测某个陈述来自模型训练数据、官方文档、论文，还是操作员断言。
RAG 层应位于起草之前，而不是之后。事后附加引用更弱，因为模型已经形成了声明。在更强的设计中，检索会约束生成上下文，而生成会产出可根据检索集合核查的声明。可见文章可以保持简洁，但存储的产物应保留研究轨迹。
技术机制
对于文章写作，Naly 的 RAG 流程是一条批处理流水线：
- 主题选择创建一个有边界的研究问题，例如检索增强生成如何为有来源支撑的文章写作提供依据。
- 查询规划将该问题扩展为网页查询、官方文档查询和 arXiv 查询。
- 检索会收集官方文档、主要论文和高信号解释性来源。
- 规范化会提取标题、规范 URL、来源类型、可用时的发布或更新背景，以及相关片段或摘要。
- 来源持久化会在生成前存储 URL 台账，以便日后审计文章。
- 提示组装会向模型提供主题、Naly 特定实现事实、写作约束和检索到的证据。
- 生成会产出 Markdown，其中包含答案优先的摘要、明确的失败模式和参考文献部分。
- 验证会检查渲染后文章中的每一条引用是否映射到已存储的来源对象。
- 渲染会将 Markdown 转换为站点所需的 HTML，同时应用清理和生产检查。
这接近 Vercel 的 RAG 指南中描述的检索和增强生成模式：先检索相关上下文，再在生成前将其与用户或任务问题结合。区别在于，Naly 优化的不是对话式支持，而是持久发布，在这种发布中，来源 URL 是文章数据模型的一部分。
AI SDK 是这类任务的自然编排层，因为它的文本生成接口支持非交互式自动化、工具调用、多步骤结果，以及在提供商返回 URL 来源时支持来源元数据。即使提供商不返回原生来源对象，Naly 也可以将自己检索到的来源列表附加到文章产物上，并把模型原生来源视为补充而非权威。
文献怎么说
Lewis 等人最初的 RAG 表述很好地界定了核心问题：参数化语言模型将事实存储在权重中，但更新这些知识和提供出处仍然困难。他们的检索增强模型将序列模型与密集向量索引结合起来，并发现，在知识密集型任务上，相比只依赖参数的基线，它能生成更具体、更多样且更符合事实的内容。
Gao 等人后来的 RAG 综述将这一思路推广成一种分类法：朴素 RAG、高级 RAG 和模块化 RAG。Naly 的文章流水线应当是模块化的。检索、排序、来源持久化、提示构建、生成、引用验证和渲染是独立单元，各自有独立的失败模式。将它们视为独立单元，会让系统在文章引用薄弱来源或遗漏更好来源时更容易调试。
Self-RAG 增加了一条重要警示。Asai 等人认为，无论是否需要检索都检索固定数量的段落，可能会降低输出质量。对 Naly 来说，这意味着 top-k 检索不应成为仪式。一篇关于稳定框架特性的短文可能只需要官方文档和一篇论文；一篇文献密集型文章可能需要多个 arXiv 来源和一篇综述。检索深度应随声明风险而定。
RAGChecker 给出了评估层面的教训。Ru 等人认为，RAG 系统需要在检索和生成两端进行细粒度诊断，尤其是在长篇回答中。对 Naly 来说，评估单位不应只是文章质量。它还应包括检索召回率、来源相关性、声明支撑度、引用覆盖率，以及是否有未获支撑的声明滑入最终 Markdown。
设计权衡
高召回率与低噪声是核心权衡。更多检索会提高找到正确来源的机会，但也会增加薄弱片段进入提示并引导模型的概率。Naly 应倾向于分阶段方法：广泛收集、严格过滤，然后压缩提示上下文。
来源持久化提升可审计性，但也带来存储和维护工作。URL 会漂移，论文会修订，文档页面会迁移。持久记录应包括规范 URL、抓取时间戳、标题、来源类型，理想情况下还应包括内容摘要或摘录边界。这让 Naly 能区分模型错误和来源变更。
答案优先的写作提升读者价值，但也可能过度压缩不确定性。文章应以结论开头，同时保留后续章节说明失败模式和注意事项。答案优先摘要是入口，而不是抹平证据的许可。
渲染后的 HTML 改善分发和阅读体验，但也形成安全边界。Marked 对 Markdown 解析快速且有用，但其文档明确警告它不会清理输出 HTML。Naly 的文章渲染器应清理生成的 HTML，并保留可信的 Markdown 源以便重放。
失败模式
检索遗漏：搜索步骤找到了看似合理但不完整的来源。这通常发生在查询规划器过窄，或使用了与文献不同的产品术语时。缓解措施：使用多种查询风格，纳入官方文档，并在文章提出研究声明时要求至少两个主要来源或 arXiv 来源。
引用洗白：某个来源出现在参考文献中，但实际上并不支持其附近的句子。这比没有引用更糟，因为它制造了虚假的信心。缓解措施：根据来源片段验证声明，并拒绝那些引用只是主题相关的文章。
陈旧来源漂移：官方文档页面在发布后发生变化。缓解措施：在生成时持久化来源元数据并记录日期标签。对于支撑重大声明的来源，在许可允许的情况下存储快照或摘要。
过度检索：过多分块会让模型总结上下文，而不是回答文章论点。缓解措施：使用来源排序，去重近乎相同的文档，并根据声明相关性而不是原始数量限制提示证据。
上下文污染：垃圾页面、生成式 SEO 页面或低质量摘要的排名超过主要材料。缓解措施：将官方文档、arXiv、标准和源码仓库排在二级评论之上，除非文章明确讨论行业反响。
渲染器风险：生成的 Markdown 可能包含原始 HTML、不安全链接或格式错误的表格。缓解措施：清理渲染后的 HTML，规范化链接，拒绝可脚本化内容，并运行符合 Next.js 关于性能、安全、元数据和可访问性指导的生产检查。
实现笔记
鉴于 Naly 当前的运行时事实，清晰的架构是一个 TypeScript 作业，它使用 ai@6.0.0-beta.105 进行模型编排，使用 Web 和 arXiv 检索工具收集证据，使用 Drizzle ORM 与 Neon 存储文章和来源记录， marked@17.0.1 进行 Markdown 到 HTML 渲染，并使用 Next.js 16 作为发布界面。
数据库应将来源视为一等行记录，而不是一团 Markdown 文本。一个实用的 schema 包含文章表、文章-来源关联表，以及来源字段，包括 URL、标题、来源类型、检索时间戳、可用时的规范标识符如 arXiv ID，以及提取状态。随后，文章记录可以指向 Markdown、渲染后的 HTML、摘要、要点和发布元数据。
Vercel Blob 适用于更大的产物或不可变渲染输出，而 Postgres 仍更适合作为来源和文章元数据的可查询台账。这种分离让审计查询成本较低：列出使用某个来源的每篇文章、某篇文章使用的每个来源，以及来源提取失败的每篇文章。
生成器提示应在输出结构中要求来源纪律：不得有无支撑声明，不得编造 URL，并且参考文献部分的链接必须与持久化来源列表匹配。模型可以写出流畅的散文，但任务本身应掌握来源真相。如果模型输出了一个未被检索到的引用，验证器应让文章失败，而不是悄悄发布。
最后，生产行为很重要。Next.js 已经提供服务器组件、代码拆分、预渲染和缓存默认值，但生成内容流水线仍需要明确的错误处理、安全检查、元数据和 Core Web Vitals 意识。RAG 帮助 Naly 用证据写作。生产工程确保这些证据快速、安全、反复地到达读者。