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 設計包含五個受控階段：
- 證據計畫與查詢編排
- 以主題、日期區間與證據政策定義任務規格。
- 同時執行網頁搜尋與 arXiv 搜尋以取得第一來源。
- 依 canonical URL 去重複，並標準化通訊協定、主機與查詢字串。
- 來源持久化層
- 儲存每個 URL 的中繼資料（
url、正規化 URL、抓取狀態、抓取時間戳、標題、摘要、來源類型）。 - 將模型可見片段與原始載荷分開儲存，使重跑在上游頁面變動時仍保持可重現。
- 新增每個來源的校驗碼以偵測漂移。
- 上下文塑形與約束
- 建立依關聯度與新近性排序的檢索上下文。
- 在提示合約中要求明確的來源 ID。
- 強制採用 answer-first 輸出形態（
intro claim,evidence bullets,risk caveats,uncertainty），並加上有順序的來源參照。
- 以嚴格 schema 進行結構化生成
- 使用結構化輸出，讓格式異常或違反 schema 的回應快速失敗，並以更精準的上下文重試。
- 將生成保留在伺服器上下文中，並拒絕未提供對應來源 ID 的不支援事實主張。
- 渲染、發布與驗證
- 將已驗證的 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 可降低資料過期，但會提高重新抓取成本。持久化快照可在仍進行新鮮度窗口重驗證的同時，維持可重現的渲染。
- 檢索中的召回率 vs 精確率：更廣的檢索可提高覆蓋率，但也會帶入雜訊；第二階段相關性過濾能保護主張品質。
- schema 嚴格度 vs 文案流暢度：嚴格輸出 schema 提升機器可靠性，但可能降低文體自由度。answer-first schema 模式在保留護欄的同時，仍維持可讀性。
- 靜態渲染速度 vs 稽核性：預先渲染 HTML 可提升傳遞效能並降低重複計算，但前提是所用來源構件必須是不可變參考。
- 複雜度 vs 運維成本：每新增一個驗證步驟（來源檢查、schema 檢查、構件持久化）都會提高延遲。Next 生產指引中的快取、路由邊界與建置時驗證對維持可運行性至關重要。
失效模式
- 來源漂移：任務建立後 URL 變為 404 或軟變動。緩解：canonical key + 快照雜湊 + 回退來源鏈。
- 檢索過度擴散：高召回低精準會導致似是而非但未受支持的綜合結果。緩解：要求 evidence-first 約束，並阻擋沒有來源對應的主張。
- 模型格式失敗：schema 不符或生成 JSON 被截斷。緩解：嚴格 schema 驗證，並在縮減上下文後重試。
- 雙重發布競爭：並發 worker 可能發布部分構件。緩解：使用 job 冪等鍵、列層級狀態轉移（
pending -> drafting -> validated -> published）。 - 渲染回歸：Markdown 格式不當或不安全的 HTML 轉換。緩解：採用可重現的
marked轉換路徑，並以樣本清單（manifest）建立 HTML 輸出測試。 - 快取錯覺：伺服器輸出中的過時動態資料可能使已發布文字與來源索引不同步。緩解：將路由渲染策略與明確的執行時新鮮度政策對齊，並避免在需要證據新鮮度時使用隱含快取。
實作註記
在實務落地中，將其視為一個發布合約：
- 在 Drizzle 中定義來源資料表，採用明確約束：按 canonical host/path 的 URL 唯一性、抓取狀態枚舉與 checksum 欄位。
- 一致使用與 Neon 相容的驅動路徑，以配合 serverless 的執行行為；Drizzle 文件同時描述 runtime-specific 和
neon-*driver 選項。 - 在生成環節，強制結構化輸出合約，並在渲染前對無效物件直接失敗。
- 對文章路由使用 Next.js 的生產指引，涵蓋伺服器邊界、錯誤頁面、快取與 SEO metadata，讓發布可被觀測且保持快速。
- 透過 Vercel Blob 持久化生成的二進位物件（例如封面圖、附件、匯出檔），設定明確存取策略並使用可預測命名以避免碰撞。
- 在發布前輸出營運檢查：最小來源數、最小來源多樣性、證據新鮮度，以及已映射主張的最低完成率。
這是關鍵轉變：文章不再以模型聰明度來評判，而是以在重試與重新部署下，證據與生成是否始終同步來評估。