做智能客服這幾年我最大的感受就是用戶根本不在乎你底層是規(guī)則引擎還是大模型他們在乎的是“同一件事?lián)Q個說法你還能不能聽懂”“上次剛說過的情況這次還要不要再重復(fù)一遍”。這也是我們點(diǎn)控云團(tuán)隊(duì)下決心把整個客服技術(shù)底座推翻重來的原因。傳統(tǒng)的意圖識別加檢索問答在固定場景下夠用但一旦對話拐個彎或者用戶帶著歷史訴求回來追問系統(tǒng)就徹底失憶。所以從去年開始我們圍繞自研大模型和雙層記憶重構(gòu)了整套智能客服架構(gòu)今天就把這套技術(shù)底座的完整復(fù)盤寫出來包括為什么選這個方案、記憶層怎么設(shè)計(jì)、落地時踩了哪些坑希望給正在做同類系統(tǒng)的團(tuán)隊(duì)一些參考。1. 整體設(shè)計(jì)思路為什么必須自研大模型加雙層記憶1.1 傳統(tǒng)智能客服到底差在哪先說傳統(tǒng)方案的三個硬傷。第一是規(guī)則引擎和按鍵菜單的交互方式太僵化用戶說“我要退貨”和“我不想要了怎么弄”得配置完全不同的兩條規(guī)則漏一條就漏一片。第二是檢索式問答只能做單輪匹配用戶說“那運(yùn)費(fèi)呢”系統(tǒng)根本不知道“那”指的是剛才那筆退貨訂單的運(yùn)費(fèi)。第三也是最致命的就是完全沒有跨會話的記憶能力——用戶兩周前剛提交過售后工單這次再來追問進(jìn)度客服機(jī)器人面對這個熟悉的老客戶表現(xiàn)得跟第一次見面一樣。這些問題的根源在于傳統(tǒng)架構(gòu)把一次對話當(dāng)成一個孤立事件來處理既沒有語義理解能力也沒有狀態(tài)保持能力。我們統(tǒng)計(jì)過自己平臺上的客服對話數(shù)據(jù)大約三成以上的用戶咨詢是涉及歷史信息的比如查訂單、跟蹤進(jìn)度、追問處理方案。這部分需求用規(guī)則和檢索根本覆蓋不了必須從底層換思路。1.2 為什么選擇自研大模型而非直接調(diào)API這里可能有人會問現(xiàn)在開源大模型那么多直接接API不就行了嗎為什么要自研我們當(dāng)時的判斷有三個方面。第一個是數(shù)據(jù)安全與合規(guī)問題客服場景里全是用戶手機(jī)號、訂單詳情、售后記錄這些數(shù)據(jù)出域去調(diào)第三方API無論從合規(guī)角度還是從品牌聲譽(yù)風(fēng)險角度都不可接受私有化部署是硬要求。第二個是定制化問題業(yè)務(wù)方希望模型在售前導(dǎo)購、售后處理、投訴安撫這些細(xì)分場景上有穩(wěn)定表現(xiàn)通用大模型做不到這種深度適配必須自己做領(lǐng)域微調(diào)。第三個是長期成本問題按調(diào)用量計(jì)費(fèi)的API在峰值期費(fèi)用非常不可控而自研模型在充分優(yōu)化后單次推理的邊際成本是可以壓到很低的。也補(bǔ)充一句我們并不是說自研就一定比其他方式高級。如果團(tuán)隊(duì)剛起步、數(shù)據(jù)量不大、對延遲和數(shù)據(jù)出境沒有嚴(yán)格要求直接調(diào)用成熟API快速驗(yàn)證需求完全合理。但如果你做的是企業(yè)級客服底座并且打算長期在這個方向深耕那自研大模型配合領(lǐng)域微調(diào)的路線遲早要走。1.3 雙層記憶到底是什么解決什么問題記憶是智能客服從“能用”走向“好用”的分水嶺。我們最終落地的方案是把記憶分成短期記憶和長期記憶兩層各司其職。短期記憶負(fù)責(zé)當(dāng)前會話之內(nèi)的上下文保持比如用戶剛才提過訂單號、剛才確認(rèn)過退貨方案在下一輪回答的時候都要用得上。實(shí)現(xiàn)上主要是會話級的狀態(tài)管理包括原始對話內(nèi)容、關(guān)鍵信息槽位、當(dāng)前意圖棧。長期記憶則負(fù)責(zé)跨會話的用戶畫像與業(yè)務(wù)信息沉淀比如這個用戶的會員等級、歷史偏好、之前的投訴記錄、上次沒解決完的問題。有了這一層系統(tǒng)才能做到老客戶一開口就知道他是誰、他過去發(fā)生過什么、他大概率需要什么。我用一個生活化的類比來幫助理解短期記憶就像飯店服務(wù)員手里那張點(diǎn)菜單客人這桌點(diǎn)了什么、有什么忌口都在上面但這桌客人吃完走了這張菜單也就作廢了。長期記憶則像餐廳的客戶檔案本哪個熟客口味偏咸、哪桌客人上次投訴過上菜慢翻一翻檔案就心里有數(shù)。一個合格的智能客服既不能丟掉眼前的點(diǎn)菜單也不能把客戶檔案本當(dāng)成廢紙扔了。2. 自研大模型的選型、微調(diào)與部署實(shí)踐2.1 模型基座選擇與中文能力評估自研大模型的起點(diǎn)是選基座。我們在選型時主要看四個維度中文語義理解能力、上下文長度、推理資源消耗、社區(qū)生態(tài)成熟度。當(dāng)時測試對比了好幾款主流開源基座從7B到13B到更大的規(guī)模都跑了一遍。測試方法也很樸素就是拿真實(shí)脫敏客服語料構(gòu)造了一批意圖分類和多輪對話樣本看模型在相同參數(shù)下的準(zhǔn)確率和響應(yīng)質(zhì)量。最終我們選擇的是基于13B量級的基座繼續(xù)走。原因很直接7B模型部署成本低、速度快但在處理復(fù)雜意圖和多輪指代消解的時候明顯吃力13B模型的理解能力上了一個臺階配合量化部署后單卡也能跑起來綜合性價比最合適。如果你們的業(yè)務(wù)涉及很多垂直術(shù)語建議基座選型時就專門測一下領(lǐng)域文本的困惑度和抽取準(zhǔn)確率別只看通用榜單的成績。這里也提醒一點(diǎn)很多人選基座只盯著參數(shù)量忽略了tokenizer詞表對中文的支持程度。有些模型英文很強(qiáng)但中文詞表覆蓋差會導(dǎo)致中文場景下token切得很碎推理開銷增大且語義受損。我們當(dāng)時的測試標(biāo)準(zhǔn)里專門有一項(xiàng)用相同長度的一批中文句子對比token消耗量差距能到百分之二三十這個必須提前摸清楚。2.2 領(lǐng)域微調(diào)的數(shù)據(jù)準(zhǔn)備與訓(xùn)練配置選好基座之后就是微調(diào)。客服領(lǐng)域微調(diào)的數(shù)據(jù)主要來自三類歷史優(yōu)質(zhì)會話記錄、業(yè)務(wù)方整理的標(biāo)準(zhǔn)問答對、人工標(biāo)注的意圖和情緒標(biāo)簽。我們把這些數(shù)據(jù)整理成指令微調(diào)格式每個樣本包含角色信息、當(dāng)前問題、上下文和標(biāo)準(zhǔn)回答。數(shù)據(jù)清洗這一步最花時間。原始客服會話里有很多口語化表達(dá)、錯別字、敏感信息還有一半以上的對話是無效寒暄。我們寫了一套預(yù)處理流水線先做敏感信息脫敏再做相似會話去重最后靠人工質(zhì)檢保證數(shù)據(jù)質(zhì)量。說實(shí)話微調(diào)的效果好不好七分看數(shù)據(jù)三分看參數(shù)寧可把數(shù)據(jù)準(zhǔn)備好再訓(xùn)練也不要急著跑實(shí)驗(yàn)。訓(xùn)練配置上我們用的經(jīng)驗(yàn)值是學(xué)習(xí)率設(shè)置在2e-5到5e-5之間用余弦衰減訓(xùn)練輪數(shù)不要貪多3到5個epoch就足夠了太多反而會過擬合到訓(xùn)練集上導(dǎo)致在真實(shí)對話里泛化能力下降。LoRA這類參數(shù)高效微調(diào)技術(shù)我們也測過它確實(shí)能大幅降低顯存門檻但初期微調(diào)還是建議先做全量微調(diào)等業(yè)務(wù)穩(wěn)定了再用LoRA做增量更新。2.3 推理部署與性能優(yōu)化方案微調(diào)完成后的部署環(huán)節(jié)核心是把成本和延遲控制在可接受范圍。我們用vLLM作為推理服務(wù)框架它有幾個特性對客服場景特別有價值其中最有用的就是Prefix Caching——對所有用戶都共享系統(tǒng)提示詞、知識庫公共前綴這些重復(fù)內(nèi)容做緩存實(shí)際測試中這部分內(nèi)容占比非常高開啟后首token延遲明顯下降GPU利用率也上來了。量化方案我們選了INT8起步因?yàn)榭头鼍皩卮鹳|(zhì)量要求很高INT4在部分復(fù)雜回答上會出現(xiàn)可感知的質(zhì)量下降。如果你們后續(xù)模型規(guī)模繼續(xù)增大可以用AWQ或GPTQ做更激進(jìn)的量化但上線前一定拿真實(shí)對話樣本做AB對比測試不能只看Perplexity指標(biāo)。部署拓?fù)浞矫嫖覀冏鲞^兩套方案單機(jī)多卡部署一套大模型多機(jī)多卡部署多套模型副本。實(shí)際跑下來對于日均幾十萬次對話的規(guī)模三臺雙卡機(jī)器做成推理集群前面架一層負(fù)載均衡和請求排隊(duì)已經(jīng)完全夠用。模型副本之間沒有狀態(tài)天然支持水平擴(kuò)容。這里建議流量入口處一定要做超時控制和降級開關(guān)萬一模型推理出現(xiàn)抖動或者隊(duì)列積壓可以直接降級到檢索式問答兜底保證用戶至少能拿到基礎(chǔ)回復(fù)而不是轉(zhuǎn)圈圈或報(bào)錯。3. 雙層記憶機(jī)制的設(shè)計(jì)與工程實(shí)現(xiàn)3.1 短期記憶會話上下文的分層管理短期記憶這塊沒有用特別復(fù)雜的技術(shù)核心解決的問題是“什么該留、什么該丟”。原始的對話內(nèi)容如果全部塞進(jìn)大模型上下文一方面token消耗大另一方面超過窗口長度后模型會對早期信息失焦。我們的做法是把短期記憶拆成三級原始對話buffer、結(jié)構(gòu)化信息槽位、會話摘要。原始對話buffer保留最近幾輪完整的用戶輸入和系統(tǒng)輸出用于處理指代和省略。結(jié)構(gòu)化信息槽位則實(shí)時抽取并維護(hù)當(dāng)前會話中的關(guān)鍵實(shí)體比如訂單號、退款金額、商品型號——這幾個字段是業(yè)務(wù)查詢的高頻維度抽到就放進(jìn)槽位后續(xù)輪次直接讀取不依賴模型重新理解。會話摘要是當(dāng)輪次過多時由模型自動壓縮出來的把早期對話濃縮成幾十字的摘要釋放上下文空間。做一個簡短的計(jì)算示例如果每輪平均消耗400個token20輪就是8000個token在8K窗口的模型上已經(jīng)快頂?shù)缴舷蘖?。引入三級管理后原始buffer只保留最近8輪約3200個token加上壓縮后的摘要和槽位信息整個上下文控制在5000個token左右既能保住關(guān)鍵歷史信息又給當(dāng)前輪次留出充足的推理空間。3.2 長期記憶用戶畫像與業(yè)務(wù)知識如何沉淀為可檢索記憶長期記憶層的建設(shè)是這個項(xiàng)目里工程量最大的部分。簡單說它的職責(zé)是把一個用戶在所有歷史會話中產(chǎn)生的高價值信息沉淀成結(jié)構(gòu)化檔案和向量化記憶兩種形態(tài)。結(jié)構(gòu)化檔案主要存那些字段明確、穩(wěn)定變化的數(shù)據(jù)比如用戶ID、會員等級、常用收貨地址、歷史訂單數(shù)、最近一次投訴類別。這類數(shù)據(jù)的寫入邏輯很簡單對接業(yè)務(wù)系統(tǒng)就能同步。真正需要花心思的是非結(jié)構(gòu)化信息的沉淀比如用戶上次反饋“對物流速度非常不滿”、用戶偏好“客服回復(fù)盡量簡潔直接”這些信息藏在對話文本里需要抽取和向量化之后存到向量數(shù)據(jù)庫中。信息抽取我們參考了OneKE這類知識抽取框架的思路先識別實(shí)體再抽取實(shí)體間的關(guān)系最后落成三元組結(jié)構(gòu)。比如用戶說“我去年買的那個吹風(fēng)機(jī)壞了”系統(tǒng)會抽取出“用戶-購買-吹風(fēng)機(jī)”“吹風(fēng)機(jī)-購買時間-去年”“吹風(fēng)機(jī)-狀態(tài)-損壞”這幾組事實(shí)。然后再將整段用戶描述和抽取結(jié)果同時向量化寫入向量庫查詢的時候用用戶當(dāng)前的輸入做相似度檢索把最相關(guān)的歷史記憶召回。長期記憶還有一個關(guān)鍵設(shè)計(jì)是寫入策略和遺忘策略。寫入策略分兩種一種是會話結(jié)束后異步批量寫入把本次對話里的高價值信息更新到用戶檔案另一種是當(dāng)用戶明確表達(dá)某些長期偏好時觸發(fā)即時寫入比如“以后發(fā)貨前請先電話確認(rèn)”。遺忘策略則對應(yīng)數(shù)據(jù)合規(guī)要求用戶注銷或要求刪除時要能把對應(yīng)的結(jié)構(gòu)化數(shù)據(jù)和向量條目一并清除這個功能在設(shè)計(jì)階段就預(yù)留了接口千萬不能等上線后再補(bǔ)。3.3 兩層記憶如何協(xié)同工作短期記憶和長期記憶不是兩個獨(dú)立模塊它們需要在一個完整的請求鏈路里配合。我以真實(shí)場景走一遍全流程大家感受一下協(xié)同方式。假設(shè)一個用戶之前買過產(chǎn)品并投訴過物流慢今天再次進(jìn)線說“上次那個東西怎么還沒到”。請求進(jìn)來后系統(tǒng)先用用戶ID從長期記憶層拉取畫像和歷史檔案發(fā)現(xiàn)這個用戶存在“物流慢投訴”記錄。然后短期記憶層初始化把本次會話的上下文結(jié)構(gòu)建好。模型在生成回答時系統(tǒng)提示詞里會注入兩份信息長期記憶里的用戶畫像摘要、短期記憶里的當(dāng)前會話上下文。于是模型結(jié)合“老投訴客戶”和“當(dāng)前訂單查詢”兩層信息生成的回復(fù)會主動帶上道歉語氣和物流補(bǔ)償方案而不是干巴巴丟一個物流單號。會話結(jié)束后系統(tǒng)再異步把本次交互中新增的有效信息回寫進(jìn)長期記憶比如用戶當(dāng)前的訂單狀態(tài)更新。這樣一個完整的記憶閉環(huán)就跑起來了。協(xié)同的關(guān)鍵在于長期記憶負(fù)責(zé)“讓系統(tǒng)知道你是誰”短期記憶負(fù)責(zé)“讓系統(tǒng)記得我們剛剛聊到哪”兩者缺一不可。4. 智能客服業(yè)務(wù)鏈路的落地實(shí)操4.1 核心流程梳理從意圖識別到工單閉環(huán)有了模型底座和記憶層整個智能客服的業(yè)務(wù)鏈路還需要重新編排。我們最終線上運(yùn)行的流程分五個環(huán)節(jié)請求接入、意圖識別、策略分發(fā)、推理生成、服務(wù)閉環(huán)。請求接入層先做渠道歸一不管是網(wǎng)頁、小程序還是APP都統(tǒng)一轉(zhuǎn)成內(nèi)部消息協(xié)議。意圖識別是整個流程的閘門我們直接復(fù)用自研大模型來做而不是單獨(dú)訓(xùn)練一個意圖分類小模型——因?yàn)榇竽Ｐ驮诶斫饽：磉_(dá)和生僻說法上明顯更強(qiáng)。模型先判斷這個用戶進(jìn)來是咨詢、是投訴、是查詢還是閑聊再結(jié)合長期記憶里的用戶檔案決定走哪條處理路徑。策略分發(fā)這個環(huán)節(jié)是規(guī)則與大模型的結(jié)合點(diǎn)。比如檢測到用戶情緒是憤怒且歷史有投訴記錄就走優(yōu)先轉(zhuǎn)人工流程如果只是普通售前咨詢則進(jìn)入純模型對話如果涉及訂單等結(jié)構(gòu)化查詢先通過槽位信息調(diào)業(yè)務(wù)API拿最新數(shù)據(jù)再讓模型基于實(shí)時數(shù)據(jù)生成回答。最后服務(wù)閉環(huán)負(fù)責(zé)把會話結(jié)果沉淀回業(yè)務(wù)系統(tǒng)包括生成服務(wù)摘要、更新工單狀態(tài)、觸發(fā)滿意度回訪。4.2 提示詞工程與知識庫問答的落地細(xì)節(jié)純靠模型記憶解決不了企業(yè)私有知識的問題所以RAG檢索增強(qiáng)生成是智能客服落地逃不掉的一環(huán)。我們在知識庫建設(shè)上踩過不少坑這里分享兩個關(guān)鍵經(jīng)驗(yàn)。第一個是知識庫分塊策略。早期我們按固定長度切分知識文檔結(jié)果經(jīng)常把一塊完整內(nèi)容從中間切斷導(dǎo)致檢索召回的是半截話模型回答自然就歪了。后來改成熟知的做法先按篇章結(jié)構(gòu)切分再對每個段落做語義完整性校驗(yàn)如果段落過長再做二次切分并保留標(biāo)題上下文。文檔標(biāo)題和層級信息在向量化時需要拼進(jìn)塊內(nèi)容里這樣檢索匹配度提升非常明顯。第二個是提示詞里知識引用的格式。我們要求模型在使用檢索到的知識時輸出內(nèi)容必須帶有來源編號同時我們自己寫了一個知識引用一致性校驗(yàn)?zāi)K在模型回答后檢查回答內(nèi)容與引用知識之間是否存在明顯矛盾。這個模塊用規(guī)則加模型打分混合實(shí)現(xiàn)規(guī)則負(fù)責(zé)抓硬傷模型打分處理語義層面的偏差雖然增加了一點(diǎn)推理延遲但換來的準(zhǔn)確率提升非常值。4.3 與業(yè)務(wù)系統(tǒng)的對接方式客服系統(tǒng)不可能脫離訂單、售后、物流體系獨(dú)立存在。我們做對接時采用了一個輕量級的工具調(diào)用層設(shè)計(jì)每個業(yè)務(wù)系統(tǒng)能力封裝成獨(dú)立的Function通過統(tǒng)一的協(xié)議暴露給大模型。模型根據(jù)當(dāng)前對話場景決定是否調(diào)用以及傳遞哪些參數(shù)。比如用戶問“幫我改一下收貨地址”模型識別到這是個地址修改意圖就調(diào)用地址修改接口必要參數(shù)從短期記憶槽位里取缺失參數(shù)生成反問句向用戶追問。接口返回值不會直接拼進(jìn)回答里而是經(jīng)過一層格式化加工。系統(tǒng)提示詞中定義了統(tǒng)一的數(shù)據(jù)展示規(guī)范比如日期統(tǒng)一成“X月X日”、金額保留兩位小數(shù)、地址做脫敏展示。這一步看著不起眼但線上回答的專業(yè)感全靠這些細(xì)節(jié)撐起來。另外所有通過工具調(diào)用支撐業(yè)務(wù)操作都需要二次確認(rèn)再補(bǔ)一個用戶撤回機(jī)制萬一模型理解錯誤執(zhí)行了錯誤的修改操作用戶能自己撤銷避免糾紛。5. 常見問題與排查技巧實(shí)錄5.1 模型幻覺怎么控制大模型客服最怕一本正經(jīng)胡說八道尤其涉及訂單狀態(tài)、退款金額這種具體數(shù)據(jù)。我們的治理思路是“結(jié)構(gòu)化數(shù)據(jù)禁止模型編造文本潤色才放給模型發(fā)揮”。所有跟業(yè)務(wù)強(qiáng)相關(guān)的數(shù)據(jù)一律通過工具調(diào)用從業(yè)務(wù)系統(tǒng)獲取真實(shí)數(shù)據(jù)然后要求模型只做信息的重組和表達(dá)不允許修改任何關(guān)鍵數(shù)值。在提示詞里我們加了一條硬性約束“如果你無法從提供的資料或上下文中找到答案必須明確表示不知道并提供轉(zhuǎn)人工選項(xiàng)?！边@套約束加上之后虛構(gòu)回答的比例下降非常明顯。但如果你們的場景必須讓模型做數(shù)值推斷可以另外接入一套規(guī)則校驗(yàn)對金額、日期、單號等敏感字段做格式和合法性檢查不合法就觸發(fā)重寫或轉(zhuǎn)人工。5.2 上下文截?cái)鄬?dǎo)致答非所問上線初期我們遇到過一類典型的bad case用戶聊到十幾輪后突然問“那第二個方案呢”模型完全不知道“第二個方案”指的是什么。定位后發(fā)現(xiàn)是原始對話buffer只保留最近8輪而“第二個方案”是在第10輪提到的已經(jīng)被提出去了。會話摘要也沒有記錄這個信息因?yàn)檎旧硎敲?輪生成一次跨度太大丟了很多中間細(xì)節(jié)。這個問題的根治方案是給短期記憶增加關(guān)鍵信息追蹤?，F(xiàn)在我們的對話buffer里除了原始輪次還會實(shí)時維護(hù)一個“方案列表”類型的槽位每當(dāng)模型給出方案性內(nèi)容時自動編號存入槽位后續(xù)用戶提到“第二個”或“剛才說的那個”就能直接命中。記憶設(shè)計(jì)不能只看輪次窗口還要考慮業(yè)務(wù)語義信息的連續(xù)性。5.3 檢索召回率低怎么辦知識庫問答召回不準(zhǔn)這個事我們從三個方向同時優(yōu)化。首先在向量模型選型上直接從通用向量模型換成了在中文語料上表現(xiàn)更好的bge-m3換完直觀感覺是召回質(zhì)量提升了一個檔次。其次在查詢側(cè)做了改寫用戶的原始問題比較口語化先用大模型把問題改寫為更規(guī)范的知識檢索語句再去query向量庫實(shí)測top5準(zhǔn)確率提升約十幾個百分點(diǎn)。最后是混合檢索利用數(shù)據(jù)庫里的BM25全文索引和向量檢索做加權(quán)融合尤其針對那些包含精確型號、編號的查詢關(guān)鍵詞命中的價值甚至超過語義匹配。5.4 高并發(fā)下的性能瓶頸大模型推理是高并發(fā)場景下的最大瓶頸。我們的優(yōu)化手段分三層。第一層是推理引擎層前面提到的vLLM連續(xù)批處理和Prefix Caching在這里發(fā)揮主要作用能把GPU利用率提上去。第二層是業(yè)務(wù)層給不同渠道的請求設(shè)置不同的優(yōu)先級隊(duì)列比如投訴渠道優(yōu)先處理普通閑聊排隊(duì)防止低價值請求把推理資源占滿。第三層是容量規(guī)劃我們做了一個非常樸素但有效的壓測方法把歷史真實(shí)流量錄制下來按不同倍速回放找到系統(tǒng)在每秒多少個并發(fā)請求下才出現(xiàn)超時率飆升然后用這個數(shù)值的60%作為日常容量水位線留足冗余應(yīng)對突發(fā)流量。5.5 成本控制實(shí)用技巧最后說說大家都很關(guān)心的token成本。長期跑下來最大的消耗點(diǎn)不在推理本身而在于冗余的上下文。我們持續(xù)在做上下文瘦身短期記憶字段能精確到槽位就用槽位不要堆積大段歷史文本系統(tǒng)提示詞也定期迭代去掉效果不明顯的長篇描述模型回答部分開啟流式輸出后用戶可以提前終止還能省掉后續(xù)token生成的開銷。另一個容易被忽略的省錢點(diǎn)是日志存儲完整對話記錄必須保留但向量化副本不需要存全量只保留抽取出來的記憶條目能省下不少向量庫的存儲費(fèi)用。根據(jù)我們實(shí)際跑下來的數(shù)據(jù)這套自研大模型加雙層記憶的架構(gòu)上線后多輪對話的任務(wù)完成率比之前提升了接近一倍轉(zhuǎn)人工率降了四成左右用戶滿意度也明顯回升。當(dāng)然技術(shù)底座只是把地基夯實(shí)了真正的服務(wù)體驗(yàn)還要靠業(yè)務(wù)策略持續(xù)迭代。用幾張圖把架構(gòu)畫出來給團(tuán)隊(duì)看容易讓每一個模塊在線上穩(wěn)定跑起來、遇到問題能快速定位才是真功夫。至少對我們來說這個方向走對了后續(xù)還會沿著“更精準(zhǔn)的記憶寫入”和“更自然的引導(dǎo)式對話”繼續(xù)打磨。