語言模型不僅會犯錯——它們會完全自信地捏造現實。AI 代理可能會聲稱它創建了實際上並不存在的資料庫記錄,語言模型不僅會犯錯——它們會完全自信地捏造現實。AI 代理可能會聲稱它創建了實際上並不存在的資料庫記錄,

審查大型語言模型行為:我們能測試幻覺現象嗎?測試導向 AI 軟體開發人員 Dmytro Kyiashko 的專家見解

語言模型不僅會犯錯——它們還會以完全自信的態度捏造事實。AI 代理可能聲稱它創建了不存在的資料庫記錄,或堅稱它執行了從未嘗試過的操作。對於在生產環境中部署這些系統的團隊來說,這種區別決定了您如何解決問題。

Dmytro Kyiashko 專門從事 AI 系統測試。他的工作專注於一個問題:如何系統性地捕捉模型說謊的時刻?

測試自信胡言的問題

傳統軟體以可預測的方式失效。一個損壞的函數會返回錯誤。配置錯誤的 API 會提供確定性的失敗信號——通常是標準的 HTTP 狀態碼和可讀的錯誤訊息,解釋出了什麼問題。

語言模型的失效方式不同。它們會報告完成了從未開始的任務,從未查詢過的資料庫中檢索資訊,並描述僅存在於訓練資料中的操作。回應看起來正確。內容卻是捏造的。

「每個 AI 代理都根據工程師準備的指令運作,」Kyiashko 解釋道。「我們確切知道我們的代理能做什麼和不能做什麼。」這種知識成為區分幻覺和錯誤的基礎。

如果一個訓練用來查詢資料庫的代理無聲地失敗,那是一個錯誤。但如果它在沒有接觸資料庫的情況下返回詳細的查詢結果呢?那就是幻覺。模型基於訓練模式創造了看似合理的輸出。

針對真實資料的驗證

Kyiashko 的方法以針對實際系統狀態的驗證為核心。當代理聲稱它創建了記錄時,他的測試會檢查這些記錄是否存在。如果系統與之矛盾,代理的回應就無關緊要。

「我通常使用不同類型的負面測試——包括單元測試和整合測試——來檢查 LLM 幻覺,」他指出。這些測試故意請求代理缺乏執行權限的操作,然後驗證代理不會錯誤地確認成功,且系統狀態保持不變。

一種技術是針對已知約束進行測試。沒有資料庫寫入權限的代理被提示創建記錄。測試驗證沒有未經授權的資料出現,且回應不會聲稱成功。

最有效的方法使用生產資料。「我使用客戶對話的歷史記錄,將所有內容轉換為 JSON 格式,並使用這個 JSON 檔案運行我的測試。」每個對話都成為一個測試案例,分析代理是否做出與系統日誌矛盾的聲明。

這能捕捉到合成測試遺漏的模式。真實使用者創造了暴露邊緣情況的條件。生產日誌揭示了模型在實際使用中幻覺的地方。

兩種評估策略

Kyiashko 使用兩種互補的方法來評估 AI 系統。

基於程式碼的評估器處理客觀驗證。「當失敗定義是客觀的且可以用規則檢查時,基於程式碼的評估器是理想的。例如:解析結構、檢查 JSON 有效性或 SQL 語法,」他解釋道。

但有些失敗抗拒二元分類。語氣是否恰當?摘要是否忠實?回應是否有幫助?「當失敗模式涉及程式碼無法捕捉的詮釋或細微差別時,會使用 LLM-as-Judge 評估器。」

對於 LLM-as-Judge 方法,Kyiashko 依賴 LangGraph。兩種方法都無法單獨運作。有效的框架會同時使用兩者。

傳統 QA 培訓遺漏的內容

經驗豐富的品質工程師在第一次測試 AI 系統時會遇到困難。使他們有效的假設無法轉移。

「在傳統 QA 中,我們確切知道系統的回應格式,我們確切知道輸入和輸出資料的格式,」Kyiashko 解釋道。「在 AI 系統測試中,沒有這樣的東西。」輸入資料是一個提示——而客戶表達請求的方式變化無窮。

這需要持續監控。Kyiashko 稱之為「持續錯誤分析」——定期審查代理如何回應實際使用者,識別它們在哪裡捏造資訊,並相應地更新測試套件。

挑戰隨著指令量而加劇。AI 系統需要大量定義行為和約束的提示。每條指令都可能與其他指令發生不可預測的互動。「AI 系統的問題之一是需要不斷更新和測試的大量指令,」他指出。

知識差距很大。大多數工程師缺乏對適當指標、有效資料集準備或驗證每次運行都會改變的輸出的可靠方法的清晰理解。「製作 AI 代理並不困難,」Kyiashko 觀察道。「自動化該代理的測試才是主要挑戰。根據我的觀察和經驗,測試和優化 AI 系統所花費的時間比創建它們更多。」

可靠的每週發布

幻覺比錯誤更快地侵蝕信任。損壞的功能會使使用者感到沮喪。自信地提供錯誤資訊的代理會摧毀可信度。

Kyiashko 的測試方法實現了可靠的每週發布。自動化驗證在部署前捕捉回歸。使用真實資料訓練和測試的系統能正確處理大多數客戶請求。

每週迭代推動競爭優勢。AI 系統透過增加功能、改進回應、擴展領域而改進。

為什麼這對品質工程很重要

整合 AI 的公司每天都在增長。「世界已經看到了使用 AI 的好處,所以沒有回頭路,」Kyiashko 主張。AI 採用在各行業加速——更多新創公司推出,更多企業將智慧整合到核心產品中。

如果工程師構建 AI 系統,他們必須了解如何測試它們。「即使在今天,我們也需要了解 LLM 如何運作、AI 代理如何構建、這些代理如何測試,以及如何自動化這些檢查。」

提示工程正成為品質工程師的必備技能。資料測試和動態資料驗證遵循相同的軌跡。「這些應該已經是測試工程師的基本技能。」

Kyiashko 在整個行業中看到的模式證實了這種轉變。透過他審查 AI 評估技術論文和在技術論壇評估新創公司架構的工作,相同的問題反覆出現:各地的團隊面臨相同的問題。他幾年前在生產中解決的驗證挑戰現在隨著 AI 部署規模的擴大而成為普遍關注的問題。

可擴展的測試基礎設施

Kyiashko 的方法涵蓋評估原則、多輪對話評估以及不同失敗模式的指標。

核心概念:多元化測試。程式碼層級驗證捕捉結構性錯誤。LLM-as-Judge 評估能夠根據使用的 LLM 版本評估 AI 系統的有效性和準確性。手動錯誤分析識別模式。RAG 測試驗證代理使用提供的上下文而不是創造細節。

「我描述的框架基於 AI 系統測試多元化方法的概念。我們使用程式碼層級覆蓋、LLM-as-Judge 評估器、手動錯誤分析和檢索增強生成評估。」多種驗證方法協同工作,捕捉單一方法遺漏的不同幻覺類型。

接下來會發生什麼

該領域透過生產失敗和迭代改進即時定義最佳實踐。更多公司部署生成式 AI。更多模型做出自主決策。系統變得更強大,這意味著幻覺變得更加可信。

但系統性測試在使用者遇到捏造之前就捕捉到它們。測試幻覺不是關於完美——模型總會有產生幻覺的邊緣情況。這是關於系統性地捕捉捏造並防止它們進入生產環境。

這些技術在正確應用時是有效的。缺少的是對如何在可靠性至關重要的生產環境中實施它們的廣泛理解。

Dmytro Kyiashko 是一名專門從事 AI 系統測試的測試軟體開發人員,在為對話式 AI 和自主代理構建測試框架方面擁有經驗。他的工作檢驗多模態 AI 系統中的可靠性和驗證挑戰。

評論
市場機遇
Large Language Model 圖標
Large Language Model實時價格 (LLM)
$0.0003346
$0.0003346$0.0003346
+0.39%
USD
Large Language Model (LLM) 實時價格圖表
免責聲明: 本網站轉載的文章均來源於公開平台,僅供參考。這些文章不代表 MEXC 的觀點或意見。所有版權歸原作者所有。如果您認為任何轉載文章侵犯了第三方權利,請聯絡 [email protected] 以便將其刪除。MEXC 不對轉載文章的及時性、準確性或完整性作出任何陳述或保證,並且不對基於此類內容所採取的任何行動或決定承擔責任。轉載材料僅供參考,不構成任何商業、金融、法律和/或稅務決策的建議、認可或依據。