在將大型語言模型（LLM）整合進生產環境的管線時，開發者經常面臨一個核心矛盾：LLM 擅長處理模糊的文本與語義，但企業系統（如資料庫、ERP 或 API）則要求絕對的精確度。例如，在自動化採購系統中，模型必須將一段描述文字準確地對應到資料庫中的一個整數 ID（如成本中心編號），而非僅僅給出一個「看起來正確」的名稱。
Nooxit 的 CTO Jendrik Jördening 在 InfoQ Dev Summit Munich 的分享中，透過一個自動化處理德國鐵路（Deutsche Bahn）延誤申報的實例，探討了如何將 LLM 從一個「隨機的聊天機器人」轉化為一個可預測、可監控且具備高可靠度的選擇系統。他指出，若直接讓 LLM 處理從文本到 ID 的映射，會面臨非確定性（Non-determinism）、上下文視窗限制以及幻覺（Hallucination）等問題，導致系統無法在大規模生產環境中運作。
核心策略：消除隨機性與限制輸出
要建構可靠的選擇系統，首要任務是消除隨機性。Jördening 建議將溫度（Temperature）設為 0 並固定隨機種子（Random Seed），盡量禁用思考預算（Thinking Budget），除非任務極其複雜，因為非線性的思考過程會增加輸出不一致的風險。
然而，僅靠參數調整不足以解決問題。最關鍵的技術是「限制 Schema」（Restrict Your Schemas）。開發者不應僅要求模型輸出 JSON 格式，而應利用結構化輸出（Structured Outputs）定義嚴格的枚舉（Enum）或數值範圍。例如，在識別車站時，不應讓模型自由生成車站名稱，而應提供一個預定義的選項清單，強制模型從中選擇。這樣能將 LLM 的角色從「生成者」轉變為「選擇者」，確保輸出結果能直接對接資料庫 ID，避免出現不存在的車站或錯誤的編號。
解耦映射任務與確定性邏輯
在實作過程中，Jördening 發現將所有任務塞進單一提示詞（Prompt）會導致模型混亂。他提出了「將映射分離為獨立任務」的策略。具體流程應分為兩步：首先，利用 LLM 的視覺或文本能力從原始資料（如截圖）中提取粗略的語義資訊（例如：提取車站名稱）；接著，將提取出的名稱交給另一個專門的映射任務，將其對應到資料庫 ID。
這種解耦方式解決了上下文視窗爆炸的問題。如果將數千個候選 ID 全部放入提示詞，模型會因資訊過載而失效。正確的做法是先縮小搜索範圍，僅將相關的候選集提供給模型。此外，對於時間比較、數值計算等確定性邏輯，應完全移出 LLM，交由傳統程式碼處理。例如，不要問 LLM「下一班車是什麼時候」，而應讓 LLM 找出所有前往目的地的列車，再由程式碼計算出最接近當前時間的班次。
驗證機制與 MVC 架構的引入
為了確保系統的穩定性，Jördening 引入了判別模型（Discriminator Model）作為驗證層。在模型做出選擇後，由第二個獨立的模型來驗證該選擇是否正確（例如：驗證所選的車站 ID 是否真的對應到提取的名稱）。這種設計創造了兩個獨立的信號：預測值與驗證結果。開發者可以透過這兩個信號來量化模型的準確率，而不需要每次都進行人工抽檢。
在整體架構上，他建議採用類 MVC（Model-View-Controller）的設計模式。Model 負責管理系統狀態（如目前的車站、目標地）；Controller 負責定義狀態轉移的邏輯，調用 LLM 執行特定的微小任務；View 則可以保留為使用者熟悉的 AI 聊天介面。這種結構讓系統具備可組合性（Composable Design），開發者可以輕鬆替換單個 Agent 或調整業務邏輯，而不會影響整個流程。
實務意義與限制
這種從「端到端生成」轉向「結構化選擇」的方法，雖然增加了開發的僵硬度（Rigidity）——開發者必須定義狀態機並編寫更多對接程式碼，不再能僅靠修改 Prompt 就完成功能更新——但它換來了企業級的可靠度。
透過將 LLM 定位為處理非結構化文本的「語義轉換器」，並將其結果限制在確定性的框架內，團隊能夠獲得明確的監控指標（Metrics），並確保系統不會將使用者導向一個早已廢棄的車站。這證明了在生產環境中，LLM 的價值不在於其創造力，而在於其能將混亂的現實世界數據轉化為系統可處理的結構化信號。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。