聊天模板裡藏著魔鬼 =========================== 馬鈴薯和馬鈴薯不是一回事，這與菲比·布菲讓你相信的說法相反。 如果你正為通用人工智慧（AGI）而輾轉難眠，或者你只是在從事開源人工智慧模型的實作工作，那麼這篇部落格你一定要讀。 如果你是一位研究「人工智慧安全」的公共知識分子，卻看不懂這篇博客，那麼你就沒有資格評論這個主題。正如人們常說的，去讀書吧。 現在我的抱怨已經結束了，我想告訴你們，這篇部落格將告訴你們所有可能出錯的事情，這些事情最終可能會使你的前沿模型變得「愚蠢」。 LLM的推理非常脆弱。推理引擎必須以嚴格的格式（聊天範本）將輸入呈現給LLM。如果稍有偏差，輸出結果就會很糟糕。不過，這至少可以減輕你對通用人工智慧（AGI）的焦慮——科技不會變成天網。 感謝 @vllm_project 和 Lilian Weng。他們在此講述如何根據 Kimi 團隊的回饋，將運行在 vLLM 上的 Kimi k2 模型的工具呼叫成功率提高到接近 100%。 他們收到回饋後很快就行動了，做得好！非常感謝你們的社區服務🧡💕 關鍵教訓（引用） 魔鬼藏在聊天模板裡：聊天模板是模型與其服務框架之間至關重要的互動環節。整合新模型時，請務必仔細驗證其範本邏輯的每個部分，確保它們符合框架的特定行為和假設。 剝離抽象層：像 `/chat/completions` 這樣的高階 API 雖然方便，但可能會掩蓋根本原因。調試時，不要猶豫，直接訪問像 `/completions` 這樣的底層介面。手動建立輸入是隔離問題的有效方法。 專業提示：令牌 ID 是最終的真相：對於最細微的問題，檢查發送給模型的最終令牌 ID 序列是唯一確定問題所在的方法。雖然我在上述問題中並不需要用到這種方法，但它仍然是工具箱中至關重要的工具。諸如使用 OpenAI 相容的 API 返回令牌 ID 之類的技術可能在關鍵時刻救你一命。有興趣的朋友可以參考我們在 Agent Lightning 文章中重點介紹的這一點。 理解框架設計理念：vLLM 對 **kwargs 的嚴格處理並非缺陷，而是出於安全考慮的有意選擇。理解這些設計決策有助於快速找到根本原因，避免被意外行為所困擾。 開放生態系統的挑戰：諸如“Enforcer”工具呼叫之類的高級功能是成熟專有服務的標誌。如何在像vLLM這樣的開源專案中穩健而優雅地實現這些功能，是社群亟待解決的重要挑戰。
正在載入線程內容
正在從 X 取得原始推文，整理成清爽的閱讀畫面。
通常只需幾秒鐘，請稍候。