預生成上下文：重構RAG的關鍵工程，構建AI程式設計底座

2025-06-26 20:19 phodal

在上一篇文章《AI 友好架構：平臺工程賦能 AI 自動程式設計》，我們提及了 DevOps 平臺應該大量的預先生成專案、模板、上下文等資訊。在這一篇文章中， 我們將詳細展開其中的一個核心實踐：預生成上下文。
最近的幾個月裡，預先生成上下文在 AI 編碼領域成為了一個熱門話題，或者說技術趨勢。開發人員受益於這些 AI 生成的 Wiki，用於 快速理解開源專案的用途、技術架構。儘管，從理解深度來說，現在的基於 RAG、文件檢索的方式還有待提升，還需要加入基於 AST 的上下文分析，來 提升準確度和覆蓋度。但是從效率上來說，預生成上下文的方式已經成為了一個趨勢。
因此，我們開始為 AutoDev 開發一個新功能 Context Worker，旨在透過預生成上下文來提升 RAG 的效果。如果你對這個功能感興趣，歡迎加入我們的 GitHub：https://github.com/unit-mesh/autodev-work

引子：誰都會，但誰都做不好的 RAG

2023 年，LangChain 框架的出現從某種意義上簡化（也從某種意義上覆雜化）了 AI 應用的開發，RAG （Retrieval Augmented Generation） 也成為了一個熱門的應用開發領域概念。RAG 的核心思想是將檢索和生成結合起來，透過檢索相關資訊來增強生成模型的能力。

技術因素：不確定的 RAG，隨機的模型生成

RAG 流程中的每一個環節都可能引入變數，這些變數累積起來，形成了影響最終效果的“不確定性鏈條”。
通常，主流的 RAG 實現包含兩個主要階段：
  1. 索引階段。將非結構化、結構化的資料（個人無法理解）以某種拆分方式拆分，進行向量化（可選），儲存到資料庫中。
  2. 檢索階段。對使用者的輸入進行轉換，進行向量化（可選），在資料庫中進行檢索，返回相關的上下文資訊，再經過一定的處理（可選），傳遞給生成模型進行生成。
這個過程中存在大量的不確定性因素，導致了 RAG 的效果往往不如預期。
索引階段：知識庫構建的質量直接決定了後續檢索的上限。其核心難點包括：如何合理分塊以保留語義完整性（尤其是程式碼邊界）、 選擇合適的嵌入模型進行向量化、以及針對多源資料進行有效預處理，避免“垃圾進、垃圾出”。
檢索階段的挑戰：即使使用者查詢意圖明確，從索引中高效準確地找到相關資訊也非易事。精準檢索需解決查詢歧義、提升搜尋能力（如混合搜尋、HyDE）、 進行結果重排序(Re-ranking)，並控制上下文長度以防資訊丟失或干擾生成。
最後，由於 LLM 本身在生成回覆時也會引入隨機性。模型對查詢意圖的理解以及對檢索到的上下文資訊的解讀都可能存在偏差，這導致即使輸入完全相同， 輸出結果也可能不一致或不準確。RAG 系統非常依賴外部資料的質量和相關性；如果檢索過程出現偏差，生成階段的質量必然會受到影響。

業務因素：大量的垃圾知識在影響到 RAG 的效果

去年，我們在與大量企業交流時發現：企業中海量的文件和程式碼（“文件太多”）帶來了重大挑戰。程式碼的版本化和文件的版本化方式是不一致的。通常來說，你 在流水線上透過的程式碼就是可以 work 的，但是你很難從 04-03.docx 和 修訂版12.docx 中判斷出哪個是最新的版本。即使你能判斷出哪個是最新的版本，你也很難判斷出這個版本是否是正確的版本。
因此，質量參差不齊（“質量不齊”）進一步使問題複雜化，因為模型在即時處理時可能會從次優或錯誤的示例中學習或檢索資訊（使用者查詢）。如果引導不當，生成式 AI 可能會產生有害的、虛假的或剽竊的內容，當輸入資料龐大且未經整理（即未經過預處理和篩選）時，這些風險會放大。
在這種文件資料背景下，即使擁有最優秀的文字分塊、向量嵌入和檢索演算法，它們也只能在充滿噪聲、過時或錯誤的資料之上執行。其結果是，RAG 系統非但不能解決企業原有的資訊混亂問題，反而可能延續甚至放大這些問題。

程式碼檢索：從結構化檢索到 DeepWiki

生成式 AI 能很好解決建立新專案的問題，但是對於理解和修改存量的程式碼，依然會有大量的挑戰。在軟體工程師和 AI 研究員各自有各自不同的思考， 工程師講究的是經典的工程化思維，AI 更多的是大力飛磚的新一代方式，兩種思維方式在過去的幾年裡不斷的交融。
當前主流的 AI 程式設計工具在程式碼檢索方面採用了多樣化的策略，它們通常結合了傳統的基於關鍵字和結構的方法與新興的 AI 技術，以期在速度、準確性和上下文理解之間取得平衡。

關鍵資訊檢索：工程思維與結構化索引

當你的檢索需要在客戶端執行的時候，你需要考慮到效能和效率的問題。你需要考慮到如何在本地的機器上進行高效的檢索，而不是依賴於雲端的計算能力。
而程式碼本身是結構化的，但是並不意味著主流的程式碼檢索方式是結構化的。我們在之前的文章中提到過，主流的程式碼檢索方式有兩種：
  • 基於關鍵資訊的檢索：如 Cline、Copilot、Cursor 等
  • 基於程式碼和文字的檢索：如 Bloop、SourceGraph Cody 等
而從現有的方式來看，主流的是基於關鍵資訊的檢索方式。諸如於：
  • Cline：AST（抽象語法樹） + 正則檢索
  • Copilot（2024）：生成關鍵詞 + TreeSitter AST（抽象語法樹）中的關鍵資訊（類、方法名等）搜尋
  • Cursor：Ripgrep 文字搜尋 + 雲端的向量化
  • Continue：基於 SQLite 的文字搜尋 + LanceDB 本地向量化
  • ……
簡單來說，它們都是基於關鍵資訊來進行檢索的，只需要對程式碼的類名、方法名、變數名等進行檢索即可。所以，使用者的輸入是一個關鍵詞，或者是一句話，再交由 模型來轉換成查詢條件，最後交給模型總結即可。
不過，關鍵詞檢索速度快，但其對使用者意圖的理解有限，容易產生不相關的結果。而基於抽象語法樹的檢索雖然能理解程式碼結構，但在處理語義相似性方面存在不足。

關鍵文件生成：預生成程式碼庫文件

當你的檢索可以在雲端執行的時候，又需要考慮到效能和效率的問題，預先生成文件就變成一個非常好的方案：它可以解決存量大量文件的老舊問題，並且可以 提升非常高效的檢索效率。
如下是我們結合 DeepResearch 調研的：程式碼文件工具中預生成策略對比分析
如我們開頭所說，儘管從理解深度來說，現在的基於 RAG、文件檢索的方式還有待提升，但是一旦成為技術趨勢，那麼就會有大量的工具和平臺開始支援這個趨勢。
而這些工具在面對複雜或包含隱式邏輯的程式碼時，由於缺少準確的程式碼關聯關係，對於缺少文件或者大型專案來說，就變得非常有限。
與之相似的，在模型能力進一步加強之後，AI 友好的文件也是一個非常重要的話題。文件中的程式碼準確性就變得更加重要，錯誤的文件和知識，剛會 讓你的 AI 助手變得難以信任。

預生成上下文

預生成上下文是指在使用者發起查詢或生成請求之前，系統針對特定程式碼倉庫、文件或 SDK，離線構建一組結構化的上下文資料。這些上下文經過理解、 加工與組織，使其在執行時能夠被快速檢索和引用，從而提升程式碼智慧體在生成、解釋或檢索程式碼時的準確性、相關性和響應速度。
其核心要素包含：
  • 文件與程式碼的抽取與解析：包括 API 文件、原始碼註釋、示例程式碼、變更日誌等；
  • 語義理解與摘要生成：提取關鍵能力、用途、限制等元資訊；
  • 向量化與索引構建：為快速語義檢索構建 embedding 索引；
  • 版本繫結與內容更新策略：確保上下文始終與特定版本保持一致；

AutoDev 探索：AutoDev Context Worker

基於上述的想法和研究，我們開始構建 AutoDev Context Worker。結合我們的 AutoDev IDE 外掛的能力，以下是我們的基本思路：
  • 深度專案解析與 AST 構建結構化，Context Worker 對整個專案（或指定的模組範圍）進行深度解析。這包括構建完整的 AST，識別所有的函式、類、介面及其簽名、註釋（docstrings）。同時，分析專案依賴（內部模組間和外部庫依賴），構建初步的依賴圖。
  • 自動化程式碼摘要與“意圖”標註：對於缺乏良好註釋的程式碼塊（函式、複雜邏輯段），嘗試使用 LLM 預先生成簡潔的摘要或“意圖描述”。對於一些關鍵的架構元件或核心演算法，可以預先打上特定的標籤或元資料。
  • 構建專案級知識圖譜：將解析出的程式碼實體（類、函式、變數等）及其關係（呼叫、繼承、實現、引用等），並圍繞領域模型構建知識圖譜， 標註實體的語義和上下文資訊。
  • ……
透過這些預計算和預組織工作，Context Worker 旨在為 AI 輔助研發功能（如程式碼生成、缺陷修復、程式碼重構、需求理解等）提供高質量、即時可用、 深度結構化的上下文。解決了傳統 RAG 在處理複雜程式碼時可能出現的上下文不完整、不準確、檢索效率低等問題，從而更好地實現 “AI 友好架構”的理念， 賦能更高級別的 AI 自動程式設計能力。

總結

本文探討了預生成上下文作為增強 AI 程式設計能力的關鍵機制。傳統 RAG 方法面臨的不確定性和知識質量問題，使得預生成上下文成為一種更可靠的替代方案。透過對比分析了當前程式碼檢索方法的侷限性，我們看到基於關鍵資訊檢索雖快速但理解有限，而 DeepWiki 等預生成文件工具雖有進步但在處理複雜程式碼邏輯時仍有不足。
預生成上下文代表了 AI 友好架構的重要實踐，它將傳統軟體工程的結構化思維與AI大模型的生成能力相結合，為下一代智慧程式設計工具鋪平了道路。透過主動構建而非被動檢索程式碼上下文，我們能夠更好地賦能AI理解和修改現有程式碼庫，使開發者能夠更專注於創造性工作，而非重複性任務。


相關文章