?LangGraph 助力代碼生成新境界
研究初衷
在大型語言模型（LLMs）的眾多應用中，代碼生成與分析尤為關鍵，這從產品 GitHub co-pilot 的廣泛應用和 GPT-engineer 等項目的熱度可見一斑。AlphaCodium 的最新進展展示出，與傳統“提示-應答”方法不同，“流程”式編程通過測試與反思答案，進而迭代改進，能更好地推動代碼的生成。
AlphaCodium 的流程法則
我們最近推出了 LangGraph，這是一種以圖表形式表示與設計流程的工具。受到 AlphaCodium 和 Reflexion 工作的激勵，我們想借助 LangGraph 在代碼生成中實現類似的迭代循環和關鍵決策點。
具體而言，我們試圖構建并比較兩種架構：
- 基于提示與上下文填充的代碼生成
- 涉及校驗執行代碼的流程化代碼生成，出現錯誤時能自我糾錯
這個嘗試旨在探究：這種代碼檢驗能在多大程度上提升代碼生成系統的性能？
結果如何呢？
??
?與僅進行單次生成的基本方法相比，涉及校驗與自我修正的系統展現出顯著進步（ 81% 對 55% ）
問題背景
為了在有限的文檔庫上展示代碼生成能力，我們選擇了 LangChain 的文檔子集，著重于 LangChain 表達式語言（LCEL），其范圍小（大約 60k 標記）且備受關注。我們篩選了連續 30 天的 ??chat-langchain??? 中與 LCEL 相關的問題（代碼在此）。從 ??>60k 聊天記錄??? 共篩選出 ??~500?? 條提到 LCEL 的記錄。我們對這約 500 條記錄進行聚類，由 LLM（GPT-4，128k）歸納總結，以得出每個類別中的代表性問題。每個問題我們都進行了手動審核，并制定了標準答案（含 20 個問題的評估集在這里）。我們把此數據集加到了 LangSmith。
生成 LCEL 教材評估集合流程
利用 LangGraph 進行反射式代碼生成
我們設計并實踐了一個包含如下環節的代碼生成流程：
- 受到長上下文 LLMs 的新動向啟發，我們利用 GPT-4（128k 令牌上下文窗口）的能力將 60k 令牌的 LCEL 文檔詳盡填充。我們向經處理過的 LCEL 鏈條提交 LCEL 相關問題，以啟動初步答案的生成。
- 我們使用 OpenAI 工具對成果進行了解析，將輸出轉化為擁有三個部分的 Pydantic 對象：（1）問題描述，（2）導入模塊部分，（3）代碼本體。
- 我們首先對導入模塊進行執行測試，因為我們曾發現在代碼生成過程中，幻覺可能悄然滲入導入語句之中。
- 導入模塊測試通過后，我們接著確認代碼本身是否可執行。在代碼生成時，我們特別指導 LLM 防止代碼中出現偽代碼或未定義變量，以確保代碼能夠被執行。
- 其中，若上述任一測試失敗，我們就會將錯誤堆棧與先前的回答一起傳回生成環節以供反思。默認我們會重試 3 次，當然這個次數根據需求還可以增加。
集錯誤檢測、反饋及反思于一體的 LangGraph 代碼執行流程
利用 LangSmith 進行的評估
我們設立了不涉及 LangGraph 的 “上下文填充” 基準線，即在我們的流程圖中這一環節并未執行任何檢測或反饋：同樣利用 GPT-4 的 128k 令牌上下文窗口，我們將 60k 令牌的 LCEL 文檔進行充實。我們提交了與 LCEL 相關的問題以生成答案。
我們為兩個部分
（1）導入模塊的評估
（2）代碼執行的評估
實現了 LangSmith 的自定義評價功能。
我們在 “上下文填充” 的 20 個問題評估集上進行了四輪評估。評估結果在此。通過上下文填充進行的評估表明 ??~98%??? 的導入模塊測試是準確的，而代碼執行成功率約 ??~55%???（??N=79?? 次成功嘗試）。
我們通過 LangSmith 分析了失敗的案例：案例分析，一個典型的錯誤是沒能注意到 ??RunnableLambda??? 函數的輸入應當是 ??dict???，反而將其誤認為 ??string???：??AttributeError: 'dict' object has no attribute 'upper'??
接下來，我們對“通過上下文填充 + LangGraph”的情況進行了測試，通過執行測試以篩查導入和代碼執行中的錯誤，并在生成更新的答案時進行反思。在相同的評估集上，我們觀察到 ??100%??? 的導入測試是準確的，以及 ??~81%??? 的代碼執行測試是成功的（??N=78?? 次嘗試）。
以上述失敗案例為例，我們可以看到系統是如何進行處理的：完整的錯誤跟蹤顯示，我們在回答問題的第二次嘗試中遇到了同樣的錯誤詳情。在后續的反思環節中，我們提供了先前的解決方案和隨之出現的錯誤：
您之前嘗試解決過這個問題。
...
--- 最近的運行錯誤 ---
執行錯誤：'dict' 對象沒有 'upper' 屬性
...
請再次嘗試回答這個問題。
...最終的代碼正確處理了 ??RunnableLambda??? 函數中的輸入字典，避免了 ??上下文填充??? 情況中出現的錯誤。總的來看，通過使用 LangGraph 添加這個簡單的反思步驟進行重試后，代碼執行的準確率得到了 ??~47%?? 的提高：
使用與不使用 LangGraph 的導入及代碼執行 LangSmith 評測對比
結論總結
LangGraph 以其流程設計的便捷性，助力了復雜循環和決策點的設置。最新研究證明，這種設計對于代碼生成極具價值，能夠迭代并利用測試來檢驗答案，通過反思錯誤，不斷完善最終的解決方案。我們使用 LangGraph 實現了這一流程，并在關于 LCEL 的 20 個問題中進行了代碼導入和執行的測試。結果顯示，“上下文填充 + LangGraph” 結合反思的模式相比于僅有的“上下文填充”，在代碼執行方面取得了 ??~47%?? 的顯著提升。這一流程的應用案例在這里，并且可以輕松擴展至其他代碼庫，供相關人員參考。
