研究初衷

在大型語言模型（LLMs）的眾多應(yīng)用中，代碼生成與分析尤為關(guān)鍵，這從產(chǎn)品 GitHub co-pilot 的廣泛應(yīng)用和 GPT-engineer 等項(xiàng)目的熱度可見一斑。AlphaCodium 的最新進(jìn)展展示出，與傳統(tǒng)“提示-應(yīng)答”方法不同，“流程”式編程通過測試與反思答案，進(jìn)而迭代改進(jìn)，能更好地推動代碼的生成。

AlphaCodium 的流程法則

我們最近推出了 LangGraph，這是一種以圖表形式表示與設(shè)計(jì)流程的工具。受到 AlphaCodium 和 Reflexion 工作的激勵，我們想借助 LangGraph 在代碼生成中實(shí)現(xiàn)類似的迭代循環(huán)和關(guān)鍵決策點(diǎn)。

具體而言，我們試圖構(gòu)建并比較兩種架構(gòu)：

• 基于提示與上下文填充的代碼生成
• 涉及校驗(yàn)執(zhí)行代碼的流程化代碼生成，出現(xiàn)錯誤時(shí)能自我糾錯

這個嘗試旨在探究：這種代碼檢驗(yàn)?zāi)茉诙啻蟪潭壬咸嵘a生成系統(tǒng)的性能？

結(jié)果如何呢？

??

?與僅進(jìn)行單次生成的基本方法相比，涉及校驗(yàn)與自我修正的系統(tǒng)展現(xiàn)出顯著進(jìn)步（ 81% 對 55% ）

問題背景

為了在有限的文檔庫上展示代碼生成能力，我們選擇了 LangChain 的文檔子集，著重于 LangChain 表達(dá)式語言（LCEL），其范圍小（大約 60k 標(biāo)記）且備受關(guān)注。我們篩選了連續(xù) 30 天的 ??chat-langchain??? 中與 LCEL 相關(guān)的問題（代碼在此）。從 ??>60k 聊天記錄??? 共篩選出 ??~500?? 條提到 LCEL 的記錄。我們對這約 500 條記錄進(jìn)行聚類，由 LLM（GPT-4，128k）歸納總結(jié)，以得出每個類別中的代表性問題。每個問題我們都進(jìn)行了手動審核，并制定了標(biāo)準(zhǔn)答案（含 20 個問題的評估集在這里）。我們把此數(shù)據(jù)集加到了 LangSmith。

生成 LCEL 教材評估集合流程

利用 LangGraph 進(jìn)行反射式代碼生成

我們設(shè)計(jì)并實(shí)踐了一個包含如下環(huán)節(jié)的代碼生成流程：

• 受到長上下文 LLMs 的新動向啟發(fā)，我們利用 GPT-4（128k 令牌上下文窗口）的能力將 60k 令牌的 LCEL 文檔詳盡填充。我們向經(jīng)處理過的 LCEL 鏈條提交 LCEL 相關(guān)問題，以啟動初步答案的生成。
• 我們使用 OpenAI 工具對成果進(jìn)行了解析，將輸出轉(zhuǎn)化為擁有三個部分的 Pydantic 對象：（1）問題描述，（2）導(dǎo)入模塊部分，（3）代碼本體。
• 我們首先對導(dǎo)入模塊進(jìn)行執(zhí)行測試，因?yàn)槲覀冊l(fā)現(xiàn)在代碼生成過程中，幻覺可能悄然滲入導(dǎo)入語句之中。
• 導(dǎo)入模塊測試通過后，我們接著確認(rèn)代碼本身是否可執(zhí)行。在代碼生成時(shí)，我們特別指導(dǎo) LLM 防止代碼中出現(xiàn)偽代碼或未定義變量，以確保代碼能夠被執(zhí)行。
• 其中，若上述任一測試失敗，我們就會將錯誤堆棧與先前的回答一起傳回生成環(huán)節(jié)以供反思。默認(rèn)我們會重試 3 次，當(dāng)然這個次數(shù)根據(jù)需求還可以增加。

集錯誤檢測、反饋及反思于一體的 LangGraph 代碼執(zhí)行流程

利用 LangSmith 進(jìn)行的評估

我們設(shè)立了不涉及 LangGraph 的 “上下文填充” 基準(zhǔn)線，即在我們的流程圖中這一環(huán)節(jié)并未執(zhí)行任何檢測或反饋：同樣利用 GPT-4 的 128k 令牌上下文窗口，我們將 60k 令牌的 LCEL 文檔進(jìn)行充實(shí)。我們提交了與 LCEL 相關(guān)的問題以生成答案。

我們?yōu)閮蓚€部分

（1）導(dǎo)入模塊的評估

（2）代碼執(zhí)行的評估

實(shí)現(xiàn)了 LangSmith 的自定義評價(jià)功能。

我們在 “上下文填充” 的 20 個問題評估集上進(jìn)行了四輪評估。評估結(jié)果在此。通過上下文填充進(jìn)行的評估表明 ??~98%??? 的導(dǎo)入模塊測試是準(zhǔn)確的，而代碼執(zhí)行成功率約 ??~55%???（??N=79?? 次成功嘗試）。

我們通過 LangSmith 分析了失敗的案例：案例分析，一個典型的錯誤是沒能注意到 ??RunnableLambda??? 函數(shù)的輸入應(yīng)當(dāng)是 ??dict???，反而將其誤認(rèn)為 ??string???：??AttributeError: 'dict' object has no attribute 'upper'??

接下來，我們對“通過上下文填充 + LangGraph”的情況進(jìn)行了測試，通過執(zhí)行測試以篩查導(dǎo)入和代碼執(zhí)行中的錯誤，并在生成更新的答案時(shí)進(jìn)行反思。在相同的評估集上，我們觀察到 ??100%??? 的導(dǎo)入測試是準(zhǔn)確的，以及 ??~81%??? 的代碼執(zhí)行測試是成功的（??N=78?? 次嘗試）。

以上述失敗案例為例，我們可以看到系統(tǒng)是如何進(jìn)行處理的：完整的錯誤跟蹤顯示，我們在回答問題的第二次嘗試中遇到了同樣的錯誤詳情。在后續(xù)的反思環(huán)節(jié)中，我們提供了先前的解決方案和隨之出現(xiàn)的錯誤：

您之前嘗試解決過這個問題。
...
--- 最近的運(yùn)行錯誤 ---
執(zhí)行錯誤：'dict' 對象沒有 'upper' 屬性
...
請?jiān)俅螄L試回答這個問題。
...

最終的代碼正確處理了 ??RunnableLambda??? 函數(shù)中的輸入字典，避免了 ??上下文填充??? 情況中出現(xiàn)的錯誤。總的來看，通過使用 LangGraph 添加這個簡單的反思步驟進(jìn)行重試后，代碼執(zhí)行的準(zhǔn)確率得到了 ??~47%?? 的提高：

使用與不使用 LangGraph 的導(dǎo)入及代碼執(zhí)行 LangSmith 評測對比

結(jié)論總結(jié)

LangGraph 以其流程設(shè)計(jì)的便捷性，助力了復(fù)雜循環(huán)和決策點(diǎn)的設(shè)置。最新研究證明，這種設(shè)計(jì)對于代碼生成極具價(jià)值，能夠迭代并利用測試來檢驗(yàn)答案，通過反思錯誤，不斷完善最終的解決方案。我們使用 LangGraph 實(shí)現(xiàn)了這一流程，并在關(guān)于 LCEL 的 20 個問題中進(jìn)行了代碼導(dǎo)入和執(zhí)行的測試。結(jié)果顯示，“上下文填充 + LangGraph” 結(jié)合反思的模式相比于僅有的“上下文填充”，在代碼執(zhí)行方面取得了 ??~47%?? 的顯著提升。這一流程的應(yīng)用案例在這里，并且可以輕松擴(kuò)展至其他代碼庫，供相關(guān)人員參考。