先別急著 Scale。這句話聽(tīng)起來(lái)很反直覺(jué)尤其是在“AI”已經(jīng)被默認(rèn)和“規(guī)模化”綁在一起的今天。很多人拿到一個(gè)新模型、跑通一條生成流程后的第一反應(yīng)就是立刻把它放大從 20 條擴(kuò)到 2000 條從單機(jī)調(diào)到多機(jī)從一個(gè)人用變成全團(tuán)隊(duì)用。但我在實(shí)際項(xiàng)目里看到的往往是另一個(gè)版本的故事批量任務(wù)上線不到半天輸出質(zhì)量忽高忽低錯(cuò)誤日志堆滿了磁盤成本數(shù)字開(kāi)始讓人肉疼最后只能緊急拉停。問(wèn)題不全在模型也不全在并發(fā)。問(wèn)題在于很多團(tuán)隊(duì)把“單次跑通”誤當(dāng)成了“可以規(guī)模化”。在傳統(tǒng)軟件開(kāi)發(fā)里功能能跑通距離上線往往只差性能優(yōu)化和部署流程。但在 AI 時(shí)代這條路徑被徹底改寫了。因?yàn)?AI 的輸出不是確定性的你每一次調(diào)用得到的結(jié)果都可能不一樣如果你在沒(méi)有設(shè)計(jì)好反饋、日志、重試和人工校驗(yàn)邊界的情況下直接擴(kuò)容那么 scale 放大的不只是成功案例還會(huì)放大失敗率、幻覺(jué)、壞數(shù)據(jù)和沒(méi)人處理的異常。所以我的主判斷很明確AI 時(shí)代擴(kuò)容的第一順序不是加機(jī)器而是先把“可控性”擴(kuò)起來(lái)。這也是這篇文章想講清楚的事。1. AI 先改變的不是吞吐量而是“擴(kuò)容的瓶頸”1.1 傳統(tǒng)擴(kuò)容解決的是“資源夠不夠”新擴(kuò)容要解決的是“結(jié)果穩(wěn)不穩(wěn)”過(guò)去我們談?wù)?Scale通常是在談?wù)撏掏铝坑脩粽?qǐng)求變多了數(shù)據(jù)庫(kù)連接不夠了接口響應(yīng)變慢了那就加服務(wù)器、加緩存、加消息隊(duì)列。這套思路的底層假設(shè)是只要給足資源系統(tǒng)行為就能保持穩(wěn)定。AI 應(yīng)用的第一批規(guī)模化場(chǎng)景很容易讓人沿用舊思路。接口慢了可能是模型服務(wù)并發(fā)不夠任務(wù)多了可能是腳本跑得不夠快存儲(chǔ)滿了可能是數(shù)據(jù)同步不到位。這些判斷沒(méi)有錯(cuò)但只覆蓋了問(wèn)題的一半。另一半是每次調(diào)用模型拿到的輸出并不穩(wěn)定。同一段 prompt同一個(gè)輸入可能這輪輸出是對(duì)的下一輪就漏掉一個(gè)關(guān)鍵條件更麻煩的是模型在某些情況下會(huì)一本正經(jīng)地生成不存在的引用、錯(cuò)誤的參數(shù)、甚至完全偏移主題的內(nèi)容。也就是說(shuō)AI 系統(tǒng)的核心不確定性不在服務(wù)器而在輸出本身。這帶來(lái)的變化是擴(kuò)容的瓶頸從“資源飽和度”轉(zhuǎn)移到了“結(jié)果可信度”。你可以用 1000 臺(tái)機(jī)器把吞吐量撐上去但沒(méi)法用機(jī)器直接解決 5% 的壞輸出對(duì)下游系統(tǒng)造成的污染。1.2 真正的 scale 分為四層很多人只看到了第一層我通常會(huì)把 AI 系統(tǒng)的擴(kuò)容拆成四個(gè)層面流量規(guī)模單位時(shí)間內(nèi)能處理多少請(qǐng)求。數(shù)據(jù)規(guī)模知識(shí)庫(kù)、語(yǔ)料、文檔集有多大索引能不能跟上。任務(wù)規(guī)模批量任務(wù)能跑多長(zhǎng)、能支撐多少種輸入變化。反饋規(guī)模輸出結(jié)果有人看、有人審、有人修正、能回流進(jìn)下一輪改進(jìn)。傳統(tǒng)思路關(guān)注前兩層尤其是第一層。但 AI 項(xiàng)目真正容易崩的地方在第三層和第四層。流量規(guī)模上去之后如果任務(wù)輸入仍然五花八門腳本和提示詞很快就撐不住。數(shù)據(jù)規(guī)模上去之后如果你沒(méi)有建立對(duì)應(yīng)的上下文管理策略模型很容易在長(zhǎng)文檔里丟掉最關(guān)鍵的約束。任務(wù)規(guī)模上去之后如果失敗重試和人工審核跟不上壞數(shù)據(jù)就會(huì)直接進(jìn)入你可能還要用來(lái)做訓(xùn)練的成果集。所以我給團(tuán)隊(duì)的建議通常是先別急著把請(qǐng)求量拉到最高先確認(rèn)你的任務(wù)能不能扛住輸入變化你的結(jié)果有沒(méi)有人在看。這個(gè)順序一旦反了后面所有優(yōu)化都在給錯(cuò)誤加速。1.3 為什么“單條成功”會(huì)帶來(lái)安全感這里還有一種心理因素讓人更容易做出“先擴(kuò)容”的沖動(dòng)決定。當(dāng)你手動(dòng)跑到第 5 條、第 10 條時(shí)輸出看起來(lái)都不錯(cuò)你會(huì)產(chǎn)生一個(gè)很強(qiáng)的直覺(jué)這個(gè)流程已經(jīng)成熟了。然后你把并發(fā)調(diào)到 8 或者 16腳本開(kāi)始批量跑。你能看到的只是進(jìn)度條在往前走直到過(guò)了很久你翻結(jié)果目錄時(shí)才發(fā)現(xiàn)有一半輸出是重復(fù)的還有一部分壓根沒(méi)有按照 prompt 里的硬性要求輸出。原因很簡(jiǎn)單手動(dòng)驗(yàn)證時(shí)你的注意力在隱性地兜底。輸入是你一條條選的調(diào)用的順序是你控制的異常出現(xiàn)時(shí)你會(huì)下意識(shí)判斷并跳過(guò)。批量腳本沒(méi)有這個(gè)能力它只會(huì)把所有輸入一視同仁地交給模型然后把你沒(méi)有預(yù)料到的所有異常原樣寫進(jìn)結(jié)果里。因此真正的 Scale 準(zhǔn)備不是從 10 到 1000 直接跳而是先把“無(wú)人工干預(yù)時(shí)系統(tǒng)也能穩(wěn)定處理常見(jiàn)異常”這件事做好。注意批量調(diào)用之前先用 20 到 50 條有代表性的樣本跑一遍不要只跑順手的輸入。這一步會(huì)幫你過(guò)濾掉大多數(shù)“跑通假象”。2. 先擴(kuò)展工作流再擴(kuò)展規(guī)模提示詞、上下文和樣本基線2.1 提示詞不應(yīng)該硬編碼在腳本里很多人寫 AI 批處理腳本時(shí)會(huì)直接把 prompt 寫成字符串塞在代碼里。這在單次實(shí)驗(yàn)里沒(méi)什么問(wèn)題但你要 Scale 的時(shí)候它就是第一個(gè)坑。原因是提示詞一定會(huì)隨著任務(wù)變而你不會(huì)記得哪一版 prompt 對(duì)應(yīng)哪一輪輸出。如果哪天結(jié)果變差你根本說(shuō)不清楚是模型更新了、輸入數(shù)據(jù)變了還是提示詞被誰(shuí)動(dòng)過(guò)。我比較推薦的做法是把提示詞模板獨(dú)立成文件用版本號(hào)管理起來(lái)。腳本只負(fù)責(zé)加載模板、填充變量、調(diào)用模型、記錄結(jié)果。這樣你至少能做到每次調(diào)用都能回溯到當(dāng)時(shí)用的提示詞版本。下面是一個(gè)示意結(jié)構(gòu)關(guān)鍵不是代碼本身而是分層方式# prompts/generate_draft.txt 你是一名技術(shù)編輯。 根據(jù)下面的要點(diǎn)寫一段 300 字左右的博客草稿。 要求 - 語(yǔ)言自然不要廣告腔 - 開(kāi)頭要有具體場(chǎng)景 - 結(jié)尾要給一句實(shí)操建議。 【本期要點(diǎn)】 {{input}} 【參考材料】 {{context}}# process.py示意結(jié)構(gòu) import json import time from pathlib import Path prompt_template Path(prompts/generate_draft.txt).read_text(encodingutf-8) def call_model(system_prompt: str, user_prompt: str, model: str) - str: # 這里對(duì)接你自己的模型服務(wù) # 上線前先確認(rèn)上下文窗口、超時(shí)時(shí)間和錯(cuò)誤返回格式 return def run_one(sample: dict) - dict: prompt prompt_template.replace({{input}}, sample[input]) prompt prompt.replace({{context}}, sample.get(context, )) started time.time() output call_model( system_prompt你是一個(gè)嚴(yán)謹(jǐn)?shù)募夹g(shù)編輯, user_promptprompt, modelsample.get(model, default), ) return { sample_id: sample[id], prompt: prompt, output: output, duration_ms: int((time.time() - started) * 1000), created_at: time.time(), }注意這只是一個(gè)結(jié)構(gòu)示例不能直接跑。它的意義在于提醒你把“指令”“樣例輸入”“參考材料”分開(kāi)管理。后面排查“為什么這條輸出偏題”時(shí)你會(huì)節(jié)省大量時(shí)間。2.2 上下文要拆成三部分而不是一股腦全塞進(jìn)去做 AI 工程時(shí)間久了你會(huì)慢慢形成一個(gè)共識(shí)上下文管理往往比提示詞措辭更影響結(jié)果。我習(xí)慣把上下文拆成三層固定指令模型必須遵守的角色和規(guī)則比如輸出格式、字?jǐn)?shù)、語(yǔ)氣。動(dòng)態(tài)輸入當(dāng)次任務(wù)真正要處理的數(shù)據(jù)比如一段待總結(jié)的文檔。參考材料可選的背景知識(shí)比如企業(yè)知識(shí)庫(kù)片段、相關(guān)歷史結(jié)果。這三層不應(yīng)該混在同一個(gè)字符串里。原因是它們出問(wèn)題的概率完全不同。固定指令如果被輸入內(nèi)容“污染”模型可能忽略規(guī)則輸入內(nèi)容過(guò)長(zhǎng)可能把前面指令擠出上下文窗口參考材料如果太雜模型會(huì)失去焦點(diǎn)。在擴(kuò)容之前我建議你先把這三層寫清楚最好在代碼里用不同的變量管理。每輪調(diào)用結(jié)束以后把最終拼好的 prompt 也存進(jìn)日志。這樣出現(xiàn)壞結(jié)果時(shí)你能立刻看出是規(guī)則被覆蓋還是輸入本身有問(wèn)題還是參考材料給錯(cuò)了。2.3 建立你的“10 條樣本基線”我想給每個(gè)準(zhǔn)備 Scale 的團(tuán)隊(duì)推薦一個(gè)很輕量的做法先建立一個(gè)基線表不需要很重只需要 10 到 20 條代表性輸入。選擇樣本時(shí)不要只挑簡(jiǎn)單的。至少包含這幾類正常輸入。超短輸入比如只有一句話。超長(zhǎng)輸入比如接近上下文上限的文本。含特殊符號(hào)或代碼片段的輸入。之前模型最容易出錯(cuò)的輸入。然后逐條小批量執(zhí)行記錄輸出質(zhì)量。可以是人工打三個(gè)檔位通過(guò)、勉強(qiáng)通過(guò)、不通過(guò)。這組數(shù)據(jù)就是你的基線。之后每當(dāng)你調(diào)整提示詞、切換模型、改上下文策略、甚至升級(jí)依賴版本時(shí)都用同一批樣本重跑一遍。如果通過(guò)率明顯下降說(shuō)明你的改動(dòng)帶來(lái)了回歸。這比“感覺(jué)變好了”“效果差不多”這種判斷可靠得多。這里有一句我經(jīng)常對(duì)同事說(shuō)的話基線不是用來(lái)證明系統(tǒng)有多好而是用來(lái)防止你在擴(kuò)容之后才發(fā)現(xiàn)系統(tǒng)變差了。2.4 小批量試點(diǎn)是通往批量任務(wù)的唯一路徑當(dāng)你有了基線下一步不是直接上并發(fā)而是先跑一個(gè)小批量比如 200 條。小批量批次的意義在于你能完整地看一遍“輸入-調(diào)用-輸出-存儲(chǔ)”的閉環(huán)。你會(huì)看到某些輸入觸發(fā)了超時(shí)某些輸出沒(méi)有按 JSON 返回某些文件路徑有中英文混用問(wèn)題某些文本編碼導(dǎo)致腳本中斷。這些問(wèn)題在 10 條樣本里未必暴露但在 200 條里基本都會(huì)出現(xiàn)。等這個(gè)小批量跑完你再?zèng)Q定是不是要增加到幾千條節(jié)奏就穩(wěn)了。不要第一輪就把并發(fā)拉到 16。先以 1 并發(fā)跑 50 條確認(rèn)沒(méi)有底層配置問(wèn)題再以 4 并發(fā)跑 200 條觀察耗時(shí)和失敗率最后才考慮更高的并發(fā)。3. 從原型到生產(chǎn)差的不是模型而是日志、權(quán)限、異常和邊界3.1 日志是 Scale 的地基做不好一切無(wú)從談起在沒(méi)有日志的情況下討論擴(kuò)容基本等于閉著眼睛開(kāi)車。尤其是 AI 調(diào)用你不僅要記錄“調(diào)用了什么模型”還要記錄和業(yè)務(wù)強(qiáng)相關(guān)的字段。我在工程里至少會(huì)記錄這些內(nèi)容請(qǐng)求 ID 和業(yè)務(wù) ID。提示詞模板版本。最終拼出來(lái)的完整 prompt或至少它的哈希值。模型的返回原文。耗時(shí)、token 消耗。當(dāng)時(shí)使用的模型和參數(shù)。是否觸發(fā)重試、重試次數(shù)、最終是否成功。這個(gè)日志表不用一開(kāi)始設(shè)計(jì)得很龐大。最簡(jiǎn)單的方案是每行結(jié)果存成 JSON寫進(jìn)一個(gè)按日期切分的結(jié)果目錄。之后不管是排查壞樣本、統(tǒng)計(jì)成本還是復(fù)盤質(zhì)量都有據(jù)可查。很多團(tuán)隊(duì)在原型階段忽略日志等到生產(chǎn)環(huán)境出問(wèn)題再去補(bǔ)費(fèi)時(shí)費(fèi)力。更麻煩的是缺失的日志無(wú)法事后補(bǔ)回來(lái)。# 記錄一條結(jié)果到文件示意結(jié)構(gòu) import json from pathlib import Path def save_result(result: dict, out_dir: Path) - None: out_dir.mkdir(parentsTrue, exist_okTrue) path out_dir / f{result[sample_id]}.json with open(path, w, encodingutf-8) as f: json.dump(result, f, ensure_asciiFalse, indent2)3.2 異常重試要有但不能盲目重試AI 調(diào)用過(guò)程中網(wǎng)絡(luò)超時(shí)、模型服務(wù)限流、返回格式異常都很常見(jiàn)。沒(méi)有重試策略任務(wù)容易中斷重試太激進(jìn)又可能把限流打得更嚴(yán)重甚至造成成本浪費(fèi)。一個(gè)相對(duì)穩(wěn)妥的做法是第一次失敗后等待 1 秒再重試。第二次失敗后等待 5 秒再重試。連續(xù)三次失敗后寫入失敗隊(duì)列不再自動(dòng)重試。失敗隊(duì)列觸發(fā)告警由人工查看到底是什么原因。這里的關(guān)鍵判斷是不要默認(rèn)“重試一定能成功”。如果一條輸入反復(fù)失敗它是值得人工分析的壞樣本。如果你不區(qū)分失敗類型就無(wú)限重試最后只會(huì)得到一堆重復(fù)調(diào)用記錄以及一張高得嚇人的賬單。3.3 權(quán)限、密鑰和成本邊界要提前設(shè)計(jì)還有一個(gè)經(jīng)常被忽略的點(diǎn)是權(quán)限。原型階段你可能會(huì)圖省事把 API Key 直接寫在腳本里甚至放在前端請(qǐng)求里。這在個(gè)人電腦上問(wèn)題不大但一旦變成多人使用的服務(wù)就是嚴(yán)重風(fēng)險(xiǎn)。進(jìn)入生產(chǎn)前至少要確認(rèn)API Key 存放在服務(wù)端環(huán)境變量或密鑰管理服務(wù)中。前端和后端之間的調(diào)用經(jīng)過(guò)受控接口而不是直接暴露模型服務(wù)地址。不同角色使用不同的訪問(wèn)權(quán)限比如普通用戶不能改提示詞模板。設(shè)置單日調(diào)用上限和預(yù)算告警避免腳本 bug 導(dǎo)致成本失控。成本這塊我多強(qiáng)調(diào)一句AI 調(diào)用成本不是只算 token 費(fèi)用還要算失敗重試的成本、人工審核的成本、以及壞結(jié)果流入下游后返工的成本。很多人只盯著模型單價(jià)最后發(fā)現(xiàn)真正花費(fèi)時(shí)間的是清理壞數(shù)據(jù)。3.4 批量任務(wù)異常排查鏈路當(dāng)你真的遇到批量任務(wù)異常時(shí)建議按下面這個(gè)順序排查而不是直接懷疑模型不好用。先看現(xiàn)象是請(qǐng)求失敗、卡住不動(dòng)、輸出為空、還是輸出格式不對(duì)再看輸入這一批輸入是從哪里來(lái)的文件編碼對(duì)不對(duì)字段是否完整有沒(méi)有異常字符導(dǎo)致 prompt 拼接出錯(cuò)再看配置模型版本、提示詞版本、輸出目錄、權(quán)限、依賴庫(kù)版本最近有沒(méi)有變化再看參數(shù)并發(fā)數(shù)、超時(shí)時(shí)間、重試次數(shù)、上下文窗口是否和當(dāng)前任務(wù)匹配最后看模型服務(wù)上游是否限流服務(wù)是否健康最近模型是否有更新或調(diào)整。這個(gè)順序可以有效避免一個(gè)常見(jiàn)誤區(qū)一上來(lái)就改提示詞。很多問(wèn)題其實(shí)出在數(shù)據(jù)清洗和腳本健壯性上跟模型本身關(guān)系不大。4. 當(dāng)應(yīng)用從單人變成多人、多系統(tǒng)真正要擴(kuò)展的是反饋回路4.1 不要讓“提示詞大師”成為單點(diǎn)瓶頸在個(gè)人使用階段一個(gè)人可以靠記憶管理所有提示詞和參數(shù)。但 Scale 到團(tuán)隊(duì)協(xié)作時(shí)這就會(huì)變成災(zāi)難。團(tuán)隊(duì)里如果有一個(gè)人最懂提示詞所有人都在等他把規(guī)則調(diào)好。一旦他請(qǐng)假業(yè)務(wù)就卡住一旦他換了一版提示詞其他人根本不知道影響范圍。這不是團(tuán)隊(duì)能力問(wèn)題而是流程沒(méi)有可追溯性。我建議團(tuán)隊(duì)至少做到三點(diǎn)提示詞模板入庫(kù)有版本號(hào)。所有參數(shù)調(diào)整通過(guò)配置管理而不是散落在聊天記錄里。每周復(fù)盤一批壞樣本明確下一次迭代要改進(jìn)的規(guī)則。這三點(diǎn)沒(méi)有一項(xiàng)很復(fù)雜但它們決定了 AI 應(yīng)用能不能脫離個(gè)人英雄主義變成團(tuán)隊(duì)能持續(xù)迭代的能力。4.2 從直連腳本到接口化、隊(duì)列化當(dāng)接入方從一個(gè)腳本變成多個(gè)系統(tǒng)比如內(nèi)容平臺(tái)、運(yùn)營(yíng)后臺(tái)、產(chǎn)品接口你至少要開(kāi)始考慮接口化。接口化不是把腳本包一層 HTTP API 就完事而是要處理請(qǐng)求格式統(tǒng)一。鑒權(quán)和配額。結(jié)果異步獲取或回調(diào)。失敗任務(wù)的重新發(fā)送。調(diào)用方能看到任務(wù)狀態(tài)而不是只能等結(jié)果。一個(gè)常見(jiàn)的中間方案是引入任務(wù)隊(duì)列把所有調(diào)用轉(zhuǎn)成異步任務(wù)。這樣即使某個(gè)時(shí)刻調(diào)用量很大也不會(huì)把模型服務(wù)直接打掛。# 偽代碼任務(wù)隊(duì)列的基本思路 # submit_task(prompt_id, payload) # worker 進(jìn)程接收任務(wù) - 加載模板 - 調(diào)用模型 - 保存結(jié)果 - 寫日志 # 連續(xù)失敗超過(guò) 3 次 - 寫入 dead_letter 隊(duì)列 - 觸發(fā)告警如果你的團(tuán)隊(duì)已經(jīng)在用 Spring AI 這類集成框架接口化通常會(huì)省不少事。但框架不能替你決定日志結(jié)構(gòu)、權(quán)限邊界和人工審核流程。這些屬于系統(tǒng)設(shè)計(jì)不是框架職責(zé)。4.3 存儲(chǔ)和數(shù)據(jù)同步也要遵循“先小范圍驗(yàn)證”說(shuō)到數(shù)據(jù)規(guī)模這里有一個(gè)很容易踩的坑還沒(méi)想清楚目錄結(jié)構(gòu)就把整個(gè)歷史數(shù)據(jù)集復(fù)制到目標(biāo)環(huán)境。我在一些數(shù)據(jù)量級(jí)比較大的項(xiàng)目里見(jiàn)過(guò)這樣的問(wèn)題團(tuán)隊(duì)為了準(zhǔn)備訓(xùn)練語(yǔ)料一次性同步了幾千個(gè)文檔結(jié)果發(fā)現(xiàn)文件命名沖突、權(quán)限不一致、部分文件損壞最后只能清空重來(lái)。如果你想在 TrueNAS Scale 這類 NAS 平臺(tái)上配置數(shù)據(jù)同步方法可以很細(xì)但原則只有一個(gè)先配對(duì)兩臺(tái)機(jī)器同步一個(gè)小數(shù)據(jù)集確認(rèn)文件名、權(quán)限、修改策略都符合預(yù)期再放到定時(shí)任務(wù)里同步全量。這跟在 AI 批量任務(wù)里先跑 200 條再跑全量是同一個(gè)道理。不要被“全量同步”四個(gè)字迷惑。全量意味著你正在把一個(gè)小錯(cuò)誤放大成一次大規(guī)模返工。4.4 人工審核不是抽樣而是一條顯性流程很多團(tuán)隊(duì)在 Scale 之前總覺(jué)得自己的人工審核方案沒(méi)問(wèn)題。等到量起來(lái)后才發(fā)現(xiàn)所謂審核就是“抽空看看結(jié)果”一旦任務(wù)堆上來(lái)根本看不過(guò)來(lái)。正確做法是在流程設(shè)計(jì)階段就把人工審核占位。你可以按輸出類型和風(fēng)險(xiǎn)等級(jí)分類高風(fēng)險(xiǎn)內(nèi)容必須人工審核后才能發(fā)布。中風(fēng)險(xiǎn)內(nèi)容機(jī)器預(yù)審合格后再人工抽檢。低風(fēng)險(xiǎn)內(nèi)容系統(tǒng)自動(dòng)處理定期復(fù)盤壞樣本。關(guān)鍵不是“有沒(méi)有人看”而是“誰(shuí)能決定要不要看”。這個(gè)判斷如果做不好要么審核過(guò)度拖慢效率要么審核不足放大風(fēng)險(xiǎn)。5. 擴(kuò)容前先回答五個(gè)問(wèn)題一個(gè)可復(fù)用的判斷清單5.1 你能否說(shuō)清當(dāng)前失敗率如果我問(wèn)你最近 1000 次調(diào)用里有多少次輸出不合格你能立刻答出來(lái)嗎如果答案是“沒(méi)人統(tǒng)計(jì)過(guò)”那就說(shuō)明現(xiàn)在不適合擴(kuò)容。失敗率是 AI 系統(tǒng)最重要的健康指標(biāo)。它可以是自動(dòng)評(píng)估也可以是人抽檢后的統(tǒng)計(jì)但必須有一個(gè)數(shù)字。沒(méi)有失敗率的擴(kuò)容是在賭運(yùn)氣。5.2 失敗之后誰(shuí)能看到、誰(shuí)能重試批量任務(wù)跑完之后如果有 30 條壞結(jié)果它們會(huì)被記錄到哪里誰(shuí)會(huì)收到通知重試失敗后下一步動(dòng)作是什么沒(méi)有這個(gè)流程壞結(jié)果只會(huì)在系統(tǒng)里安靜地躺著直到某一天有人發(fā)現(xiàn)成果集里有大量低質(zhì)量?jī)?nèi)容。5.3 成本增長(zhǎng)是線性的還是非線性變陡調(diào)用量翻倍成本也翻倍這是線性增長(zhǎng)還好估算。但如果你用了重試機(jī)制、加了更長(zhǎng)上下文、或者每次失敗都要人工處理成本可能遠(yuǎn)遠(yuǎn)超過(guò)任務(wù)量增速。擴(kuò)容之前建議先算一筆賬跑 1000 條需要多少錢其中模型費(fèi)用多少、超時(shí)重試費(fèi)用多少、人工審核時(shí)間多少。如果這筆賬算不出來(lái)就不要急著擴(kuò)量。5.4 人工校驗(yàn)的邊界寫清楚了嗎不是所有任務(wù)都需要人工審核但你必須清楚哪些任務(wù)不需要。判斷標(biāo)準(zhǔn)可以是業(yè)務(wù)風(fēng)險(xiǎn)、內(nèi)容合規(guī)、下游用途、數(shù)據(jù)敏感度等。如果這個(gè)邊界沒(méi)寫清楚那你所謂的審核流程就是看心情。這種不確定性在規(guī)模化之后會(huì)成為比模型失敗率更麻煩的管理問(wèn)題。5.5 這只是擴(kuò)充一次任務(wù)還是要讓它每天穩(wěn)定運(yùn)行這是最后一個(gè)問(wèn)題也是最關(guān)鍵的判斷。一次性跑一批任務(wù)是項(xiàng)目每天穩(wěn)定運(yùn)行是產(chǎn)品。兩者的工程要求完全不同。如果只是臨時(shí)跑一批你只需保證腳本能跑完、結(jié)果能保存。但如果是每天運(yùn)行你還需要考慮調(diào)度、監(jiān)控、告警、數(shù)據(jù)備份、輸出人工審核、模型版本升級(jí)策略。我見(jiàn)過(guò)不少團(tuán)隊(duì)把一次性任務(wù)腳本直接丟到生產(chǎn)計(jì)劃任務(wù)里結(jié)果一個(gè)周末沒(méi)人盯著積累了幾千條重復(fù)輸出。5.6 一張簡(jiǎn)單的判斷表判斷項(xiàng)適合擴(kuò)容的跡象先別擴(kuò)容的跡象失敗率低于 1%錯(cuò)誤種類集中高于 5%每條輸出錯(cuò)誤類型都不一樣反饋回路有結(jié)果庫(kù)壞樣本每周復(fù)盤結(jié)果散落在各人電腦和聊天記錄里成本有預(yù)算監(jiān)控單條成本波動(dòng)小沒(méi)有人知道這個(gè)月消耗了多少 token人工審核明確哪些輸出必須人審?fù)耆蕾嚹Ｐ洼敵鰶](méi)有審核環(huán)節(jié)流程復(fù)用提示詞、參數(shù)、數(shù)據(jù)版本可回溯還在靠某個(gè)人記憶里的參數(shù)和規(guī)則啟動(dòng)方式先小批量驗(yàn)證再逐步放量一批直接拉滿全量這五問(wèn)不是形式主義它們對(duì)應(yīng)的是 Scale 前必須補(bǔ)齊的五塊拼圖質(zhì)量基線、反饋機(jī)制、成本模型、人工邊界和可運(yùn)維性。任何一個(gè)缺位擴(kuò)容都不是加速而是放大故障。如果你這周只做一件事我建議做一次基線測(cè)試挑 10 條有代表性的輸入跑一遍把輸出、耗時(shí)、錯(cuò)誤、備注記下來(lái)。然后帶著這份基線去和同事討論“是不是真的可以 Scale”。你會(huì)發(fā)現(xiàn)真正值得擴(kuò)展的不是并發(fā)數(shù)而是你對(duì)這套系統(tǒng)運(yùn)行規(guī)律的理解。先把可控性擴(kuò)起來(lái)這才是 AI 時(shí)代 scale 的正確起點(diǎn)。