大多數(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)部說服成本?
特別聲明:以上內(nèi)容(如有圖片或視頻亦包括在內(nèi))為自媒體平臺“網(wǎng)易號”用戶上傳并發(fā)布,本平臺僅提供信息存儲服務(wù)。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.