大模型火了之后各種新概念、新玩法層出不窮今天一個“智能體”明天一個“思維鏈”后天又冒出個“多模態(tài)融合”。很多人追著這些名詞跑越追越焦慮感覺永遠學(xué)不完。但如果你把市面上主流的大模型應(yīng)用掰開揉碎看一遍會發(fā)現(xiàn)一個讓人踏實的事實所有 AI 新花樣本質(zhì)上只在兩個地方做文章——輸入什么以及輸出怎么處理。中間那個負責“思考”的模型本體反而是最穩(wěn)定的那一層。這個判斷不是拍腦袋來的。我過去兩年折騰過不少大模型落地項目從最簡單的文檔問答到稍微復(fù)雜點的自動化流程踩了一圈坑之后回頭看真正決定一個應(yīng)用好不好用的往往不是換了多強的模型而是輸入側(cè)喂了什么、輸出側(cè)怎么接。這篇文章就把這個三層架構(gòu)徹底拆開講清楚不管你是剛?cè)腴T想搞明白大模型應(yīng)用到底怎么回事還是已經(jīng)做過一些項目但總覺得哪里沒打通都能從中找到可以直接抄作業(yè)的思路和避坑經(jīng)驗。1. 三層架構(gòu)到底怎么分先建立全局視角1.1 為什么是三層而不是兩層或四層把大模型應(yīng)用拆成三層是我試過多種分法之后覺得最順手的一種。三層分別是輸入層、模型層、輸出層。輸入層負責把用戶的原始需求翻譯成模型能理解的格式模型層負責推理生成輸出層負責把模型吐出來的東西變成用戶能直接用的結(jié)果。為什么不是兩層因為很多人會把輸入和輸出混在一起叫“應(yīng)用層”但實際操作中你會發(fā)現(xiàn)輸入側(cè)的問題和輸出側(cè)的問題完全是兩碼事。輸入側(cè)出問題表現(xiàn)為模型答非所問、理解偏差輸出側(cè)出問題表現(xiàn)為格式不對、沒法對接下游系統(tǒng)?；煸谝黄鹋挪樾蕵O低。為什么不是四層有人會把“數(shù)據(jù)層”單獨拎出來但在大多數(shù)應(yīng)用場景里數(shù)據(jù)要么是輸入的一部分比如檢索增強要么是輸出的一部分比如寫入數(shù)據(jù)庫單獨拆一層反而增加了理解成本。三層足夠覆蓋絕大多數(shù)情況而且邊界清晰。提示這個分層不是學(xué)術(shù)定義而是實操視角的劃分。目的是讓你在遇到問題時能快速定位到底是哪一層出了毛病。1.2 模型層為什么反而最“無聊”模型層就是那個真正跑推理的大模型本身。你可能會覺得這是最核心的一層但實際上在應(yīng)用開發(fā)中它是最不需要頻繁改動的一層。原因很簡單模型的能力邊界在訓(xùn)練完成那一刻就基本確定了你能做的只是通過輸入輸出來適配它而不是改變它。我見過不少團隊花大量時間糾結(jié)“用哪個模型”今天試試這個明天換換那個結(jié)果項目進度卡在選型上。但實際跑下來同一個任務(wù)不同主流模型的表現(xiàn)差異遠沒有想象中那么大真正拉開差距的是輸入側(cè)有沒有把需求說清楚、輸出側(cè)有沒有做好后處理。模型層還有一個特點它的迭代是平臺方的事不是應(yīng)用方的事。你今天用的模型版本下個月可能就升級了但你的輸入輸出邏輯不需要跟著大改。這就是為什么我說模型層最“無聊”——它穩(wěn)定、被動是整個架構(gòu)里的常量而不是變量。1.3 輸入層和輸出層才是真正的戰(zhàn)場所有讓人眼前一亮的 AI 應(yīng)用創(chuàng)新點幾乎都集中在輸入層和輸出層。輸入層的創(chuàng)新包括更好的提示詞設(shè)計、更精準的上下文檢索、更合理的多輪對話管理、更豐富的多模態(tài)輸入處理。輸出層的創(chuàng)新包括結(jié)構(gòu)化輸出解析、多輪結(jié)果聚合、格式轉(zhuǎn)換、與外部工具的聯(lián)動。舉個例子同樣一個模型你直接問“幫我寫個方案”和先給它喂三篇參考文檔再問“按照這三篇文檔的風格寫個方案”輸出質(zhì)量天差地別。這個差異不來自模型來自輸入層。再比如模型輸出了一段 JSON你直接扔給用戶看和解析后渲染成表格再展示體驗完全不同。這個差異來自輸出層。所以如果你想把 AI 應(yīng)用做好精力應(yīng)該花在輸入輸出這兩層上而不是天天盯著模型排行榜。2. 輸入層拆解決定模型“吃”到什么2.1 提示詞工程只是輸入層的一部分很多人一提到輸入層就想到提示詞工程覺得把提示詞寫好就萬事大吉了。但提示詞只是輸入層的一個子集。完整的輸入層至少包括四個部分系統(tǒng)指令、上下文信息、用戶輸入、歷史對話。系統(tǒng)指令是給模型定角色的比如“你是一個專業(yè)的法律顧問”。上下文信息是你額外喂給模型的參考資料比如檢索到的文檔片段。用戶輸入是當前這一輪的問題。歷史對話是之前幾輪的交互記錄。這四部分怎么組合、怎么排序、怎么控制長度都是輸入層要解決的問題。我踩過的一個坑是早期做文檔問答時把檢索到的文檔片段直接拼在用戶問題前面結(jié)果模型經(jīng)常把文檔里的內(nèi)容當成用戶說的話來回應(yīng)。后來改成用明確的分隔符把文檔和問題隔開并加上“以下文檔僅供參考請回答用戶問題”的指令問題就解決了。這就是輸入層設(shè)計不到位導(dǎo)致的。2.2 上下文檢索輸入層最值錢的能力如果說輸入層有什么能力最值得投入那一定是上下文檢索。大模型本身的知識是固定的但通過檢索把外部知識注入到輸入里就能讓模型回答它原本不知道的事情。這就是檢索增強生成的核心思路。檢索增強生成聽起來復(fù)雜拆開看就三步把用戶問題轉(zhuǎn)成向量在向量庫里找最相似的文檔片段把找到的片段塞進輸入里。難點不在模型而在檢索質(zhì)量。檢索不準喂進去的上下文就是噪音模型反而會被帶偏。我在實際項目里總結(jié)了幾條檢索優(yōu)化的經(jīng)驗。第一文檔切分粒度很重要切得太碎會丟失上下文切得太大會引入無關(guān)信息一般按語義段落切分效果比較好。第二向量模型的選擇比大模型的選擇更影響檢索效果因為檢索不準后面全白搭。第三檢索數(shù)量不是越多越好一般三到五條最相關(guān)的結(jié)果就夠了多了反而干擾模型判斷。注意檢索增強生成不是萬能藥。如果外部知識本身質(zhì)量差、結(jié)構(gòu)亂檢索出來的東西也是垃圾。輸入層的質(zhì)量上限取決于你的數(shù)據(jù)質(zhì)量。2.3 多輪對話管理別讓歷史拖垮輸入多輪對話是輸入層里最容易被忽視的部分。很多人做對話系統(tǒng)時把全部歷史對話都塞進輸入里結(jié)果 token 消耗飛快模型還容易被早期無關(guān)內(nèi)容干擾。正確的做法是有選擇地保留歷史。我的做法是只保留最近三到五輪對話并且對歷史對話做摘要壓縮。比如用戶前面聊了十分鐘的需求背景不需要把原話全帶上用一兩句話概括就行。這樣既保留了上下文連貫性又控制了輸入長度。還有一個技巧是“對話狀態(tài)追蹤”。把多輪對話中提取到的關(guān)鍵信息比如用戶提到的日期、地點、偏好單獨存成一個結(jié)構(gòu)化狀態(tài)每輪輸入時把這個狀態(tài)帶上而不是帶原始對話。這樣輸入更干凈模型也更容易抓住重點。2.4 多模態(tài)輸入圖片、音頻怎么喂給模型多模態(tài)輸入是近兩年的熱點但實操中要注意不是所有模型都支持多模態(tài)支持的模型對輸入格式也有要求。圖片一般需要轉(zhuǎn)成 base64 編碼或者提供 URL音頻需要先轉(zhuǎn)成文字再輸入視頻更復(fù)雜通常要抽幀成圖片序列。我做過一個圖片理解的小項目經(jīng)驗是圖片分辨率不是越高越好太高的分辨率會消耗大量 token而且模型對圖片的理解能力有限關(guān)鍵信息清晰可見就夠了。另外圖片和文字的排列順序會影響模型理解一般把圖片放在相關(guān)文字旁邊效果最好。音頻輸入目前最穩(wěn)妥的方案還是先做語音轉(zhuǎn)文字再把文字輸入模型。直接端到端的語音理解模型雖然有但穩(wěn)定性和可控性還不如轉(zhuǎn)文字方案。視頻輸入同理抽關(guān)鍵幀加字幕轉(zhuǎn)文字比直接喂視頻靠譜得多。3. 輸出層拆解決定用戶“拿”到什么3.1 結(jié)構(gòu)化輸出讓模型吐出來的東西能用模型默認輸出的是自然語言文本但很多應(yīng)用場景需要的是結(jié)構(gòu)化數(shù)據(jù)。比如你要把模型輸出存進數(shù)據(jù)庫就需要 JSON要展示成表格就需要二維數(shù)組要觸發(fā)下游動作就需要特定的指令格式。這些都需要在輸出層做處理。讓模型輸出結(jié)構(gòu)化數(shù)據(jù)有兩種思路。一種是在提示詞里明確要求模型按 JSON 格式輸出另一種是讓模型自由輸出然后用解析器提取結(jié)構(gòu)化信息。第一種思路更直接但模型有時會不聽話輸出帶 markdown 代碼塊的 JSON 或者格式錯誤的 JSON。第二種思路更靈活但解析器要寫得足夠健壯。我的經(jīng)驗是兩者結(jié)合提示詞里要求 JSON 輸出同時輸出層加一個容錯解析器能處理常見的格式偏差比如去掉代碼塊標記、補全缺失的括號、修正常見的鍵名拼寫錯誤。這樣既保證了結(jié)構(gòu)化又不會因為模型偶爾不聽話就整個流程崩掉。3.2 格式轉(zhuǎn)換與渲染從文本到用戶界面模型輸出的文本要變成用戶能看的東西中間需要一層格式轉(zhuǎn)換。最簡單的場景是純文本展示復(fù)雜一點的場景包括把 markdown 轉(zhuǎn)成 HTML 渲染、把 JSON 轉(zhuǎn)成表格、把列表轉(zhuǎn)成卡片、把代碼塊加上語法高亮。這一步看起來是前端的事但實際上輸出層就要考慮好。比如模型輸出的 markdown 里可能有表格你的渲染器要能正確處理可能有代碼塊要能識別語言類型可能有數(shù)學(xué)公式要能渲染成公式而不是純文本。這些如果輸出層不做處理前端就要做但前端做的話不同端網(wǎng)頁、App、小程序就要各做一遍不如在輸出層統(tǒng)一處理。我一般會在輸出層做一個“標準化”步驟把模型輸出的各種格式統(tǒng)一轉(zhuǎn)成一種中間格式比如 HTML 片段或者結(jié)構(gòu)化 JSON然后各端再基于中間格式做渲染。這樣邏輯集中維護成本低。3.3 結(jié)果校驗與兜底別讓模型胡說八道直接出去模型會胡說八道這是常識。輸出層的一個重要職責就是校驗和兜底。校驗包括事實性校驗輸出內(nèi)容是否和已知事實矛盾、格式校驗輸出是否符合預(yù)期格式、安全校驗輸出是否包含不當內(nèi)容。兜底就是當校驗不通過時給用戶一個合理的降級回復(fù)而不是直接把錯誤內(nèi)容展示出去。事實性校驗最難做因為你需要一個可信的知識源來比對。我的做法是對于關(guān)鍵事實在輸入層就把可信信息喂給模型輸出層再檢查模型輸出是否引用了這些信息。如果模型輸出和輸入信息矛盾就觸發(fā)重新生成或者降級回復(fù)。格式校驗相對簡單就是檢查輸出是否符合預(yù)期的結(jié)構(gòu)。安全校驗可以用關(guān)鍵詞過濾加模型自檢的方式。兜底策略要根據(jù)場景設(shè)計比如客服場景可以回復(fù)“這個問題我暫時無法回答建議您聯(lián)系人工客服”而不是硬答。3.4 輸出與外部系統(tǒng)的聯(lián)動輸出層不只是給用戶看的很多時候還要觸發(fā)外部動作。比如模型判斷用戶意圖是“查天氣”輸出層就要調(diào)用天氣接口判斷意圖是“下單”輸出層就要調(diào)用訂單系統(tǒng)。這就是所謂的“工具調(diào)用”或“函數(shù)調(diào)用”。工具調(diào)用的關(guān)鍵是意圖識別和參數(shù)提取。模型輸出一段文本輸出層要從中解析出用戶想調(diào)用哪個工具、參數(shù)是什么。我的做法是讓模型直接輸出結(jié)構(gòu)化的調(diào)用指令比如{tool: weather, params: {city: 北京}}然后輸出層解析這個指令并執(zhí)行。這樣比讓模型輸出自然語言再解析要可靠得多。提示工具調(diào)用的參數(shù)校驗一定要做。模型可能提取出錯誤的參數(shù)比如把城市名提取成省份名輸出層要能識別并糾正或者返回錯誤讓模型重新提取。4. 實操從零搭一個三層架構(gòu)的問答應(yīng)用4.1 場景定義與技術(shù)選型假設(shè)我們要做一個“內(nèi)部文檔問答助手”用戶可以用自然語言提問系統(tǒng)從內(nèi)部文檔庫里找答案并回復(fù)。這個場景足夠典型覆蓋了輸入層的檢索、模型層的推理、輸出層的格式化。技術(shù)選型上模型層選一個主流的中等規(guī)模模型就夠了不需要追求最大最強的因為我們的重點在輸入輸出。輸入層的向量檢索用一個輕量級的向量模型加一個向量數(shù)據(jù)庫。輸出層用一個簡單的 Web 框架做接口前端用最基礎(chǔ)的 HTML 加 JavaScript。這個選型的邏輯是把復(fù)雜度和成本控制在輸入輸出層模型層保持簡單穩(wěn)定。這樣整個系統(tǒng)更容易調(diào)試也更容易替換組件。4.2 輸入層實現(xiàn)文檔切分與檢索文檔切分我按語義段落來每段控制在 300 到 500 字。太短了上下文不夠太長了噪音太多。切分的時候保留段落標題這樣檢索到片段后還能知道它屬于哪個章節(jié)。向量化用的是一個開源的中文向量模型把每個段落轉(zhuǎn)成向量存進向量數(shù)據(jù)庫。檢索時把用戶問題也轉(zhuǎn)成向量算余弦相似度取 top 3 的段落。這里有個細節(jié)用戶問題往往很短直接拿短問題去檢索長文檔相似度計算容易不準。我的做法是先讓模型把用戶問題擴展成幾個相關(guān)查詢分別檢索后合并結(jié)果。比如用戶問“報銷流程”模型擴展成“報銷需要什么材料”“報銷審批要多久”“報銷在哪里提交”這樣檢索覆蓋面更廣。4.3 模型層調(diào)用提示詞模板設(shè)計提示詞模板我分成三部分系統(tǒng)指令、上下文、用戶問題。系統(tǒng)指令寫清楚角色和輸出要求上下文放檢索到的文檔片段用戶問題放原始提問。模板大概長這樣你是一個內(nèi)部文檔問答助手。請根據(jù)以下文檔片段回答用戶問題。 如果文檔中沒有相關(guān)信息請直接說“文檔中沒有找到相關(guān)信息”不要編造。 文檔片段 {context} 用戶問題{question} 請用簡潔的中文回答并在回答末尾標注引用的文檔片段編號。這個模板的關(guān)鍵點是明確要求不編造、要求標注引用。標注引用是為了輸出層能做校驗如果模型說了一個文檔里沒有的信息輸出層可以檢查引用編號對應(yīng)的片段里有沒有這個信息。4.4 輸出層實現(xiàn)解析、校驗與展示模型輸出后輸出層先做解析提取回答正文和引用編號。然后做校驗檢查引用編號是否有效檢查回答內(nèi)容是否能在引用片段中找到依據(jù)。校驗通過就展示不通過就降級回復(fù)“抱歉我暫時無法確認這個問題的答案”。展示時把引用片段也一并展示出來讓用戶能看到答案的來源。這樣既增加了可信度也方便用戶自己判斷。如果用戶點擊引用片段還能展開看完整段落。整個流程跑下來你會發(fā)現(xiàn)真正花時間的是輸入層的文檔處理和輸出層的校驗邏輯模型調(diào)用本身只是幾行代碼的事。這再次印證了那個判斷新花樣都在輸入輸出模型層只是執(zhí)行者。5. 常見問題與排查技巧實錄5.1 模型答非所問怎么排查答非所問是最常見的問題排查思路是從輸入層往模型層查。先看輸入里有沒有把用戶問題說清楚再看上下文有沒有干擾信息最后才懷疑模型能力。我遇到過一次典型情況用戶問“年假怎么算”模型回答了一堆考勤制度。查下來發(fā)現(xiàn)檢索到的文檔片段里有一大段考勤制度和年假無關(guān)但向量相似度很高被檢索出來了。解決辦法是在檢索后加一個重排序步驟用更精細的模型對候選片段做二次排序把真正相關(guān)的排前面。5.2 輸出格式不穩(wěn)定的處理模型輸出 JSON 時經(jīng)常帶 markdown 代碼塊標記或者鍵名大小寫不一致或者少個括號。這些都要在輸出層做容錯處理。我的容錯解析器大概做這幾件事去掉首尾的代碼塊標記、嘗試用 JSON 解析、解析失敗就用正則提取鍵值對、鍵名統(tǒng)一轉(zhuǎn)小寫、缺失的括號自動補全。這套組合拳下來百分之九十五的格式問題都能自動修復(fù)。5.3 檢索不準的優(yōu)化路徑檢索不準的表現(xiàn)是明明文檔里有答案但檢索不到或者檢索到的片段和問題無關(guān)。優(yōu)化路徑按優(yōu)先級排先優(yōu)化文檔切分粒度再優(yōu)化向量模型再優(yōu)化檢索策略最后才考慮換向量數(shù)據(jù)庫。文檔切分是最容易被忽視但影響最大的。我見過一個項目文檔按固定字數(shù)切分結(jié)果一個完整的流程被切成三段檢索到其中一段根本看不懂。改成按標題和段落切分后檢索準確率直接上了一個臺階。5.4 多輪對話中上下文丟失的解決多輪對話中用戶經(jīng)常用代詞指代前文內(nèi)容比如“它”“那個”“上面說的”。如果歷史對話沒帶全模型就不知道指代什么。解決辦法是在輸入層做指代消解把用戶當前問題中的代詞替換成具體指代的內(nèi)容。比如用戶上一輪問“報銷流程”這一輪問“它需要多久”輸入層把“它”替換成“報銷流程”變成“報銷流程需要多久”。這樣即使歷史對話帶得少模型也能理解。指代消解可以用規(guī)則做也可以用模型做。規(guī)則做簡單場景夠用復(fù)雜場景還是得靠模型。但模型做會增加一次調(diào)用成本和延遲都會上升需要權(quán)衡。5.5 常見問題速查表問題表現(xiàn)可能原因排查方向解決思路答非所問輸入上下文有干擾檢查檢索結(jié)果相關(guān)性加檢索重排序格式錯誤模型不聽話檢查提示詞格式要求加輸出容錯解析檢索不到文檔切分不合理檢查切分粒度和方式按語義段落切分指代不明歷史對話缺失檢查多輪對話管理加指代消解編造信息模型幻覺檢查輸入是否有依據(jù)加輸出事實校驗響應(yīng)太慢輸入太長檢查 token 數(shù)量壓縮歷史對話和上下文這張表是我在實際項目中反復(fù)用到的一個速查工具遇到問題先對號入座能省不少排查時間。6. 三層架構(gòu)的擴展思路6.1 輸入層的擴展從文本到多模態(tài)輸入層往多模態(tài)擴展是趨勢。圖片輸入可以做圖文問答音頻輸入可以做語音助手視頻輸入可以做內(nèi)容摘要。但擴展時要注意多模態(tài)輸入的 token 消耗遠大于純文本成本控制是關(guān)鍵。我的建議是多模態(tài)輸入先做預(yù)處理圖片壓縮到合適分辨率音頻轉(zhuǎn)文字視頻抽關(guān)鍵幀。預(yù)處理后的輸入再喂給模型既控制了成本也提高了理解準確率。6.2 輸出層的擴展從展示到行動輸出層往行動擴展就是工具調(diào)用和自動化流程。模型輸出不只是給人看還能觸發(fā)一系列動作。比如模型判斷用戶要訂機票輸出層就調(diào)用訂票接口、填表單、發(fā)確認郵件。擴展的關(guān)鍵是定義好工具接口和參數(shù)規(guī)范。每個工具要有清晰的描述和參數(shù) schema模型才能正確調(diào)用。輸出層要做好參數(shù)校驗和錯誤處理工具調(diào)用失敗要有降級方案。6.3 模型層的擴展多模型路由雖然我說模型層最穩(wěn)定但也不是完全不能動。多模型路由就是一個擴展方向簡單問題用小模型復(fù)雜問題用大模型特定任務(wù)用專用模型。這樣能在成本和效果之間取得平衡。路由邏輯可以放在輸入層根據(jù)問題類型選擇模型也可以放在輸出層根據(jù)模型輸出質(zhì)量決定是否換模型重試。我一般放在輸入層因為這樣延遲更低用戶體驗更好。7. 我踩過的幾個印象深刻的坑第一個坑是過度依賴模型能力。早期做項目時總覺得換個更強的模型就能解決問題結(jié)果換了一圈發(fā)現(xiàn)問題出在輸入層的檢索不準。后來把精力放在檢索優(yōu)化上效果立竿見影。這個教訓(xùn)讓我明白模型是常量輸入輸出是變量。第二個坑是忽視輸出校驗。有一次做自動回復(fù)模型輸出了一段看起來很像那么回事但實際上是編造的內(nèi)容直接發(fā)出去了造成了不好的影響。從那以后我在輸出層加了強制校驗關(guān)鍵信息必須能在輸入中找到依據(jù)才允許輸出。第三個坑是上下文塞太多。為了“讓模型知道更多”把大量歷史對話和文檔片段都塞進輸入結(jié)果模型反而抓不住重點響應(yīng)也慢。后來學(xué)會了做減法只保留最相關(guān)的信息效果反而更好。第四個坑是格式處理想當然。以為模型會乖乖按 JSON 輸出結(jié)果各種格式偏差。后來寫了容錯解析器才把這個問題解決。這件事讓我意識到輸出層的健壯性和輸入層的準確性同樣重要。8. 給不同階段從業(yè)者的建議如果你剛開始接觸大模型應(yīng)用建議先從輸入層入手把提示詞寫好把檢索做準。這兩件事做好了效果提升最明顯也最容易看到成果。如果你已經(jīng)做過一些項目建議重點優(yōu)化輸出層。輸出層的校驗、格式化、工具調(diào)用是區(qū)分“玩具”和“產(chǎn)品”的關(guān)鍵。很多項目輸入層做得不錯但輸出層粗糙導(dǎo)致用戶體驗差。如果你在帶團隊做項目建議把輸入層和輸出層分開專人負責。輸入層的人關(guān)注數(shù)據(jù)質(zhì)量和檢索效果輸出層的人關(guān)注格式穩(wěn)定性和系統(tǒng)對接。模型層不需要專人盯定期評估一下就行。最后分享一個我常用的判斷方法當你拿到一個新 AI 應(yīng)用時先看它的輸入設(shè)計再看它的輸出處理基本就能判斷它的技術(shù)含量和實用價值。那些只會在提示詞里堆花活的往往輸出層很粗糙那些輸出層做得很精細的輸入層通常也不會差。這個判斷方法幫我省了很多研究新工具的時間。