Blog

Retrieval-augmented generation for source-backed article writing

Naly 工程备忘录：以来源优先的 RAG 文章起草实现可持久化、可审计发布

本说明定义了一种生产架构，其中检索是一级控制平面，而非提示时的提示性提示。Naly 的文章任务会收集网络和 arXiv 证据，持久化标准化来源事实，并在渲染 HTML 前强制模型输出通过结构化、可审计的契约，以确保文章保持基于 re

June 27, 202610 sources

TL;DR检索增强生成（RAG）将 Naly 的文章流水线转变为以来源为基础的发布系统，而非模型记忆拼接。每个草稿请求都会先收集网络和 arXiv 证据，标准化并持久化来源 URL，随后要求模型先产出 answer-first 草稿和最终 HTML 文章。这样可将风险从“模型会不会幻觉？”转移为“检索层是否完整且可追溯”，从而为编辑提供稳定产物、可重放任务以及可辩护的公开主张。

摘要

Naly 的 RAG 应围绕 来源持久化与确定性约定构建。在2026年6月27日，实用可靠性更多来自检索产物是否可查询、可版本化，并在发布前完成校验，而不是模型更大。本文提出了双平面设计：一个用于检索/存储的证据平面，和一个用于起草的生成平面，并论证该架构如何直接提升编辑信任与故障处理。

Naly 中的位置

Naly 将其作为生产内容子系统运行在 Next.js 16.0.7 App Router 栈（next + react）中，其中文章发布是运行时代码路径的一部分，而非独立的离线写作步骤。文章任务路径是必须执行所有约束的地方：没有来源记录、摘要结构未通过验证和 HTML 未被实体化的文章不会被“写入”。

该栈对齐是有意为之：

  • next@16.0.7 + React Server Components 在服务端空间承载任务触发的渲染，与文章的服务端输出约定保持一致。
  • drizzle-orm@0.44.7 + @neondatabase/serverless@1.0.2 定义带类型的持久化作业和来源表，让每条声明可追溯。
  • ai@6.0.0-beta.105 为生成提供感知 Schema 的输出控制。
  • marked@17.0.1 将生成的 Markdown 摘要转换为发布用的 HTML。
  • @vercel/blob@2.0.0 将生成资产存储为持久 URL 以便复用。
  • Anthropic 工具可作为同一约束边界内的备用模型提供者加入，但不能成为规避结构化约束的逃生通道。

这将“先生成再校对”模型替换为 基于来源的写作闭环：检索、校验、生成、渲染和发布都必须通过，文章才会可见。

技术机制

一个稳健的 Naly 设计包含五个边界明确的阶段：

  1. 证据计划与查询编排
  • 用主题、时间窗口和证据策略定义作业规范。
  • 同时运行网络搜索和 arXiv 搜索以获取第一方来源。
  • 按规范化 URL 去重，并标准化协议、主机与查询字符串。
  1. 来源持久化层
  • 按每个 URL 存储元数据（url，规范化 URL、抓取状态、抓取时间戳、标题、摘要、来源类型）。
  • 将面向模型的片段与原始负载分离存储，即使上游页面变化也能让重跑结果保持确定性。
  • 为每个来源添加校验和以检测漂移。
  1. 上下文塑造与约束
  • 构建按相关性和时效性排序的检索上下文。
  • 在提示契约中要求显式来源 ID。
  • 强制 answer-first 输出形态（intro claim evidence bullets risk caveats uncertainty），并要求来源引用有序。
  1. 结构化生成与严格 schema
  • 使用结构化输出，让格式错误或违反 schema 的响应快速失败，并在上下文更严格时重试。
  • 将生成留在服务端上下文，拒绝声明未映射来源 ID 的不支持事实。
  1. 渲染、发布与验证
  • 将已验证的 Markdown 转为 HTML，并同时持久化 Markdown 和 HTML。
  • 仅在验证成功后缓存最终输出。
  • 输出分析与审计字段：来源数量、被拒主张、重试次数和生成延迟。

最关键的设计变化是 关注点分离：检索质量和生成质量是不同的故障域，具有不同指标。Next.js Server Components 适配这种拆分，因为渲染可以保持确定性，而检索与生成在受控异步任务中进行。

文献观点

近期 RAG 文献支持这一架构模式。一项 2024 年的 RAG 架构调查表明，检索增强系统通过将生成条件化于外部证据减少事实漂移，但也指出了流水线复杂度和模块协同方面的权衡 [Gupta et al., 2024]。一项 2025 年的后续调查补充称，当前鲁棒性取决于自适应检索、解码控制和端到端评估，而不再只依赖生成质量本身 [Sharma, 2025]。

在生产质量控制中，2025 年的评估导向调查明确将评估拆分为内部检索器/生成器指标与外部系统指标；该分解对文章流水线尤为有用，因为即使语言质量很高，“错误文章”也可能意味着来源选择错误 [Gan et al., 2025]。面向 groundedness 的研究也转向了检测层，使用检索上下文与类 NLI 检查对主张支持进行分类，进一步强化了生成后校验在实践中的价值 [Gerner et al., 2025]。

简而言之，这些论文在一个核心结论上趋同：RAG 不仅是注入上下文的方法，它更是一种 工程化约定 ，位于检索与生成之间。Naly 因而应优化这套约定，而不是只优化提示。

设计权衡

  • 新鲜度与确定性：更严格的 TTL 降低陈旧性但提高重抓取成本。持久化快照可在保持确定性渲染的同时，继续在窗口内重新验证新鲜度。
  • 检索中的召回率与精确率：更广的检索可提升覆盖率，但会引入噪声；二阶段相关性过滤可保护主张质量。
  • Schema 严格性与文案流畅性：严格的输出 schema 提高了机器可靠性，但可能减少文体自由度。answer-first schema 模式在保留可读性的同时保留护栏。
  • 静态渲染速度与可审计性：预渲染 HTML 能提升交付性能并减少重复计算，但前提是所用来源产物是不可变引用。
  • 复杂度与运维成本：每个新增校验环节（来源校验、schema 校验、产物持久化）都会带来延迟。下一步的生产实践中，缓存、路由边界和构建时校验的指导至关重要，以保持系统可运维。

故障模式

  • 来源漂移：URL 在任务创建后可能返回 404/软变更。缓解：规范主键 + 快照哈希 + 回退来源链。
  • 检索过度：高召回低精度会产生看似合理但缺乏支撑的综合结论。缓解：要求证据优先约束并阻断未匹配来源的声明。
  • 模型格式化失败：生成阶段出现 schema 不匹配或 JSON 截断。缓解：严格 schema 校验，并在上下文收紧后重试。
  • 双重发布竞争：并发 worker 可能发布了部分产物。缓解：作业幂等键、行级状态流转（pending -> drafting -> validated -> published）。
  • 渲染回归：格式不规范的 Markdown 或不安全的 HTML 转换。缓解：使用确定性的 marked 转换路径，并将 HTML 输出测试绑定到样本清单。
  • 缓存幻觉：服务端输出中的动态数据过期会导致已发布文本与来源索引不同步。缓解：将路由渲染策略与明确的运行时新鲜度策略对齐，并避免在需要证据新鲜度的场景下使用隐式缓存。

实施说明

为了落地，可将其视为发布契约：

  • 在 Drizzle 中定义带显式约束的来源表：按规范化 host/path 的 URL 唯一性、抓取状态枚举和校验和列。
  • 在无服务器执行行为下持续使用与 Neon 兼容的驱动路径；Drizzle 文档同时描述了运行时特定的 neon-* 和驱动选项。
  • 在生成阶段，执行结构化输出约束，并在渲染前对无效对象直接判失败。
  • 在生成时使用 Next.js 的生产建议，涵盖服务器边界、错误页面、缓存和文章路由 SEO 元数据，以保持发布可观测且快速。
  • 通过 Vercel Blob 持久化生成的二进制对象（如封面图、附件、导出文件），并使用明确的访问策略与确定性命名以避免冲突。
  • 发布前执行运营校验：最小来源数量、最小来源多样性、证据新鲜度，以及映射主张的最低完成率。

这是关键转变：文章不再按模型的聪明程度评分，而是按证据与生成是否在重试和重部署下保持同步来评分。

参考资料

Sources