1. 從數(shù)字人到知識(shí)引擎這套組合拳到底在解決什么問題數(shù)字人這兩年熱度一直沒降過但真正在一線做過落地的人都知道早期的數(shù)字人項(xiàng)目大多停留在“能說會(huì)動(dòng)”的階段——嘴型對得上、表情不僵硬、語音合成聽起來像真人就算交差了?？梢坏┛蛻魡柍觥澳銈冞@個(gè)數(shù)字人能不能回答我關(guān)于產(chǎn)品保修政策的具體問題”很多項(xiàng)目就露餡了。原因很簡單數(shù)字人的“大腦”和“嘴巴”是兩套系統(tǒng)嘴巴做得再好大腦里沒有對應(yīng)的知識(shí)回答就只能靠預(yù)設(shè)腳本硬撐。騰訊這套數(shù)字人與大模型知識(shí)引擎的產(chǎn)品組合本質(zhì)上就是在補(bǔ)“大腦”這一環(huán)。它把混元大模型作為推理內(nèi)核把向量數(shù)據(jù)庫作為知識(shí)存儲(chǔ)和檢索的底座再通過RAG檢索增強(qiáng)生成的架構(gòu)把兩者串起來最終讓數(shù)字人具備“基于企業(yè)私有知識(shí)進(jìn)行準(zhǔn)確問答”的能力。這不是一個(gè)單點(diǎn)工具而是一條從知識(shí)入庫、向量化、檢索召回、到大模型生成、再到數(shù)字人播報(bào)的完整鏈路。這套東西適合誰看如果你是企業(yè)側(cè)的AI應(yīng)用開發(fā)者正在評估數(shù)字人項(xiàng)目的技術(shù)選型或者你已經(jīng)在做RAG相關(guān)的應(yīng)用但苦于不知道怎么和數(shù)字人前端打通那這篇內(nèi)容就是為你準(zhǔn)備的。我會(huì)從整體架構(gòu)講到每個(gè)環(huán)節(jié)的實(shí)操細(xì)節(jié)包括向量數(shù)據(jù)庫怎么選、知識(shí)切分怎么做、召回效果怎么調(diào)、數(shù)字人接口怎么對接盡量把踩過的坑和驗(yàn)證過的方案都攤開來說。2. 整體架構(gòu)拆解為什么是“混元向量數(shù)據(jù)庫RAG”這個(gè)組合2.1 數(shù)字人項(xiàng)目的核心瓶頸從來不在“人”而在“知”我做過好幾個(gè)數(shù)字人項(xiàng)目早期用過的方案無非是兩種一種是純腳本驅(qū)動(dòng)把所有可能的問答對寫死在配置文件里數(shù)字人根據(jù)關(guān)鍵詞匹配來播報(bào)對應(yīng)內(nèi)容另一種是接一個(gè)通用大模型API讓模型自由發(fā)揮。前者的問題是知識(shí)更新極其痛苦每加一個(gè)產(chǎn)品型號就要改一遍腳本維護(hù)成本隨知識(shí)量線性增長后者的問題是模型會(huì)“胡說”尤其是在企業(yè)場景下編造一個(gè)不存在的保修期限或者錯(cuò)誤的價(jià)格信息后果比不回答還嚴(yán)重。騰訊這套方案的核心思路是用RAG來解決這個(gè)矛盾。RAG的全稱是Retrieval-Augmented Generation翻譯過來就是“檢索增強(qiáng)生成”。它的邏輯是用戶提問后系統(tǒng)先去知識(shí)庫里檢索出最相關(guān)的幾段內(nèi)容把這些內(nèi)容作為“參考資料”塞給大模型讓模型基于這些資料來生成回答。這樣既保留了大模型的語言組織能力又把回答的內(nèi)容邊界限制在了企業(yè)提供的知識(shí)范圍內(nèi)。2.2 向量數(shù)據(jù)庫在鏈路中扮演什么角色向量數(shù)據(jù)庫是整個(gè)RAG鏈路里的“檢索器”。傳統(tǒng)的關(guān)鍵詞搜索是靠字面匹配你搜“保修期”它只能找到包含“保修期”這三個(gè)字的文檔。但用戶實(shí)際提問可能是“這個(gè)東西壞了能免費(fèi)修多久”字面上和“保修期”沒有任何重疊。向量數(shù)據(jù)庫解決的就是這個(gè)問題它把文本通過嵌入模型轉(zhuǎn)換成高維向量語義相近的文本在向量空間里的距離就近檢索時(shí)按距離排序就能找到語義相關(guān)的內(nèi)容而不依賴字面匹配。騰訊的大模型知識(shí)引擎底層支持多種向量數(shù)據(jù)庫接入包括騰訊自研的、也兼容開源的Milvus等。Milvus是目前社區(qū)里用得比較多的開源向量數(shù)據(jù)庫支持十億級向量的檢索延遲控制在毫秒級對于大多數(shù)企業(yè)知識(shí)庫場景來說性能是綽綽有余的。選型的時(shí)候主要看幾個(gè)維度數(shù)據(jù)量級、查詢并發(fā)、是否需要分布式部署、以及和現(xiàn)有技術(shù)棧的兼容性。2.3 混元大模型在其中的定位混元大模型在這套架構(gòu)里承擔(dān)的是“最終生成”的角色。檢索模塊把相關(guān)的知識(shí)片段找出來之后這些片段加上用戶的原始問題一起組成一個(gè)Prompt送給混元混元負(fù)責(zé)把碎片化的知識(shí)組織成一段通順、準(zhǔn)確、符合企業(yè)話術(shù)規(guī)范的回復(fù)。這里有個(gè)關(guān)鍵點(diǎn)混元的輸出質(zhì)量很大程度上取決于檢索模塊給它的“參考資料”質(zhì)量。如果檢索出來的內(nèi)容不相關(guān)或者不完整再強(qiáng)的模型也生成不出正確答案。所以整個(gè)鏈路的優(yōu)化重點(diǎn)其實(shí)在檢索側(cè)而不在生成側(cè)。3. 知識(shí)入庫與向量化從原始文檔到可檢索的知識(shí)庫3.1 文檔預(yù)處理切分粒度直接決定召回質(zhì)量知識(shí)入庫的第一步是把企業(yè)的原始文檔PDF、Word、網(wǎng)頁、FAQ表格等轉(zhuǎn)換成純文本然后進(jìn)行切分。切分這一步看似簡單實(shí)際上對最終效果影響極大。切得太粗一個(gè)片段里混了好幾個(gè)主題檢索時(shí)噪音大切得太細(xì)一個(gè)完整的答案被拆成好幾段模型拿到的是殘缺信息。我的經(jīng)驗(yàn)是對于FAQ類內(nèi)容一條問答作為一個(gè)切分單元不要拆。對于產(chǎn)品手冊這類長文檔按段落切分每段控制在200到500字之間。如果一段超過500字優(yōu)先找自然的分段點(diǎn)比如標(biāo)題、換行、句號來切不要硬切。騰訊的知識(shí)引擎支持自定義切分規(guī)則你可以配置按標(biāo)題層級切、按固定長度切、或者按語義相似度切。語義切分的效果通常最好但計(jì)算成本也最高適合知識(shí)量不大但精度要求高的場景。注意切分后的每個(gè)片段最好保留其來源文檔的元信息如文檔標(biāo)題、章節(jié)名、頁碼這樣在檢索召回后可以把元信息一起送給大模型幫助模型理解上下文。3.2 向量化模型的選擇與調(diào)用切分完成后每個(gè)文本片段需要通過嵌入模型轉(zhuǎn)換成向量。騰訊知識(shí)引擎默認(rèn)使用的是其自研的嵌入模型也支持接入第三方嵌入模型。嵌入模型的選擇主要看兩個(gè)指標(biāo)一是語義表征能力也就是它能不能準(zhǔn)確地把語義相近的文本映射到相近的向量位置二是維度維度越高表征能力越強(qiáng)但存儲(chǔ)和計(jì)算成本也越高。目前主流的嵌入模型維度在768到1536之間。騰訊默認(rèn)的嵌入模型維度是1024在效果和成本之間取得了比較好的平衡。如果你有自己的嵌入模型也可以通過API接入但要注意嵌入模型一旦確定后續(xù)所有入庫和查詢都必須用同一個(gè)模型否則向量空間不一致檢索結(jié)果會(huì)完全亂掉。3.3 向量數(shù)據(jù)庫的寫入與索引構(gòu)建向量寫入Milvus或者騰訊自研向量庫之后需要構(gòu)建索引來加速檢索。Milvus支持的索引類型有好幾種常用的有IVF_FLAT、IVF_SQ8、HNSW等。簡單說一下選型邏輯索引類型適用場景召回率檢索速度內(nèi)存占用IVF_FLAT數(shù)據(jù)量中等追求高召回高中等高IVF_SQ8數(shù)據(jù)量大內(nèi)存有限中高快低HNSW數(shù)據(jù)量中等追求低延遲高很快高IVF_PQ數(shù)據(jù)量極大可接受一定精度損失中很快很低對于大多數(shù)企業(yè)知識(shí)庫場景數(shù)據(jù)量在百萬級以下我一般推薦用HNSW檢索延遲可以控制在10毫秒以內(nèi)召回率也很理想。如果數(shù)據(jù)量到了千萬級考慮IVF_SQ8來平衡內(nèi)存和速度。4. 檢索與生成RAG鏈路的核心調(diào)優(yōu)環(huán)節(jié)4.1 檢索策略Top-K怎么定閾值怎么設(shè)用戶提問后系統(tǒng)會(huì)把問題也轉(zhuǎn)成向量然后在向量數(shù)據(jù)庫里做相似度搜索返回最相似的K個(gè)片段。這個(gè)K值的選擇很關(guān)鍵K太小可能漏掉關(guān)鍵信息K太大會(huì)引入無關(guān)內(nèi)容干擾模型判斷。我的經(jīng)驗(yàn)值是K3到5之間具體取決于知識(shí)庫的密度。如果知識(shí)庫內(nèi)容比較稀疏同一個(gè)問題相關(guān)的片段可能分散在多個(gè)文檔里K可以適當(dāng)放大到8到10。除了K值還要設(shè)一個(gè)相似度閾值。低于閾值的片段即使被召回了也不應(yīng)該送給模型因?yàn)槟腔臼窃胍?。閾值一般設(shè)在0.7到0.8之間余弦相似度具體值需要根據(jù)你的嵌入模型和實(shí)際測試來調(diào)。騰訊知識(shí)引擎的控制臺(tái)里可以實(shí)時(shí)看到每次查詢的召回片段和相似度分?jǐn)?shù)調(diào)優(yōu)的時(shí)候盯著這個(gè)面板調(diào)就行。4.2 Prompt工程怎么讓混元“照著資料說”檢索出來的片段需要和用戶問題一起組裝成Prompt送給混元。Prompt的設(shè)計(jì)直接決定了模型會(huì)不會(huì)“跑偏”。一個(gè)經(jīng)過驗(yàn)證的Prompt模板大概長這樣你是一個(gè)企業(yè)客服助手請根據(jù)以下參考資料回答用戶問題。 如果參考資料中沒有相關(guān)信息請直接說“抱歉我暫時(shí)沒有找到相關(guān)信息”不要編造答案。 參考資料 {retrieved_context} 用戶問題{user_query} 請用簡潔、準(zhǔn)確的語言回答這個(gè)模板里有幾個(gè)關(guān)鍵設(shè)計(jì)第一明確角色定位讓模型知道自己是客服助手而不是通用聊天機(jī)器人第二明確知識(shí)邊界告訴模型只能基于參考資料回答第三給出兜底話術(shù)避免模型在找不到答案時(shí)胡編。實(shí)測下來這三條約束能擋掉90%以上的幻覺問題。4.3 多輪對話中的上下文管理數(shù)字人場景下用戶往往會(huì)追問。比如先問“你們的旗艦款手機(jī)保修多久”得到回答后再問“那電池呢”。這時(shí)候如果只把第二個(gè)問題單獨(dú)拿去檢索很可能召回的是通用電池保修政策而不是旗艦款的。解決辦法是在檢索前先做一輪“查詢改寫”把多輪對話的上下文合并成一個(gè)完整的查詢語句再去做向量檢索。騰訊知識(shí)引擎支持開啟多輪對話改寫功能底層也是用混元來做查詢改寫。開啟后系統(tǒng)會(huì)自動(dòng)把“那電池呢”改寫成“旗艦款手機(jī)的電池保修多久”檢索準(zhǔn)確率會(huì)有明顯提升。這個(gè)功能在實(shí)際項(xiàng)目里是必開的不開的話多輪對話的體驗(yàn)會(huì)差很多。5. 數(shù)字人前端對接從文本回復(fù)到“人”的表達(dá)5.1 數(shù)字人驅(qū)動(dòng)接口的調(diào)用方式知識(shí)引擎生成文本回復(fù)后需要把文本送給數(shù)字人驅(qū)動(dòng)模塊讓它用對應(yīng)的口型、表情、動(dòng)作把內(nèi)容“說”出來。騰訊數(shù)字人提供了標(biāo)準(zhǔn)的API接口你只需要把文本傳進(jìn)去指定數(shù)字人形象和音色它就會(huì)返回一段帶口型同步的視頻流或者直接推流到前端。對接的時(shí)候有幾個(gè)參數(shù)需要關(guān)注語速、音調(diào)、停頓。語速太快會(huì)顯得機(jī)械太慢又會(huì)讓用戶等得不耐煩。我的經(jīng)驗(yàn)是中文場景下語速設(shè)在每分鐘220到260字之間比較自然。停頓方面句號后停300毫秒逗號后停150毫秒段落之間停500毫秒這樣聽起來最接近真人說話的節(jié)奏。5.2 流式輸出與首字延遲的優(yōu)化用戶最直觀的體驗(yàn)指標(biāo)是“從問完到數(shù)字人開口”的延遲。如果這個(gè)延遲超過2秒用戶就會(huì)覺得卡頓。優(yōu)化這個(gè)指標(biāo)的關(guān)鍵在于流式輸出不要讓大模型把整段話生成完再送給數(shù)字人而是生成一個(gè)句子就送一個(gè)句子數(shù)字人收到第一個(gè)句子就開始播報(bào)后面的句子邊生成邊播報(bào)。騰訊知識(shí)引擎支持流式返回混元生成第一個(gè)Token的延遲通常在300到500毫秒之間加上檢索和網(wǎng)絡(luò)傳輸整體首字延遲可以控制在1秒以內(nèi)。這個(gè)體驗(yàn)已經(jīng)非常接近真人對話的節(jié)奏了。5.3 多模態(tài)知識(shí)的呈現(xiàn)有些知識(shí)用純文本表達(dá)效率很低比如產(chǎn)品外觀、操作步驟、數(shù)據(jù)圖表。騰訊數(shù)字人支持在播報(bào)的同時(shí)展示圖片、視頻、PPT等輔助材料。實(shí)現(xiàn)方式是在知識(shí)庫的元信息里標(biāo)注該片段關(guān)聯(lián)的多媒體資源ID檢索命中后系統(tǒng)除了返回文本還會(huì)返回資源ID前端根據(jù)資源ID去加載對應(yīng)的圖片或視頻在數(shù)字人旁邊的區(qū)域展示。這個(gè)功能在培訓(xùn)場景下特別有用。比如新員工問“這個(gè)設(shè)備的開關(guān)在哪里”數(shù)字人一邊說“在設(shè)備背面右下角”一邊在旁邊展示一張標(biāo)注了開關(guān)位置的圖片理解成本瞬間降低。6. 常見問題與排查技巧實(shí)錄6.1 檢索召回不準(zhǔn)的排查思路召回不準(zhǔn)是最常見的問題表現(xiàn)是數(shù)字人回答的內(nèi)容和用戶問題對不上。排查的時(shí)候按這個(gè)順序來先看切分是否合理有沒有把一個(gè)完整的答案切成了兩半再看嵌入模型是否適合你的領(lǐng)域通用嵌入模型在垂直領(lǐng)域如醫(yī)療、法律、金融的表現(xiàn)可能不夠好需要考慮微調(diào)或者換用領(lǐng)域?qū)Ｓ媚Ｐ妥詈罂聪嗨贫乳撝凳欠裨O(shè)得過高或過低過高會(huì)漏召回過低會(huì)引入噪音。我遇到過一個(gè)典型案例客戶的知識(shí)庫里有一份產(chǎn)品對比表切分的時(shí)候按固定長度切結(jié)果每個(gè)片段里都混了好幾個(gè)產(chǎn)品的信息。用戶問“A產(chǎn)品和B產(chǎn)品的區(qū)別”檢索出來的片段里既有A也有B還有C模型生成的時(shí)候就被干擾了。后來改成按表格行切分每個(gè)片段只包含一個(gè)產(chǎn)品的信息召回準(zhǔn)確率立刻上去了。6.2 模型回答“太啰嗦”或“太簡短”怎么調(diào)混元的輸出長度可以通過Prompt來控制。如果覺得回答太啰嗦在Prompt里加一句“請用不超過三句話回答”如果覺得太簡短加一句“請?jiān)敿?xì)說明包括具體步驟和注意事項(xiàng)”。另外知識(shí)引擎的控制臺(tái)里也可以設(shè)置最大輸出Token數(shù)硬性限制長度。不過要注意限制長度不能太死。有些問題確實(shí)需要詳細(xì)回答硬壓到三句話反而說不清楚。我的做法是在Prompt里給一個(gè)長度范圍比如“請用50到150字回答”讓模型在這個(gè)范圍內(nèi)自行判斷。6.3 數(shù)字人口型與語音不同步的處理口型不同步通常是因?yàn)槲谋竞鸵纛l的時(shí)間對齊沒做好。排查的時(shí)候先確認(rèn)音頻采樣率和視頻幀率是否匹配騰訊數(shù)字人默認(rèn)要求音頻16kHz采樣、視頻25幀每秒。如果音頻是其他采樣率需要先轉(zhuǎn)碼再送入驅(qū)動(dòng)模塊。另外如果文本里包含英文單詞或數(shù)字中文音色引擎的發(fā)音時(shí)長可能和口型動(dòng)畫的時(shí)長對不上需要在文本預(yù)處理階段把英文和數(shù)字轉(zhuǎn)成中文讀法比如“iPhone 15”轉(zhuǎn)成“蘋果十五”。6.4 知識(shí)更新后檢索結(jié)果沒變化知識(shí)更新后需要重新走一遍“切分-向量化-寫入”的流程并且要確保新向量寫入后索引被刷新。Milvus在數(shù)據(jù)寫入后需要手動(dòng)觸發(fā)索引重建或者等待自動(dòng)刷新如果用的是騰訊自研向量庫控制臺(tái)里有一個(gè)“重建索引”的按鈕點(diǎn)一下就行。另外如果開了緩存更新后要清一下緩存否則查詢還是走舊數(shù)據(jù)。問題現(xiàn)象可能原因排查動(dòng)作回答與問題無關(guān)切分粒度過粗或過細(xì)檢查切分規(guī)則調(diào)整片段長度回答內(nèi)容不完整Top-K太小或閾值太高增大K值降低相似度閾值模型編造答案Prompt未限制知識(shí)邊界檢查Prompt模板加入兜底話術(shù)多輪對話答非所問未開啟查詢改寫開啟多輪對話改寫功能首字延遲高未開啟流式輸出檢查流式配置確認(rèn)逐句推送口型不同步音頻格式不匹配轉(zhuǎn)碼為16kHz采樣率7. 一些實(shí)操中的個(gè)人體會(huì)這套方案我從早期版本一直跟到現(xiàn)在的成熟版本最大的感受是RAG系統(tǒng)的效果上限取決于檢索質(zhì)量而不是模型大小。很多人一上來就想著換更大的模型但實(shí)際調(diào)優(yōu)下來把切分策略調(diào)好、把嵌入模型換成領(lǐng)域適配的、把Top-K和閾值調(diào)到最優(yōu)效果提升比換模型明顯得多。另外數(shù)字人場景對延遲的敏感度遠(yuǎn)高于純文本問答。純文本場景下用戶等兩三秒還能接受但數(shù)字人場景下超過1.5秒用戶就會(huì)覺得“這個(gè)數(shù)字人反應(yīng)好慢”。所以流式輸出和首字延遲優(yōu)化是必做的功課不是錦上添花。最后說一個(gè)容易被忽略的點(diǎn)知識(shí)庫的維護(hù)成本。很多項(xiàng)目上線時(shí)效果很好但運(yùn)行三個(gè)月后效果明顯下降原因是業(yè)務(wù)知識(shí)更新了但知識(shí)庫沒同步。建議在項(xiàng)目規(guī)劃階段就把知識(shí)更新的流程和責(zé)任人定好最好能做到業(yè)務(wù)系統(tǒng)更新后自動(dòng)觸發(fā)知識(shí)庫同步否則再好的系統(tǒng)也會(huì)慢慢“變笨”。