大多數(shù)人對大語言模型的使用，停在ChatGPT對話框里。

作者去年也這樣。直到他發(fā)現(xiàn)一個規(guī)律：模型越強(qiáng)，落地越疼。上下文丟失、幻覺亂答、跟現(xiàn)有工作流打架——問題從來不在模型本身，而在包裹它的那層系統(tǒng)。

從"試試"到"上線"的斷層

技術(shù)社區(qū)有個隱形漏斗。100個人讀完LLM論文，80個會跑個Demo，20個想集成進(jìn)業(yè)務(wù)，最后能完整部署的只剩個位數(shù)。

作者最初也卡在中間層。他用GPT-4做過客服機(jī)器人，用Claude寫過代碼助手，但都是玩具——能演示，不能承壓。用戶多問兩句上下文，模型就開始胡編；接進(jìn)公司CRM，API延遲直接拖垮頁面。

他意識到自己在重復(fù)一個經(jīng)典錯誤：把LLM當(dāng)黑盒插件，而不是系統(tǒng)核心來設(shè)計。

真正的轉(zhuǎn)折點，是他關(guān)掉IDE，打開了空白文檔。

不是寫代碼，是畫架構(gòu)。數(shù)據(jù)怎么流、狀態(tài)存哪、哪步必須人工確認(rèn)、哪步可以自動化——這些決策比選模型重要十倍。

系統(tǒng)設(shè)計的三個反直覺選擇

作者最終落地的方案，做了幾個讓純AI玩家意外的取舍。

第一，主動限制模型自由度。他沒追求"通用對話"，而是把交互拆成固定步驟：意圖識別→信息提取→內(nèi)部工具調(diào)用→結(jié)果組裝。每一步輸出都有JSON Schema約束，幻覺率從不可控降到接近零。

第二，把記憶外包給傳統(tǒng)數(shù)據(jù)庫。向量數(shù)據(jù)庫只存語義索引，業(yè)務(wù)狀態(tài)全走PostgreSQL。作者的原話是：「LLM不該記住用戶上周改了什么地址，它只負(fù)責(zé)理解當(dāng)前這句話想干嘛。」

第三，預(yù)留人工介入的"逃生艙"。系統(tǒng)每步都暴露中間狀態(tài)，置信度低于閾值自動轉(zhuǎn)人工。上線第一周，人工接管率23%；兩個月后降到4%。

部署后的真實數(shù)據(jù)

這套系統(tǒng)現(xiàn)在每天處理2000+請求，平均響應(yīng)時間1.2秒。作者沒透露具體業(yè)務(wù)場景，但從架構(gòu)反推，應(yīng)該是B端流程自動化——客服、工單處理或內(nèi)部審批。

他提到一個細(xì)節(jié)：最初想用LangChain快速搭建，后來全拆了重寫。「框架幫你省三天，后期改架構(gòu)多花三個月。」

另一個教訓(xùn)是關(guān)于評估。作者花了整整兩周設(shè)計測試集，包含200+邊界case——用戶故意模糊的需求、矛盾的歷史記錄、超出系統(tǒng)能力的請求。上線后遇到的90%問題，都在這套case里預(yù)演過。

給同樣想落地的人

作者最后列了幾條實操建議，沒有一條是關(guān)于"提示詞工程"的。

先畫數(shù)據(jù)流圖，再寫代碼。如果畫不清楚，說明需求本身模糊。監(jiān)控比功能更重要——上線第一天就要能看到每一步的輸入輸出、耗時、錯誤類型。別迷信最新模型，GPT-4和Claude 3的差距，遠(yuǎn)小于"能跑通"和"能承壓"的差距。

他特別提到一個現(xiàn)象：很多團(tuán)隊把80%精力花在調(diào)模型，20%花在系統(tǒng)。結(jié)果往往是Demo驚艷，生產(chǎn)拉胯。他的比例反過來，模型選型只占兩成，架構(gòu)和工程占八成。

現(xiàn)在他的系統(tǒng)已經(jīng)穩(wěn)定運行數(shù)月。作者說最意外的反饋來自內(nèi)部同事：「用起來不像AI，像個特別聰明的同事——不會突然說胡話，也不會忘記上周聊過什么。」

如果你正在把LLM從"試試"推進(jìn)到"上線"，哪個環(huán)節(jié)卡得最久——是模型選型、架構(gòu)設(shè)計，還是內(nèi)部說服成本？