摘要
檢索增強生成讓 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 綜述把這個想法推廣為一套分類法：naive RAG、advanced RAG 與 modular 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 用於模型編排，使用網路與 arXiv 檢索工具收集證據，並使用搭配 Neon 的 Drizzle ORM 來處理文章與來源記錄， marked@17.0.1 用於 Markdown 到 HTML 的渲染，並以 Next.js 16 作為發布介面。
資料庫應把來源視為一級資料列，而不是一團 Markdown 文字。實用的結構包含文章表、文章與來源的聯結表，以及來源欄位：URL、標題、來源類型、檢索時間戳、可用時的標準識別碼例如 arXiv ID，以及擷取狀態。文章記錄接著可以指向 Markdown、渲染後的 HTML、摘要、重點與發布中繼資料。
Vercel Blob 適合較大的成品或不可變的渲染輸出，而 Postgres 仍更適合作為可查詢的來源與文章中繼資料帳本。這種分離讓稽核查詢成本保持低廉：列出使用某個來源的每一篇文章、某篇文章使用的每一個來源，以及來源擷取失敗的每一篇文章。
生成器提示應在輸出形狀中要求來源紀律：不能有未受支撐的聲明、不能編造 URL，且參考資料區段中的連結必須符合持久化來源清單。模型可以寫出流暢文字，但任務本身應掌握來源真相。如果模型輸出未被檢索到的參考資料，驗證器應讓文章失敗，而不是悄悄發布。
最後，生產行為很重要。Next.js 已經提供伺服器元件、程式碼分割、預渲染與快取預設值，但生成內容管線仍需要明確的錯誤處理、安全檢查、中繼資料，以及對 Core Web Vitals 的關注。RAG 幫助 Naly 以證據寫作。生產工程則確保這些證據能快速、安全、反覆地抵達讀者。