1. 開工之前先看懂樂園客服這塊硬骨頭難在哪很多人第一次接觸“RAG系統(tǒng)”這個詞是被客戶或者老板一句話推著走的“做個智能客服吧之前的文檔和FAQ不都現(xiàn)成的嘛。”結(jié)果真開工才發(fā)現(xiàn)最難的壓根不是調(diào)大模型接口而是那些散落在官網(wǎng)、App、指引手冊里的客服知識憑什么能被機器準(zhǔn)確找到、再組織成一句人話。這篇我就用主題樂園客服這個場景帶你從零到可上線跑通一套RAG系統(tǒng)。整個過程拆成3步主線走整理知識庫、搭檢索鏈路、接大模型生成答案最后再加一輪評測守門。游客在樂園里問客服的問題表面上五花八門實際高度重復(fù)。哪天開門、哪個項目檢修、嬰兒車在哪租、能不能帶自拍桿這類問題占了日常咨詢的很大比例。關(guān)鍵詞搜索不是不能做但游客的表達(dá)方式太隨意了。官方文檔寫的是“禁止攜帶三腳架”游客問的是“我的相機支架讓不讓帶”文檔寫“煙花秀視天氣情況調(diào)整”游客問的是“今晚燈光秀還放嗎”。這種說法和文檔寫法對不上的情況傳統(tǒng)檢索基本毫無辦法這也是RAG系統(tǒng)能落地生根的原因。1.1 高頻問題很多但每個答案都藏在長篇文檔后面主題樂園的客服知識有個天然特點答案確實存在但分布得零七八碎。票務(wù)規(guī)則在購票頁寄存指引在游客須知里失物招領(lǐng)在服務(wù)頁交通信息在企業(yè)官網(wǎng)的公告區(qū)。你要是讓客服慢慢查當(dāng)然查得到但高峰期一小時幾十個咨詢?nèi)斯じ卷敳蛔?。做RAG的第一步不是寫代碼而是把這些素材當(dāng)資產(chǎn)一樣對待如果知識庫本身就臟、亂、缺后面所有環(huán)節(jié)都是給垃圾做包裝。很多人以為向量檢索和生成模型能“理解”文檔于是就把幾十個PDF直接扔進(jìn)去期待系統(tǒng)自己看明白。這是最典型的小白誤判。RAG里的“R”檢索很老實它只能在一個個文本片段里比相似度。文檔里有頁眉頁腳、表格被拆散、專有名詞不統(tǒng)一檢索質(zhì)量立刻崩盤。所以知識庫整理這一步才是真正決定整個系統(tǒng)上限的地方。我當(dāng)時給一個內(nèi)部團(tuán)隊捋需求時把客服消息記錄拉出來看了一眼發(fā)現(xiàn)大約六成問題都能靠三四十條標(biāo)準(zhǔn)答案解決。這個觀察后來成了整個項目的定心丸不需要追求“什么都能答”先把高頻問題答準(zhǔn)、答穩(wěn)體驗就已經(jīng)比純轉(zhuǎn)人工好太多。1.2 為什么直接拿大模型當(dāng)客服會一本正經(jīng)地胡說有人會問現(xiàn)在的大模型不是挺能聊的嗎直接把全部客服文檔丟給它讓它背下來再回答不就行了這個方法看起來省事實際會在三類場景上翻車。第一類是數(shù)據(jù)時效性問題。樂園的開放時間、項目檢修、防疫要求、臨時公告經(jīng)常變大模型的訓(xùn)練數(shù)據(jù)不可能實時包含這些信息。你問一個昨天剛改的入園政策模型很容易按幾個月前的舊知識答。第二類是長文檔的注意力問題。即便你把所有文檔塞進(jìn)上下文模型面對超過處理能力的內(nèi)容會不自覺忽略關(guān)鍵段落盯著某段相關(guān)性低的內(nèi)容發(fā)揮。第三類最要命就是幻覺模型覺得“大概應(yīng)該這么答”于是編出一個看似合理的寄存點或退改政策。游客按這個答案走到現(xiàn)場發(fā)現(xiàn)完全對不上客服團(tuán)隊還得擦屁股。RAG的思路恰好繞開了這三個問題。它不要求模型記住文檔而是每次有人提問時系統(tǒng)先去外部知識庫里檢索出最相關(guān)的碎片再把“問題 這些碎片”一起交給大模型讓模型只做一件事根據(jù)給定的材料組織語言。相當(dāng)于一個開卷考試資料由檢索環(huán)節(jié)提前翻好模型負(fù)責(zé)把答案念通順而不是閉卷硬背。1.3 RAG的解決思路與3步路線圖順著開卷考試這個比喻整篇文章的路線就很清晰了第一步先把考點資料準(zhǔn)備好也就是把樂園客服文檔清洗成規(guī)范的知識庫第二步給資料建索引讓系統(tǒng)能像翻目錄一樣快速找到相關(guān)段落第三步把找到的資料和游客問題拼成一段提示詞交給大模型生成最終回復(fù)。你以為到這里就結(jié)束了還差一步。上線之前必須用一批已經(jīng)知道正確答案的問題做評測否則系統(tǒng)到底行不行全靠玄學(xué)。這篇我最后會專門講評測指標(biāo)和三個我見過最多的小白翻車點。這套流程目前在企業(yè)知識問答里已經(jīng)非常成熟但絕大多數(shù)教程要么堆概念要么繞開源框架對小白特別不友好。我下面講的是盡量不下放給第三方平臺、你自己能復(fù)現(xiàn)的版本代碼量不大重點講清楚每一步背后的“為什么”。2. 第一步把散落文檔整理成RAG能吃的知識庫2.1 收資料哪些內(nèi)容值得進(jìn)知識庫開工前先盤一下手頭有什么。我做這類知識庫時習(xí)慣列一張“素材清單”把候選文檔分成三類必收、選收、不收。必收內(nèi)容通常包括營業(yè)時間、票價與購票規(guī)則、交通指南、入園安檢規(guī)定、寄存服務(wù)、失物招領(lǐng)流程、常見游客問答。這些都是游客問得最多、答案相對固定的內(nèi)容。選收內(nèi)容包括項目游玩介紹、餐飲購物導(dǎo)覽、會員權(quán)益說明、無障礙服務(wù)信息。這類內(nèi)容有助于提升體驗但不適合一開始鋪太廣。不收的內(nèi)容包括內(nèi)部排班表、供應(yīng)商合同、員工操作手冊、臨時會議記錄。這些要么涉密要么對游客沒有任何意義。有個容易被忽略的點客服聊天記錄里的高頻問題是最有價值但沒有被整理成文檔的內(nèi)容。你可以讓客服團(tuán)隊把近一兩個月的咨詢記錄導(dǎo)出來按問題類型做一次聚類你會發(fā)現(xiàn)很多文檔里根本沒單獨寫出來的問題。比如“園區(qū)里有充電寶嗎”“衛(wèi)生間在哪”“下雨天項目還開嗎”這類問題答案往往能寫成FAQ標(biāo)準(zhǔn)對。2.2 清洗文檔要順手解決的4類臟數(shù)據(jù)所謂清洗不是把文檔換個格式而是把機器讀起來會困惑的東西處理干凈。我在項目里總結(jié)過四類最常見的臟數(shù)據(jù)。第一類是頁面噪音。網(wǎng)頁導(dǎo)出的文本經(jīng)常帶導(dǎo)航欄、頁腳、版權(quán)聲明、推薦閱讀鏈接。這些東西和答案無關(guān)嵌在段落中間只會污染向量表示。要么人工刪要么用簡單的正則規(guī)則過濾。第二類是表格結(jié)構(gòu)丟失。官方文檔里經(jīng)常有表格比如“不同票種對應(yīng)可攜帶物品”或者“各區(qū)域開放時間”。PDF或網(wǎng)頁轉(zhuǎn)純文本后表格會變成一行行散亂字符串完全失去行列關(guān)系。這種內(nèi)容我建議直接人工重寫為自然語言比如“普通門票可攜帶已封裝食品入園但不包括需加熱、冷藏或具有刺激性氣味的食品”而不是保留純文本格式。第三類是專有名詞不統(tǒng)一。同一個東西不同頁面可能叫“快速通行卡”“速通卡”“FP卡”。我要求知識庫統(tǒng)一口徑同時把其他說法寫進(jìn)關(guān)鍵詞字段方便檢索時命中。第四類是版本混亂。樂園政策經(jīng)常調(diào)整庫里不能同時存在“每天允許攜帶兩個充電寶”和“每天允許攜帶一個充電寶”這種自相矛盾的舊文。清洗時要給每個文檔標(biāo)記生效時間和來源沖突時以最新版本為準(zhǔn)。提示清洗階段投入的每一分鐘都會在后續(xù)評測階段幫你省回十分鐘。垃圾進(jìn)垃圾出在RAG系統(tǒng)里表現(xiàn)尤其明顯。2.3 用“問答對 原文片段”雙軌組織內(nèi)容清洗完之后知識庫內(nèi)容怎么組織我建議走“雙軌制”。第一軌是原文片段也就是政策原文、公告正文、須知條款里拆出來的段落。原文片段的好處是保留細(xì)節(jié)和權(quán)威性適合回答那些沒被FAQ覆蓋到的邊緣問題。第二軌是問答對也就是人工整理的“游客問法 標(biāo)準(zhǔn)回答”。問答對的價值在于它直接把“游客會怎么問”和“標(biāo)準(zhǔn)答案是什么”綁定在一起檢索時往往一擊即中。舉個例子原文里有一句“輪椅與嬰兒車可在正門游客服務(wù)中心租借需繳納押金”。我們可以順手整理出幾條問答對問嬰兒車能租嗎答可以在正門游客服務(wù)中心租借需繳納押金具體以現(xiàn)場辦理為準(zhǔn)。問輪椅在哪租答正門游客服務(wù)中心可租借輪椅需繳納押金?？雌饋砗唵蔚@兩條問答對會極大地降低檢索難度。因為游客問法和文檔寫法的相似度天然比“游客問法 vs 原文文檔”要高。不需要模型多聰明余弦相似度都容易命中。有不少團(tuán)隊圖省事只做原文拆塊覺得FAQ太多維護(hù)麻煩。我的建議是用原文片段覆蓋長尾用問答對覆蓋高頻兩者并用。初始階段問答對可以做三五十條之后根據(jù)客服后臺的“未命中問題”持續(xù)補充這相當(dāng)于給系統(tǒng)喂真實需求。2.4 一份可以直接照抄的知識庫字段模板知識庫本質(zhì)上可以做成一個簡單的表格每一行是一個可以獨立檢索的文本單元。我給常用字段列一個模板。表知識庫字段模板字段名類型示例用途id字符串KB_001234全局唯一標(biāo)識doc_type字符串faq / passage / notice區(qū)分問答對和原文片段title字符串嬰兒車租借規(guī)定用于展示和引用content文本正門游客服務(wù)中心提供嬰兒車租借……最終被檢索和喂給大模型的正文keywords字符串列表嬰兒車, 租借, 押金, stroller輔助關(guān)鍵詞檢索source_url字符串http://xxx/help引用來源region字符串樂園正門 / 全園 / 某主題區(qū)元數(shù)據(jù)過濾條件language字符串zh-CN多語言場景留用updated_at日期時間2025-01-10版本管理status字符串a(chǎn)ctive / archived下線舊政策你不需要一開始把所有字段全部填滿但id、content、metadata、updated_at這幾個強烈建議保留。metadata可以做得靈活一點比如你的業(yè)務(wù)里可能需要區(qū)分“門票”“餐飲”“交通”等分類那就再加一列category。檢索時可以通過metadata做過濾比如游客明確問“停車”就只檢索交通分類下的內(nèi)容減少無關(guān)干擾。3. 第二步分塊、嵌入與檢索搭出一條能命中答案的鏈路3.1 分塊策略切得太碎太整都不行知識庫內(nèi)容準(zhǔn)備好之后就要面對分塊Chunking問題。分塊的意思是把長篇文檔切成一個個適合做檢索的片段。分塊大小直接決定檢索質(zhì)量但并沒有一個萬能參數(shù)更多是經(jīng)驗和調(diào)試的結(jié)果。分塊太碎比如切成一兩句話問題在于上下文信息丟失。比如“輪椅可在正門游客服務(wù)中心租借”和“需繳納押金和證件”被切成兩塊檢索到第一塊時答案就不完整。分塊太長比如整篇3000字的政策說明塞成一個塊問題在于相似度打分被稀釋游客問的是寄存塊里前半段講入口規(guī)定、后半段講收費最終相關(guān)性被無關(guān)文字拉低而且喂給大模型后回答容易夾帶多余信息。我在這類中文客服場景里習(xí)慣按“自然段落合并”而不是單純按字?jǐn)?shù)切。做法是先把文檔按標(biāo)題層級拆成若干小節(jié)再把每個小節(jié)里過短的段落合并控制每個塊在150到300字之間。如果相鄰塊之間話題有明顯延續(xù)就保留20到40字的重疊避免關(guān)鍵句子剛好被切斷。分塊完成之后每個塊就對應(yīng)知識庫表格里的一個content字段。后面的索引、檢索、生成全部基于這些塊進(jìn)行。3.2 嵌入模型把文本變成空間里的坐標(biāo)嵌入模型Embedding Model解決的是“語義匹配”問題。它能把一段文字轉(zhuǎn)換成一個高維向量比如幾百維甚至上千維的浮點數(shù)數(shù)組。轉(zhuǎn)換的規(guī)則是語義相近的句子在向量空間里距離更近語義無關(guān)的句子距離更遠(yuǎn)。買票相關(guān)表達(dá)的向量會聚在一起寄存相關(guān)的向量會聚在另一片區(qū)域。游客輸入“嬰兒車可以推進(jìn)園區(qū)嗎”即使知識庫里沒有這句話只有“游客可攜帶嬰兒車入園但不得在項目排隊區(qū)域使用”兩者的向量距離依然很近檢索系統(tǒng)就能把它找出來。對小白來說選嵌入模型不用太糾結(jié)。中文場景下直接選一個在中文語料上表現(xiàn)好的開源嵌入模型即可很多模型支持像“你可以通過模型庫下載到本地”這種方式使用。盡量避免把英文語料訓(xùn)練的模型直接拿來跑中文客服效果通常差不少。注意嵌入模型不是越新越強就一定要換。每次更換嵌入模型意味著庫里所有向量都要重算成本不小。判斷要不要換看評測集上的檢索命中率是否顯著提升別跟風(fēng)。3.3 向量檢索演示50行Python跑通核心鏈路如果你只是想理解原理不用一上來就上重型向量數(shù)據(jù)庫本地用Python列表加余弦相似度就能跑通一個最小演示。下面這段代碼會把知識庫分塊、轉(zhuǎn)換成向量然后對用戶問題檢索出最相關(guān)的Top-K片段。生產(chǎn)環(huán)境可以把這里的“本地向量列表”換成任意主流向量檢索服務(wù)邏輯完全一致。import numpy as np # 這里用占位函數(shù)表示調(diào)用嵌入模型把文本轉(zhuǎn)換成一維向量 def embed_text(text: str) - np.ndarray: # 在實際項目中這里會調(diào)用某個嵌入模型服務(wù) # 返回類似 np.random.rand(768) 這樣的向量。 # 注意不要用隨機向量這里只是演示函數(shù)簽名。 raise NotImplementedError(請?zhí)鎿Q為真實的嵌入模型調(diào)用) # 假設(shè)知識庫里已經(jīng)有多個分塊文本 chunks [ 正門游客服務(wù)中心提供嬰兒車租借需繳納押金和有效證件。, 游客可在規(guī)定區(qū)域攜帶已封裝食品入園禁止攜帶需加熱或冷藏的物品。, 停車場位于樂園南側(cè)收費標(biāo)準(zhǔn)為每天50元。, # ... 更多分塊 ] # 離線階段為每個分塊生成向量 vectors np.array([embed_text(chunk) for chunk in chunks]) def cos_similarity(a: np.ndarray, b: np.ndarray) - float: return float(np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))) def retrieve(query: str, top_k: int 3): q_vec embed_text(query) # 計算查詢向量與所有分塊向量的余弦相似度 scores [cos_similarity(q_vec, v) for v in vectors] # 按相似度從高到低排序取前 top_k 個 ranked_idx sorted(range(len(scores)), keylambda i: scores[i], reverseTrue)[:top_k] return [(chunks[i], scores[i]) for i in ranked_idx] # 測試檢索 for chunk, score in retrieve(嬰兒車在哪可以租): print(f相似度: {score:.4f} - {chunk})這段代碼的核心邏輯只有三步文本轉(zhuǎn)成向量、算余弦相似度、排序取前K。理解了這三步你就理解了所有向量檢索產(chǎn)品的基礎(chǔ)原理。后面要升級的時候也無非是把“本地數(shù)組”換成分布式索引把“余弦相似度”換成更適合語義匹配的距離度量。3.4 混合檢索向量 關(guān)鍵詞兩條腿走路更穩(wěn)純向量檢索在客服場景下有一個常見尷尬當(dāng)游客問題里包含明確的專有名詞或編號時向量匹配容易被無關(guān)但語義相似的長文本帶偏。比如游客問“L1停車場怎么收費”知識庫里“L1層是室內(nèi)停車場入口在商業(yè)街東側(cè)”這段話雖然包含L1但向量可能把它排到很后面反而是一段講解“停車場收費標(biāo)準(zhǔn)”的文字更靠前。這種問題在客服實操里很常見所以要上混合檢索一條腿是向量語義檢索負(fù)責(zé)捕捉“換個說法”的問法另一條腿是關(guān)鍵詞檢索比如BM25或簡單的詞頻加權(quán)負(fù)責(zé)精確命中產(chǎn)品名、地名、門票種類、數(shù)字編號。兩條路各自召回一批結(jié)果再合并去重分?jǐn)?shù)做歸一化后相加。實際工程里我不建議初始階段就做太復(fù)雜的權(quán)重調(diào)節(jié)。先用一個簡單公式比如最終得分 0.7 × 向量相似度 0.3 × 關(guān)鍵詞得分跑一遍黃金測試集再根據(jù)試錯調(diào)整權(quán)重。關(guān)鍵詞命中往往比向量更準(zhǔn)權(quán)重低一點也能有效糾偏?；旌蠙z索的代碼也不復(fù)雜關(guān)鍵詞部分可以用倒排索引或現(xiàn)成關(guān)鍵詞工具向量部分繼續(xù)沿用上一步的接口。這個組合是目前客服場景下性價比最高的檢索方案能覆蓋大多數(shù)“換個說法”和“精確詞命中”并存的情況。4. 第三步把檢索結(jié)果包裝成大模型能照著回答的素材4.1 提示詞模板沒有好的上下文再強的大模型也白搭檢索鏈路把Top-K片段拿回來之后下一步就是拼提示詞喂給大模型。提示詞模板看起來簡單實際上有很多坑。好的模板要讓大模型知道三件事自己是誰、手頭有什么資料、回答時該遵守什么紀(jì)律。下面是一個我常用的提示詞模板骨架你是某主題樂園的游客服務(wù)中心客服助手。 請只根據(jù)下面提供的“參考資料”回答游客的問題不要使用你自身的背景知識進(jìn)行補充。 如果參考資料中沒有足夠信息請直接說“抱歉我暫時沒有查詢到相關(guān)信息建議轉(zhuǎn)人工客服處理”。 回答請用簡體中文語氣友好但簡潔不要編造價格、時間或地點。 在回答末尾注明你參考的資料編號例如[1][2]。 參考資料 [1] {chunk_text_1} [2] {chunk_text_2} [3] {chunk_text_3} 游客問題{query}為什么要寫得這么死因為大模型默認(rèn)是“知識淵博”的你不加限制它會把自己訓(xùn)練時見過的其他樂園回答混進(jìn)來甚至腦補出“迪士尼有XX項目”之類的內(nèi)容。把回答范圍鎖死在參考資料里是抑制幻覺的最后一道閘門。哪怕參考資料表述不完整讓模型說不知道也比編一個答案好。4.2 重排序把召回量從50壓到3很多人會覺得檢索回來Top-K直接喂給大模型不就行了我建議中間再加一步重排序。為什么因為向量檢索第一次召回目的是“別漏掉”通常會召回幾十條。假設(shè)召回50條里面可能只有兩三條真正命中其余都是泛泛相關(guān)。如果全塞給大模型一方面浪費Token另一方面無關(guān)內(nèi)容會干擾模型判斷。重排序的思路是先用便宜的向量檢索快速篩出候選集比如50條再用一個更精細(xì)的重排序模型Reranker逐條打分把候選壓到3條左右。重排序模型本質(zhì)上是一個更強、更慢的匹配模型它把“問題 片段”拼接起來做深度交互能捕捉到向量相似度忽略的細(xì)微語義關(guān)系。這個環(huán)節(jié)在客服場景里非常值錢。我見過不少項目加了重排序之后答案準(zhǔn)確率從60%左右直接提到85%以上。推薦的做法是把重排序做成獨立步驟而不是調(diào)大向量Top-K完事。工程上具體怎么接簡單說就是向量檢索得出50條候選重排序模型給每條算一個相關(guān)性分取最高的3條進(jìn)入提示詞模板。4.3 生成鏈路調(diào)用大模型接口并保留引用來源生成這一步代碼骨架大概長這樣query 嬰兒車在哪可以租 # 1. 混合檢索召回候選 candidates hybrid_search(query, top_k50) # 2. 重排序精篩 reranked rerank(query, candidates, top_k3) # 3. 組裝提示詞 context_blocks [f[{i1}] {c.content} for i, c in enumerate(reranked)] user_prompt f 你是某主題樂園的游客服務(wù)中心客服助手。 請只根據(jù)下面提供的“參考資料”回答游客的問題不要使用自身背景知識補充。 如果參考資料中沒有足夠信息請直接說“抱歉我暫時沒有查詢到相關(guān)信息建議轉(zhuǎn)人工客服處理”。 回答請用簡體中文語氣友好但簡潔不要編造價格、時間或地點。 在回答末尾注明你參考的資料編號例如[1][2]。 參考資料 {chr(10).join(context_blocks)} 游客問題{query} # 4. 調(diào)用大模型接口這里省略具體平臺參數(shù) answer call_llm(user_prompt, max_tokens300) # 5. 輸出給用戶 print(answer)注意我特意在提示詞里要求模型標(biāo)注參考編號這樣游客和客服都能溯源。有的項目還會在前端做“查看參考來源”的入口點擊后展示原文片段和頁面鏈接信任感會強很多。調(diào)用大模型時還有兩個工程細(xì)節(jié)容易踩坑。第一是Token限制參考資料和回答加起來要在模型上下文窗口內(nèi)建議給max_tokens設(shè)置一個上限避免模型長篇大論第二是超時和重試客服場景需要快速響應(yīng)一般設(shè)置一次生成不超3秒如果失敗就返回兜底話術(shù)而不是讓游客干等。4.4 兜底設(shè)計讓系統(tǒng)學(xué)會說“不知道”越是追求“答得全”越要把“不知道”的路徑設(shè)計好?？头鼍爸谢卮疱e誤比回答不了更傷體驗。游客要是沒得到答案最多轉(zhuǎn)人工要是得到一個錯誤的寄存位置可能白跑一趟。兜底判斷可以在兩個環(huán)節(jié)做。一個是在重排序之后如果Top-1的相關(guān)性分低于某個閾值說明檢索結(jié)果本身不可靠直接進(jìn)入兜底話術(shù)。另一個是在大模型輸出后如果模型自己也明確表示“信息不足”同樣走兜底。強行走生成模型往往會把問題硬答出來這就是幻覺重災(zāi)區(qū)。兜底話術(shù)我建議主動給解決方案而不是冷冰冰一句“不知道”。比如“抱歉我暫時沒有查詢到嬰兒車租借的準(zhǔn)確信息。你可以通過官網(wǎng)幫助中心搜索‘嬰兒車’或者撥打游客服務(wù)中心電話咨詢?！边@樣既守住了事實底線又給游客留了下一步動作。提示閾值怎么定用黃金測試集做實驗先統(tǒng)計所有正確樣本的重排序得分選一個能覆蓋90%正確樣本的最低分作為兜底閾值。閾值太高會讓系統(tǒng)動不動就裝死閾值太低又會放行太多錯誤答案。5. 上線之前評測、回歸與小白的3個高頻坑5.1 用“黃金問答集”做回歸別等上線才測RAG系統(tǒng)最怕的就是“感覺還行一上線全跑偏”。所以必須在開發(fā)階段就準(zhǔn)備一套黃金問答集也就是一批已經(jīng)知道標(biāo)準(zhǔn)答案的測試數(shù)據(jù)。數(shù)量不用太多起步50到100條就能發(fā)現(xiàn)大部分問題但質(zhì)量要高。每條測試數(shù)據(jù)建議包含幾個字段游客問題、標(biāo)準(zhǔn)答案、期望引用到的知識庫段落ID、分類門票/交通/寄存/餐飲等。評測時可以跑三個維度檢索命中率、答案準(zhǔn)確率、引用正確率。檢索命中率好理解就是看正確答案的段落有沒有出現(xiàn)在召回結(jié)果里。有一個常見的現(xiàn)象答案準(zhǔn)確但檢索沒命中標(biāo)準(zhǔn)段落說明模型可能是在憑背景知識硬答這種回答時間長了必然翻車。引用正確率同樣關(guān)鍵看模型標(biāo)注的參考編號到底是不是它真正參考的那幾條。有些模型會把引用標(biāo)得很漂亮內(nèi)容卻對不上這種引用對用戶是誤導(dǎo)。評測方式上我推薦每改一次知識庫或檢索參數(shù)就跑一遍整個黃金問答集記錄指標(biāo)變化。不是說每個版本都要人工打分可以先用規(guī)則做自動初篩比如判斷標(biāo)準(zhǔn)答案里的關(guān)鍵實體有沒有出現(xiàn)在回復(fù)中再人工抽檢。5.2 小白最容易踩的3個坑第一個坑是文檔更新不同步。運營改了政策知識庫里舊內(nèi)容沒下線新內(nèi)容又加了進(jìn)來。游客一查系統(tǒng)給的是舊規(guī)定這功勞可全砸了。解決辦法是每次更新走固定流程舊文檔標(biāo)archived、新文檔標(biāo)生效時間重新生成向量索引后再放量上線?？头F(tuán)隊要養(yǎng)成一個習(xí)慣政策變化當(dāng)天就把舊條目下線。第二個坑是低估同義改寫的威力。你以為自己把FAQ寫得很全了結(jié)果游客來一句“你們家能帶吃的嗎”“園區(qū)里可以吃飯嗎”“自熱火鍋能不能過安檢”系統(tǒng)照樣抓瞎。解決方案有兩個方向持續(xù)補充問答對把高頻問法吸收進(jìn)知識庫或者在上線后收集未命中問題每周做一次問法聚類反哺知識庫。第三個坑是上下文過長導(dǎo)致答案走樣。重排序取回3條段落聽著不多但如果每段幾百字三五千字塞進(jìn)去模型生成時難免注意力渙散。解決辦法是限制每段不超過300字必要時只取Top-2并且要求模型“先直接回答再給出依據(jù)”把結(jié)論放在前面。5.3 從Demo到最小可用服務(wù)當(dāng)你在筆記本上把鏈路跑通接下來要把它變成一個別人可以訪問的系統(tǒng)。最小可用版本通常包含三個接口POST /ask接收游客問題返回回答、引用來源、兜底標(biāo)記POST /refresh用于知識庫更新后重建向量索引GET /health做健康檢查確保服務(wù)在線。實現(xiàn)時用常見的Web框架就能搞定向量存儲可以先用本地文件或輕量級開源服務(wù)不急著上重對象。響應(yīng)時間控制在2秒內(nèi)比較理想檢索部分通常只要幾十毫秒大頭在大模型生成。如果生成太慢可以考慮縮短輸出長度、用更快的模型、或者做緩存——把重復(fù)問題的高頻答案緩存起來命中緩存就直接秒回。6. 最后分享一個我認(rèn)為最關(guān)鍵的工程習(xí)慣整套系統(tǒng)走下來你會發(fā)現(xiàn)最值錢的不是某一個大模型或某個向量組件而是一套能持續(xù)迭代的流程知識庫有人管、更新有版本、評測有數(shù)據(jù)。我自己在接觸這類客服項目時一直堅持“每次改動都跑一遍黃金問答集”的習(xí)慣哪怕只是改了一個標(biāo)點符號。聽起來笨但正是這種笨功夫讓系統(tǒng)越養(yǎng)越穩(wěn)而不是上線后成了沒人敢碰的黑盒子。如果你準(zhǔn)備動手建議先別急著追求大而全挑一個具體場景比如“嬰兒車租賃與寄存”用幾十條問答對把鏈路從頭跑到尾。等這幾十條都答得不錯了再橫向擴到全園業(yè)務(wù)。這個順序帶給我很大安全感再復(fù)雜的問題也能拆開吃透了你也可以從最簡單的地方開始。