手頭只有一份66頁(yè)的工業(yè)庫(kù)卻把它做成了一條完整的知識(shí)庫(kù)Agent主線。這件事做完以后我反而把知識(shí)庫(kù)Agent這件事想明白了——它能不能跑起來(lái)跟文檔數(shù)量多少?zèng)]有決定關(guān)系而是看你能不能把每一個(gè)知識(shí)塊都處理到位。這里說(shuō)的工業(yè)庫(kù)不是某種數(shù)據(jù)庫(kù)產(chǎn)品而是工業(yè)現(xiàn)場(chǎng)最常見(jiàn)的文檔集合設(shè)備參數(shù)手冊(cè)、標(biāo)準(zhǔn)操作規(guī)程、報(bào)警響應(yīng)預(yù)案、安全注意事項(xiàng)雜七雜八湊一起就66頁(yè)。系統(tǒng)最終能穩(wěn)定回答設(shè)備參數(shù)查詢、異常處置步驟、標(biāo)準(zhǔn)依據(jù)核對(duì)這些高頻問(wèn)題每個(gè)答案還能給出文檔頁(yè)碼出處。這篇文章就把這條主線的完整拆解過(guò)程寫(xiě)出來(lái)給想用小體量知識(shí)庫(kù)起步做Agent的人一個(gè)參照。1. 項(xiàng)目解剖66頁(yè)工業(yè)庫(kù)為何能長(zhǎng)成Agent主線1.1 這66頁(yè)工業(yè)庫(kù)到底是什么我先說(shuō)清楚這份66頁(yè)的底料長(zhǎng)什么樣因?yàn)樗途W(wǎng)上常見(jiàn)的“通用知識(shí)庫(kù)”差別很大。它不是一個(gè)單一的PDF文件而是好幾類文檔拼起來(lái)的一是核心設(shè)備的參數(shù)表和技術(shù)手冊(cè)選頁(yè)里面全是型號(hào)、額定電壓、功率、壓力范圍這類數(shù)值二是一套標(biāo)準(zhǔn)操作流程也就是工業(yè)現(xiàn)場(chǎng)常說(shuō)的SOP規(guī)定某個(gè)操作按什么順序做、每步注意什么三是報(bào)警值和異常現(xiàn)象對(duì)照表比如哪個(gè)報(bào)警代碼對(duì)應(yīng)什么故障、該怎么處置四是安全注意事項(xiàng)和應(yīng)急響應(yīng)預(yù)案。這些內(nèi)容在主題上高度強(qiáng)相關(guān)都在回答同一個(gè)車間里操作人員會(huì)遇到的日常問(wèn)題但格式完全不統(tǒng)一有橫版表格、有帶層級(jí)編號(hào)的條款、有流程圖截圖。工業(yè)庫(kù)的特點(diǎn)就是“數(shù)字化程度低但專業(yè)要求極高”大量縮寫(xiě)、中英混排、數(shù)值范圍、版本號(hào)而且知識(shí)更新的節(jié)奏說(shuō)變就變——設(shè)備一改型、標(biāo)準(zhǔn)一改版舊文檔就得下線。更關(guān)鍵的是答錯(cuò)代價(jià)不同。通用知識(shí)庫(kù)答錯(cuò)一句也就是用戶覺(jué)得不準(zhǔn)工業(yè)知識(shí)庫(kù)要是答錯(cuò)一個(gè)報(bào)警閾值操作工照著回答去處理設(shè)備后果可能是設(shè)備損壞甚至安全事故。所以這個(gè)項(xiàng)目從一開(kāi)始就定了底線每個(gè)回答必須有出處沒(méi)有出處的回答寧可不說(shuō)。這也決定了后面所有技術(shù)選型都圍繞“可溯源、可驗(yàn)證、可更新”來(lái)展開(kāi)。1.2 為什么用知識(shí)庫(kù)Agent而不是“讓大模型背下全本”有人會(huì)問(wèn)66頁(yè)內(nèi)容這么少直接把全文塞給大模型讓它回答不就行了我分別解釋一下為什么三條路都沒(méi)走。第一條路是微調(diào)。讓大模型把這66頁(yè)背下來(lái)聽(tīng)起來(lái)很誘人但工業(yè)文檔的高頻操作是“改版”今天參數(shù)表更新一頁(yè)明天SOP修訂一條每次改動(dòng)都重新微調(diào)一輪時(shí)間和算力成本都不可接受。而且微調(diào)后的模型是黑盒回答沒(méi)有出處運(yùn)維人員根本不敢拿來(lái)做操作依據(jù)。66頁(yè)的數(shù)據(jù)量對(duì)于微調(diào)來(lái)說(shuō)也遠(yuǎn)遠(yuǎn)不夠很容易學(xué)歪。第二條路是長(zhǎng)上下文直讀。把66頁(yè)文本全部塞進(jìn)上下文窗口模型確實(shí)能看到但有兩個(gè)問(wèn)題一是長(zhǎng)篇文檔中的具體數(shù)值會(huì)被上下文稀釋提問(wèn)“3號(hào)空壓機(jī)排氣壓力上限是多少”模型很可能把4號(hào)設(shè)備的數(shù)據(jù)混進(jìn)來(lái)二是沒(méi)有檢索定位能力每次回答都要重新處理全文延遲高也無(wú)法指出“依據(jù)在第34頁(yè)”。第三條路就是知識(shí)庫(kù)Agent也就是我這篇文章說(shuō)的主線。它本質(zhì)上是一個(gè)“檢索增強(qiáng)生成”的框架但比普通的單次RAG多了一層Agent能力。普通RAG是“用戶問(wèn)一句、檢索一次、生成一次”工業(yè)場(chǎng)景下的真實(shí)提問(wèn)往往一句話里藏著好幾個(gè)子問(wèn)題。比如“空壓機(jī)排氣溫度高報(bào)警到底怎么處置”這個(gè)問(wèn)題實(shí)際上需要三步先確認(rèn)空壓機(jī)型號(hào)對(duì)應(yīng)的正常溫度范圍和報(bào)警閾值再查對(duì)應(yīng)型號(hào)的處置步驟最后補(bǔ)充安全注意事項(xiàng)。單次檢索很可能只命中其中一段剩下的靠模型瞎猜。知識(shí)庫(kù)Agent做的事情就是把“一次提問(wèn)、多次檢索、按需匯總”變成一套可控流程讓問(wèn)題拆解、檢索調(diào)用、答案驗(yàn)證每個(gè)環(huán)節(jié)都透明可見(jiàn)。2. 工業(yè)文檔的知識(shí)化加工從66頁(yè)到可檢索的知識(shí)塊2.1 文檔清洗有三件事必須親自做知識(shí)庫(kù)Agent的地基是文檔本身。66頁(yè)文檔不多但這恰恰是優(yōu)勢(shì)——我有精力把每一頁(yè)都人工過(guò)一遍。清洗階段有三件事偷懶不得。第一件事是解析與轉(zhuǎn)文本。PDF用pdfplumber或PyMuPDF轉(zhuǎn)成文本橫版表格直接用文本解析很容易錯(cuò)亂需要專門的表格抽取工具。我那份文檔里有一頁(yè)是設(shè)備參數(shù)總表直接用通用解析器抽出來(lái)列和行全錯(cuò)位單位也丟了最后是用表格識(shí)別工具加人工校對(duì)才恢復(fù)原樣。工業(yè)文檔里的數(shù)字和計(jì)量單位是生命線這里出錯(cuò)后面檢索做得再好都是白搭。第二件事是清理噪音。頁(yè)眉頁(yè)腳、目錄頁(yè)碼、水印、殘留換行、制表符這些都會(huì)污染切塊結(jié)果。尤其是OCR出來(lái)的文檔錯(cuò)別字要逐頁(yè)抽查我曾經(jīng)遇到過(guò)“MPa”被識(shí)別成“M Pa”一個(gè)空格之差檢索時(shí)關(guān)鍵詞完全匹配不上。這種錯(cuò)誤靠模型自動(dòng)修是修不干凈的必須人工盯一遍關(guān)鍵數(shù)值和單位。第三件事是結(jié)構(gòu)還原。工業(yè)文檔普遍有清晰的標(biāo)題層級(jí)和編號(hào)體系比如“3.2.1 濾芯更換步驟”。要把這些層級(jí)關(guān)系提取出來(lái)構(gòu)建成“文件—章節(jié)—小節(jié)—段落”的樹(shù)狀結(jié)構(gòu)。這一步有兩層價(jià)值一是后面檢索時(shí)可以按章節(jié)做粗過(guò)濾把搜索范圍大幅縮小二是每一段文本都帶著章節(jié)路徑回答時(shí)引用位置就能寫(xiě)到“第3.2.1節(jié)”這種級(jí)別而不是籠統(tǒng)說(shuō)“某個(gè)文檔里提到了”。清洗完成之后要給每個(gè)知識(shí)塊設(shè)計(jì)元數(shù)據(jù)。我的做法是每個(gè)塊固定掛六個(gè)字段來(lái)源文件名、版本號(hào)、章節(jié)路徑、頁(yè)碼、內(nèi)容類型正文/表格/步驟、創(chuàng)建時(shí)間。這些字段決定了后續(xù)檢索過(guò)濾、版本隔離、引用格式能否落地越早定越好。等索引建完再回頭補(bǔ)元數(shù)據(jù)等于重做一遍。2.2 切塊策略三個(gè)參數(shù)如何定切塊是知識(shí)庫(kù)Agent里最容易被低估的環(huán)節(jié)。很多人以為隨便按固定字?jǐn)?shù)切就行實(shí)際上一旦切錯(cuò)后面所有環(huán)節(jié)都在錯(cuò)誤的數(shù)據(jù)上做文章效果怎么調(diào)都上不去。先解釋為什么要切塊。Embedding模型對(duì)輸入長(zhǎng)度有限制當(dāng)前常用的中文向量模型一般在8192個(gè)token以內(nèi)但即使沒(méi)超過(guò)上限太長(zhǎng)的文本經(jīng)過(guò)向量化后語(yǔ)義會(huì)被“平均”稀釋——一段512字的文本里可能包含三個(gè)不同主題向量最終呈現(xiàn)的是三個(gè)主題混在一起的模糊語(yǔ)義檢索時(shí)哪個(gè)都命不準(zhǔn)。檢索的目標(biāo)是“返回和問(wèn)題最相關(guān)的局部片段”不是“返回包含答案的整個(gè)章節(jié)”所以切塊粒度直接決定召回質(zhì)量。我用的切塊策略可以總結(jié)為“結(jié)構(gòu)優(yōu)先、定長(zhǎng)兜底”。具體分四步用文檔的標(biāo)題層級(jí)先把整份文檔切成大塊保證同一個(gè)大塊內(nèi)主題一致。大塊內(nèi)部如果超過(guò)閾值再按自然段落分割。段落仍然超長(zhǎng)時(shí)用定長(zhǎng)滑動(dòng)窗口兜底。相鄰塊之間設(shè)置一定重疊防止上下文在切縫處斷裂。三個(gè)核心參數(shù)里chunk_size和overlap是繞不開(kāi)的。中文工業(yè)文檔我建議以“字符數(shù)”而不是token數(shù)來(lái)衡量中文字符和token的比例大約是1:1.5直接按token切容易把一句話攔腰截?cái)?。我的參?shù)范圍供參考chunk_size取512到768字符overlap取64到128字符。塊太大會(huì)混入無(wú)關(guān)信息塊太小則語(yǔ)義不完整比如“禁止在未泄壓狀態(tài)下拆卸”本來(lái)是一個(gè)完整的安全警告切成“禁止在未泄壓”和“狀態(tài)下拆卸”兩塊語(yǔ)義就廢了。另一個(gè)關(guān)鍵點(diǎn)是表格的切法。工業(yè)文檔里的表格是“另一條主線”不能和普通文本混在一起切。一個(gè)表格應(yīng)該作為一個(gè)整體塊保留包括表頭、單位和備注說(shuō)明如果表格行數(shù)太多必須按行切每一行都要冗余攜帶表頭信息。這個(gè)做法反直覺(jué)但非常有用否則“22.8”這個(gè)數(shù)字脫離列名和單位之后誰(shuí)都不知道它是什么。2.3 向量索引與檢索接口選型清洗和切塊完成后下一步就是把知識(shí)塊向量化并建立索引。向量模型我選了BGE-M3中文效果好而且是開(kāi)源模型支持稠密向量和稀疏向量?jī)煞N表示后面做混合檢索時(shí)同一個(gè)模型就能輸出兩種索引省了不少事。如果環(huán)境受限、下載不了大模型退而求其次用text2vec-base-chinese也能跑起來(lái)只是準(zhǔn)確率會(huì)打些折扣。66頁(yè)文檔切出來(lái)的知識(shí)塊數(shù)量很小大概也就幾百個(gè)塊用FAISS內(nèi)存索引完全夠用連獨(dú)立的向量數(shù)據(jù)庫(kù)服務(wù)都不用部署。但我還是把檢索接口封裝成了一個(gè)獨(dú)立服務(wù)。這么做的原因很樸素項(xiàng)目起步只有66頁(yè)后面一定會(huì)擴(kuò)展到更多設(shè)備手冊(cè)如果一開(kāi)始就把索引邏輯寫(xiě)死在業(yè)務(wù)代碼里后面擴(kuò)展時(shí)就得重構(gòu)。把檢索抽象成獨(dú)立接口后續(xù)換成Milvus或者Qdrant只需要替換底層實(shí)現(xiàn)上層Agent的代碼一行都不用動(dòng)。索引建設(shè)的代碼邏輯大致是這樣的from pymupdf import open as pdf_open from bge_m3 import BGEM3EmbeddingModel doc pdf_open(industrial_lib_v2.pdf) blocks extract_structured_blocks(doc) # 返回帶元數(shù)據(jù)的知識(shí)塊列表 model BGEM3EmbeddingModel(model_nameBAAI/bge-m3) chunk_texts [b[text] for b in blocks] embeddings model.encode(chunk_texts)[dense_vecs] # 每個(gè)塊保存文本和元數(shù)據(jù) for idx, block in enumerate(blocks): block[embedding] embeddings[idx] block[id] fblock_{idx} # 寫(xiě)入FAISS索引 import faiss import numpy as np dim embeddings.shape[1] index faiss.IndexFlatIP(dim) faiss.normalize_L2(embeddings) index.add(embeddings) faiss.write_index(index, industrial_blocks.index)要強(qiáng)調(diào)的是Embedding模型選型不是一勞永逸的。換了模型后必須重建索引否則新舊向量不在同一個(gè)語(yǔ)義空間里檢索結(jié)果會(huì)變得毫無(wú)意義。踩過(guò)一次坑之后我把索引重建做成了流水線上的固定步驟每次更新Embedding版本都跑一遍全量重建。3. 檢索與生成的Agent閉環(huán)核心實(shí)現(xiàn)拆解3.1 混合檢索向量不夠BM25兜底工業(yè)庫(kù)檢索有個(gè)很實(shí)際的痛點(diǎn)純向量檢索對(duì)專有名詞和縮寫(xiě)不友好。像“SOP”“PLC”“HVAC”這種縮寫(xiě)以及“A/B-3000”這種帶特殊符號(hào)的型號(hào)Embedding模型經(jīng)常把它們當(dāng)成普通詞組導(dǎo)致語(yǔ)義相近的段落湊上來(lái)精確匹配的段落反而排到后面去。解決辦法是混合檢索。向量檢索負(fù)責(zé)捕捉語(yǔ)義相關(guān)性BM25這類稀疏檢索負(fù)責(zé)精確匹配專有名詞最后把兩路結(jié)果融合排序。融合用的算法是RRFReciprocal Rank Fusion原理不復(fù)雜每個(gè)文檔在兩路結(jié)果里都有一個(gè)排名融合分?jǐn)?shù)就是每個(gè)排名倒數(shù)之和排名越靠前貢獻(xiàn)越大。這樣語(yǔ)義和關(guān)鍵詞兩條線索都能發(fā)揮各自優(yōu)勢(shì)不會(huì)被某一方的偏差帶偏。核心邏輯長(zhǎng)這樣from rank_bm25 import BM25Okapi # 用BGE-M3的sparse_vecs同時(shí)做BM25式匹配 bm25 BM25Okapi(tokenized_chunks) def hybrid_search(query, top_k5): query_vec embedding_model.encode([query])[dense_vecs] dense_scores, dense_indices faiss_index.search(query_vec, top_k) bm25_scores bm25.get_scores(tokenize(query)) top_bm25 sorted(range(len(bm25_scores)), keylambda i: bm25_scores[i], reverseTrue)[:top_k] # RRF融合 fused {} for rank, idx in enumerate(dense_indices[0]): fused[idx] fused.get(idx, 0) 1 / (60 rank) for rank, idx in enumerate(top_bm25): fused[idx] fused.get(idx, 0) 1 / (60 rank) return sorted(fused.items(), keylambda x: x[1], reverseTrue)[:top_k]實(shí)測(cè)下來(lái)加了BM25混合檢索之后像“報(bào)警代碼E-204”聯(lián)合“處置建議”這種查詢精準(zhǔn)命中率提升非常明顯。純向量檢索經(jīng)常把“報(bào)警代碼”相關(guān)的其他段落也排上來(lái)但精確帶著“E-204”的那一段反而沉在下面。工業(yè)文檔里大量存在“型號(hào)故障”這種組合查詢BM25對(duì)這類模式就是天然的強(qiáng)項(xiàng)。3.2 Agent如何把“一個(gè)難題”拆成“幾次查詢”知識(shí)庫(kù)Agent和普通RAG最核心的區(qū)別在于它把LLM從“直接答題的人”變成了“調(diào)度問(wèn)題的人”。用戶提一個(gè)復(fù)雜問(wèn)題Agent先判斷這個(gè)問(wèn)題需要哪些信息再?zèng)Q定調(diào)用幾次檢索工具最后匯總成答案。我用一個(gè)實(shí)際例子說(shuō)明。用戶問(wèn)“空壓機(jī)排氣溫度高報(bào)警怎么處置”這個(gè)問(wèn)題的正確回答需要三塊知識(shí)空壓機(jī)型號(hào)對(duì)應(yīng)的排氣溫度正常范圍、報(bào)警閾值、對(duì)應(yīng)型號(hào)的處置步驟。如果只做一次檢索返回的可能是報(bào)警處置步驟也可能是參數(shù)表里的溫度范圍反正很難一次拿全。Agent的做法是把一個(gè)問(wèn)題改寫(xiě)成三個(gè)子查詢子查詢一空壓機(jī)XX型號(hào)排氣溫度報(bào)警閾值是多少子查詢二排氣溫度高報(bào)警的處置步驟子查詢?nèi)諌簷C(jī)高溫報(bào)警的安全注意事項(xiàng)每個(gè)子查詢單獨(dú)走一遍檢索把三段結(jié)果拼接起來(lái)再讓LLM組織成完整回答。這樣每一步檢索都是精準(zhǔn)的最后給出的答案信息完整、邏輯連貫而不是大段堆砌無(wú)關(guān)內(nèi)容。要想讓Agent正確地做多步檢索關(guān)鍵在于工具定義寫(xiě)得到位。LangChain或自建Agent框架里每個(gè)工具有一個(gè)descriptionLLM就是靠這個(gè)描述來(lái)決定何時(shí)調(diào)用工具的。描述寫(xiě)得太簡(jiǎn)略比如“知識(shí)庫(kù)檢索工具”模型就很容易在第一次檢索拿到不相關(guān)內(nèi)容后直接放棄或者反復(fù)調(diào)用同一個(gè)工具碰運(yùn)氣。我會(huì)寫(xiě)清楚這個(gè)工具能搜什么、什么時(shí)候用、返回什么格式。工具定義示意tools [ { name: search_kb, description: 在工業(yè)知識(shí)庫(kù)中檢索設(shè)備參數(shù)、操作流程、報(bào)警處置、安全注意事項(xiàng)。 當(dāng)用戶問(wèn)題涉及具體設(shè)備型號(hào)、數(shù)值范圍、操作步驟時(shí)必須調(diào)用此工具。 支持傳入關(guān)鍵詞組合例如空壓機(jī) 排氣溫度 報(bào)警閾值。, parameters: {query: string} } ] def agent_loop(user_query, memory): # 1. 判斷是否需要拆解子問(wèn)題 sub_queries plan_subqueries(user_query, memory) # 2. 逐個(gè)子查詢調(diào)用檢索工具 contexts [] for sub_q in sub_queries: results search_kb(sub_q, top_k3) contexts.extend(results) # 3. 生成帶引用的最終回答 answer generate_with_sources(user_query, contexts) return answer還需要處理多輪對(duì)話記憶。工業(yè)場(chǎng)景下用戶不太會(huì)一句話把所有信息說(shuō)全更常見(jiàn)的是“3號(hào)空壓機(jī)排氣溫度高報(bào)警了怎么辦”Agent回答完之后用戶接著問(wèn)“那壓力上限呢”。如果不記憶上一輪的設(shè)備型號(hào)這個(gè)問(wèn)題就失去了主語(yǔ)。我在會(huì)話狀態(tài)里維護(hù)了兩個(gè)變量——“當(dāng)前設(shè)備型號(hào)”和“當(dāng)前討論故障”每當(dāng)識(shí)別到新的設(shè)備型號(hào)就更新后續(xù)提問(wèn)如果缺少主語(yǔ)自動(dòng)從會(huì)話狀態(tài)中補(bǔ)全。這個(gè)小功能看著不起眼但操作工用起來(lái)會(huì)明顯覺(jué)得“這個(gè)機(jī)器人是懂上下文的”。3.3 回答紀(jì)律提示詞里寫(xiě)死的三條底線知識(shí)庫(kù)Agent的LLM生成環(huán)節(jié)提示詞設(shè)計(jì)不能只考慮“答得準(zhǔn)”更要考慮“答得安全”。工業(yè)場(chǎng)景下我直接寫(xiě)死了三條紀(jì)律。第一條是強(qiáng)制引用?；卮鹬猩婕暗乃芯唧w參數(shù)、步驟、報(bào)警代碼必須附上引用來(lái)源格式為“依據(jù)文件名 第X頁(yè) 第X節(jié)”。這不僅是可解釋性問(wèn)題更是合規(guī)問(wèn)題。操作工需要一個(gè)可以翻紙質(zhì)手冊(cè)復(fù)核的答案而不是一個(gè)“看起來(lái)對(duì)但找不到依據(jù)”的結(jié)論。第二條是找不到就明說(shuō)。如果檢索到的上下文不足以支撐回答模型必須輸出“該問(wèn)題在當(dāng)前知識(shí)庫(kù)中沒(méi)有找到明確依據(jù)請(qǐng)轉(zhuǎn)人工確認(rèn)后再執(zhí)行操作”而不是基于通用知識(shí)自行推斷。工業(yè)領(lǐng)域最大的風(fēng)險(xiǎn)不是“答不上來(lái)”而是“答錯(cuò)了還理直氣壯”。我把這條寫(xiě)進(jìn)提示詞后無(wú)依據(jù)亂答的比例大幅下降。第三條是安全操作加現(xiàn)場(chǎng)確認(rèn)。凡是涉及設(shè)備操作、安全閾值、應(yīng)急處置的回答結(jié)尾自動(dòng)追加一句“具體操作請(qǐng)結(jié)合現(xiàn)場(chǎng)設(shè)備狀態(tài)和本地操作規(guī)程確認(rèn)”。這句話不是廢話它是在暗示用戶系統(tǒng)給出的內(nèi)容是知識(shí)庫(kù)中的標(biāo)準(zhǔn)規(guī)定但現(xiàn)場(chǎng)可能有標(biāo)準(zhǔn)之外的特殊情況操作前必須二次確認(rèn)。給出一段可以直接參考的回答提示詞模板你是一個(gè)工業(yè)知識(shí)庫(kù)問(wèn)答助手。請(qǐng)嚴(yán)格遵循以下規(guī)則 1. 只依據(jù)上下文檢索片段回答不得使用訓(xùn)練數(shù)據(jù)中的通用知識(shí)。 2. 回答中涉及參數(shù)、報(bào)警代碼、操作步驟時(shí)必須標(biāo)注引用來(lái)源格式為依據(jù)文件名 第X頁(yè)。 3. 如果上下文不足以回答用戶問(wèn)題明確回復(fù)“該問(wèn)題在當(dāng)前知識(shí)庫(kù)中沒(méi)有找到明確依據(jù)請(qǐng)轉(zhuǎn)人工確認(rèn)后再執(zhí)行操作。” 4. 涉及設(shè)備操作、安全閾值、應(yīng)急處置的回答結(jié)尾必須追加“具體操作請(qǐng)結(jié)合現(xiàn)場(chǎng)設(shè)備和本地操作規(guī)程確認(rèn)?！?5. 用簡(jiǎn)潔的中文回答不要重復(fù)問(wèn)題不要展開(kāi)與問(wèn)題無(wú)關(guān)的內(nèi)容。這套提示詞實(shí)際跑下來(lái)回答風(fēng)格變得非?！翱酥啤鄙踔劣袝r(shí)候顯得啰嗦但用戶接受度反而更高。工業(yè)場(chǎng)景的訴求是“我不需要你聰明我需要你靠譜”這三條紀(jì)律就是朝著靠譜去的。4. 實(shí)測(cè)評(píng)估與調(diào)優(yōu)從“能用”到“敢用”4.1 三類測(cè)試問(wèn)題與評(píng)估指標(biāo)知識(shí)庫(kù)Agent做出來(lái)能不能上線不能靠“感覺(jué)還行”必須有一套可量化的評(píng)估標(biāo)準(zhǔn)。我把測(cè)試問(wèn)題分成三類每類準(zhǔn)備30條。第一類是事實(shí)查詢型問(wèn)的是“XX設(shè)備額定功率是多少”“濾芯型號(hào)是多少”。這類問(wèn)題答案是唯一的檢索定位精準(zhǔn)度就是核心指標(biāo)。第二類是操作流程型問(wèn)的是“更換濾芯的具體步驟是什么”“多久做一次保養(yǎng)”。這類問(wèn)題答案跨度大往往分布在好幾頁(yè)考察的是檢索結(jié)果覆蓋是否完整。第三類是故障處置型問(wèn)的是“排氣溫度高報(bào)警怎么處置”“油壓過(guò)低會(huì)有什么后果”。這類問(wèn)題還需要關(guān)聯(lián)安全注意事項(xiàng)考察的是Agent多步檢索和信息整合能力。這90條測(cè)試問(wèn)題里有一半來(lái)自真實(shí)運(yùn)維群里的歷史提問(wèn)記錄另一半是我模擬新人操作工的口頭問(wèn)法。這個(gè)做法很關(guān)鍵——如果只靠自己順著文檔猜問(wèn)題來(lái)測(cè)試很容易高估系統(tǒng)效果因?yàn)椴碌膯?wèn)題往往正好落在文檔的關(guān)鍵句上。真實(shí)問(wèn)題則五花八門有問(wèn)“怎么會(huì)這樣的”、有問(wèn)“要不要緊的”數(shù)據(jù)才能暴露系統(tǒng)的短板。評(píng)估指標(biāo)我用四個(gè)檢索命中率Top3結(jié)果里有沒(méi)有包含關(guān)鍵答案段落、最終答案引用正確率、無(wú)依據(jù)回答比例越低越好、平均響應(yīng)時(shí)間。檢索命中率是基礎(chǔ)指標(biāo)引用正確率決定系統(tǒng)能不能“敢用”無(wú)依據(jù)回答比例體現(xiàn)安全底線。4.2 調(diào)優(yōu)過(guò)程中的參數(shù)與結(jié)果調(diào)優(yōu)過(guò)程有點(diǎn)像一個(gè)漏斗每一步都在修上一輪暴露的問(wèn)題。我把每次改動(dòng)和效果記錄下來(lái)方便后面復(fù)盤(pán)。第一版是純向量檢索chunk_size取1024字符沒(méi)有重疊沒(méi)有混合檢索。結(jié)果檢索命中率只有50%出頭而且經(jīng)常出現(xiàn)“文檔里明明有答案但系統(tǒng)答不對(duì)”的情況。原因很明確塊太大一個(gè)塊里信息太雜向量被稀釋沒(méi)有重疊關(guān)鍵句正好卡在切縫處時(shí)就整句丟失。第二版把chunk_size降到768overlap設(shè)為96同時(shí)把切塊方式改成“結(jié)構(gòu)優(yōu)先、定長(zhǎng)兜底”命中率提升到70%左右。這個(gè)提升主要靠數(shù)據(jù)質(zhì)量和模型沒(méi)什么關(guān)系。第三版最大的變化是表格獨(dú)立切塊、按行切時(shí)冗余表頭命中率升到80%。到這里基本達(dá)到了“能用”的門檻但離“敢用”還差一口氣。第四版加入BM25混合檢索加RRF融合命中率到了90%左右尤其是故障處置型問(wèn)題的表現(xiàn)改善明顯。第五版加了BGE-Reranker做結(jié)果重排把檢索出的Top20精排到Top5Top1準(zhǔn)確率明顯改善最終答案的引用正確率也隨之提升。各階段效果對(duì)比如下階段主要改動(dòng)檢索命中率引用正確率無(wú)依據(jù)回答比例V1純向量chunk_size102452%40%22%V2chunk_size768overlap96結(jié)構(gòu)切塊70%58%14%V3表格獨(dú)立切塊80%70%9%V4混合檢索RRF89%81%6%V5加Rerank精排93%88%3%調(diào)優(yōu)順序給我的體會(huì)是先管數(shù)據(jù)質(zhì)量再上重武器。前期最大的提升來(lái)自切塊方式和表格處理而不是換更大的模型或更復(fù)雜的算法。等到數(shù)據(jù)質(zhì)量穩(wěn)定了Rerank這類重型手段才發(fā)揮出價(jià)值。如果順序反了數(shù)據(jù)質(zhì)量一團(tuán)糟的時(shí)候上Rerank相當(dāng)于在污水里做精過(guò)濾效果有限還浪費(fèi)算力。5. 踩坑實(shí)錄知識(shí)庫(kù)Agent最常見(jiàn)的七個(gè)問(wèn)題5.1 檢索為空時(shí)按什么鏈路排查知識(shí)庫(kù)Agent上線后最讓人頭疼的問(wèn)題就是“檢索返回為空”或“答非所問(wèn)”表現(xiàn)形式五花八門但排查邏輯是有規(guī)律的按鏈路一步步走基本都能定位。排查順序第一檢查Embedding是否成功有沒(méi)有特殊字符導(dǎo)致文本被截?cái)嗟诙z查切塊是否存在過(guò)短或語(yǔ)義不完整的情況比如一個(gè)塊只有十幾個(gè)字符向量化后基本沒(méi)有語(yǔ)義信息第三檢查索引里有沒(méi)有該文檔的條目更新文檔后漏了重建索引是最常見(jiàn)的原因第四檢查混合檢索的融合權(quán)重看是不是某一方分?jǐn)?shù)過(guò)高壓掉了另一方。一個(gè)實(shí)用技巧上線后在日志里把每次檢索的“Top5命中片段文本相似度分?jǐn)?shù)”全部打出來(lái)。肉眼掃一遍日志就能判斷問(wèn)題出在切塊、向量還是融合環(huán)節(jié)。不要靠猜靠日志里的實(shí)際返回內(nèi)容定位。5.2 表格被“切碎”后的修復(fù)方案我踩過(guò)最深的一個(gè)坑就是報(bào)警代碼表被普通切塊方式切碎。那張表有三列報(bào)警代碼、含義、處置建議。用普通段落切法表頭單獨(dú)成塊數(shù)據(jù)行單獨(dú)成塊嵌入檢索時(shí)表頭和數(shù)據(jù)行完全分離。用戶搜“E-204報(bào)警怎么處置”時(shí)檢索到報(bào)警代碼“E-204”那個(gè)塊但處置建議字段已經(jīng)跑到下一個(gè)塊里了導(dǎo)致答案缺一半。修復(fù)方案就是我前面說(shuō)的表格獨(dú)立通道一個(gè)表格作為一個(gè)整體塊大表按行切分時(shí)每一行都冗余攜帶表頭列名每個(gè)表格塊的類型標(biāo)記為“table”檢索時(shí)優(yōu)先匹配類型為“table”的塊把表頭行和命中行拼成完整句子后再交給LLM。這個(gè)方案對(duì)所有以數(shù)值、字段為核心的工業(yè)文檔都適用。5.3 版本污染新舊文檔打架怎么治理工業(yè)文檔最頻繁的變更就是版本更新。有一次我把新版設(shè)備手冊(cè)索引進(jìn)去之后發(fā)現(xiàn)同一個(gè)問(wèn)題有時(shí)返回新參數(shù)、有時(shí)返回舊參數(shù)原因是舊版文檔還留在索引里。向量檢索按相似度排序新舊兩塊文本相似度都很高模型也不清楚該用哪個(gè)版本。治理方案有兩個(gè)一是在元數(shù)據(jù)里加版本號(hào)檢索時(shí)過(guò)濾條件只保留當(dāng)前有效版本二是更新文檔時(shí)對(duì)同一“來(lái)源文件章節(jié)路徑”的舊塊做標(biāo)記下線不直接物理刪除方便回溯歷史。每次版本更新后我會(huì)人工抽查20個(gè)典型問(wèn)題確保新舊文檔切換后沒(méi)有交叉污染。5.4 常見(jiàn)問(wèn)題速查表最后整理一張速查表把我在這個(gè)項(xiàng)目里遇到頻率最高的七類問(wèn)題匯總在一起方便后面排查時(shí)快速對(duì)照。現(xiàn)象可能原因解法檢索結(jié)果為空文檔未重建索引、Embedding失敗檢查索引版本查看切塊文本是否完整檢索命中但答案不對(duì)切塊太大導(dǎo)致語(yǔ)義混雜調(diào)低chunk_size增加overlap答案像是編的提示詞未強(qiáng)制引用、上下文不足加引用約束無(wú)依據(jù)時(shí)明確拒絕回答表格數(shù)據(jù)殘缺表格被當(dāng)普通文本切碎表格獨(dú)立切塊按行切時(shí)冗余表頭多輪對(duì)話丟失上下文會(huì)話狀態(tài)未維護(hù)設(shè)備型號(hào)增加會(huì)話變量記錄設(shè)備型號(hào)和故障主題新舊文檔答案打架舊版本未下線元數(shù)據(jù)版本過(guò)濾更新后人工抽查專有名詞檢索不準(zhǔn)Embedding不認(rèn)識(shí)縮寫(xiě)/型號(hào)加BM25混合檢索建立同義詞擴(kuò)展表最后說(shuō)一點(diǎn)個(gè)人體會(huì)。做完這個(gè)項(xiàng)目我最深的感受是知識(shí)庫(kù)Agent的主線并不取決于初始數(shù)據(jù)是66頁(yè)還是66萬(wàn)頁(yè)而是取決于你是否愿意把每一份文檔當(dāng)成知識(shí)資產(chǎn)來(lái)加工。66頁(yè)的好處恰恰在于體量小你有能力逐頁(yè)閱讀、逐表校對(duì)把每個(gè)知識(shí)塊都親手處理到位——這種精細(xì)度在大型自動(dòng)化流水線上反而不容易做到。如果你手頭也有一堆不起眼的技術(shù)文檔、操作手冊(cè)、規(guī)范規(guī)程別等著數(shù)據(jù)攢齊了再動(dòng)手。先拿這份小家底把閉環(huán)跑通后面每擴(kuò)展一份文檔都只是沿著這條主線再加一個(gè)分支而已。