1. 項(xiàng)目概述從嘈雜數(shù)據(jù)到結(jié)構(gòu)化對話的跨越最近在折騰對話智能體項(xiàng)目時(shí)遇到了一個(gè)經(jīng)典難題我們手頭積累了大量非結(jié)構(gòu)化的、質(zhì)量參差不齊的文檔、聊天記錄和報(bào)告也就是所謂的“嘈雜數(shù)據(jù)”。直接把這些數(shù)據(jù)扔給大語言模型效果時(shí)好時(shí)壞回答經(jīng)常跑偏或者“一本正經(jīng)地胡說八道”。為了解決這個(gè)問題我深入實(shí)踐了“Structure-Aware RAG”這個(gè)方向。簡單來說它不是一個(gè)全新的框架而是一種增強(qiáng)傳統(tǒng)檢索增強(qiáng)生成RAG的思路核心在于讓系統(tǒng)在檢索和生成時(shí)能夠“理解”并利用數(shù)據(jù)中潛在的結(jié)構(gòu)信息即使這些結(jié)構(gòu)在原始數(shù)據(jù)中是模糊、不完整甚至被噪聲淹沒的。這對于構(gòu)建穩(wěn)定、可靠的對話智能體至關(guān)重要因?yàn)楝F(xiàn)實(shí)世界的數(shù)據(jù)從來都不是干凈規(guī)整的。傳統(tǒng)的RAG流程可以概括為“切塊-向量化-檢索-生成”。但在處理客服日志、技術(shù)論壇討論、會(huì)議紀(jì)要這類數(shù)據(jù)時(shí)簡單按字?jǐn)?shù)或段落切分會(huì)把本應(yīng)屬于同一邏輯單元比如一個(gè)完整的問答對、一個(gè)故障排查步驟的內(nèi)容割裂也會(huì)把無關(guān)的廣告、重復(fù)發(fā)言、無意義符號噪聲一并索引。這直接導(dǎo)致檢索回來的“參考片段”質(zhì)量低下要么信息不全要么摻雜無關(guān)內(nèi)容最終拖累生成答案的準(zhǔn)確性和連貫性。Structure-Aware RAG要做的就是在數(shù)據(jù)處理的早期甚至在檢索和重排階段引入對數(shù)據(jù)內(nèi)在結(jié)構(gòu)的感知從而提升整個(gè)管道的信噪比。這個(gè)項(xiàng)目適合所有正在或計(jì)劃將RAG技術(shù)應(yīng)用于企業(yè)知識(shí)庫、智能客服、內(nèi)部助手等場景的開發(fā)者。特別是當(dāng)你面對的數(shù)據(jù)源五花八門、格式混亂時(shí)單純優(yōu)化向量模型或加大檢索數(shù)量可能收效甚微這時(shí)就需要從“結(jié)構(gòu)感知”這個(gè)維度入手了。接下來我會(huì)拆解整個(gè)實(shí)現(xiàn)思路、關(guān)鍵技術(shù)選型、實(shí)操步驟以及一路踩坑填坑的經(jīng)驗(yàn)。2. 核心思路與架構(gòu)設(shè)計(jì)為何以及如何感知結(jié)構(gòu)2.1 從“盲檢索”到“結(jié)構(gòu)感知”的范式轉(zhuǎn)變傳統(tǒng)RAG的檢索本質(zhì)上是“語義相似度匹配”。它假設(shè)被檢索的文本塊chunk是語義自洽的獨(dú)立單元。但在嘈雜數(shù)據(jù)中這個(gè)假設(shè)常常不成立。例如一份產(chǎn)品故障報(bào)告可能包含“用戶描述”、“工程師診斷”、“解決步驟”、“后續(xù)建議”等不同部分它們語義關(guān)聯(lián)但角色不同。如果簡單切塊可能“解決步驟”被單獨(dú)檢索出來卻丟失了關(guān)鍵的“故障現(xiàn)象”上下文導(dǎo)致生成的回答缺乏針對性。Structure-Aware RAG的核心思想是進(jìn)行兩次映射首先將非結(jié)構(gòu)化數(shù)據(jù)映射到某種結(jié)構(gòu)化的表示或元數(shù)據(jù)然后利用這種結(jié)構(gòu)化信息來指導(dǎo)檢索和生成。這里的“結(jié)構(gòu)”是廣義的可以包括邏輯文檔結(jié)構(gòu)如標(biāo)題、章節(jié)、列表、代碼塊、表格。內(nèi)容類型結(jié)構(gòu)如段落是“問題”、“答案”、“證據(jù)”、“總結(jié)”還是“引用”。領(lǐng)域本體結(jié)構(gòu)利用領(lǐng)域知識(shí)圖譜或本體識(shí)別文本中的實(shí)體如產(chǎn)品名、錯(cuò)誤代碼、人名及其關(guān)系。對話結(jié)構(gòu)在聊天數(shù)據(jù)中識(shí)別發(fā)言者、對話輪次、問答配對關(guān)系。這種感知帶來的優(yōu)勢是顯而易見的。在檢索階段我們可以進(jìn)行更精細(xì)的過濾例如只檢索被標(biāo)記為“解決方案”的文本塊或者進(jìn)行結(jié)構(gòu)化的聚合檢索將同一個(gè)案例的所有相關(guān)部分作為一個(gè)整體返回。在生成階段模型可以將結(jié)構(gòu)信息作為提示的一部分例如“根據(jù)以下‘故障現(xiàn)象’描述和對應(yīng)的‘修復(fù)步驟’生成給用戶的答復(fù)?！边@極大地約束了生成過程使其更專注、更準(zhǔn)確。2.2 系統(tǒng)架構(gòu)設(shè)計(jì)分層處理與信息流基于上述思路我設(shè)計(jì)了一個(gè)分層處理架構(gòu)整個(gè)流程分為離線處理和在線服務(wù)兩大部分。離線處理管道知識(shí)庫構(gòu)建原始數(shù)據(jù)接入與解析支持多種格式PDF、Word、HTML、Markdown、純文本、JSON日志。使用Apache Tika或Unstructured庫進(jìn)行初步解析提取原始文本和基礎(chǔ)格式標(biāo)記。噪聲過濾與清洗針對特定數(shù)據(jù)源定制規(guī)則。例如去除HTML標(biāo)簽殘留、標(biāo)準(zhǔn)化日期格式、過濾短于一定字符的無意義段落、使用正則表達(dá)式移除特定廣告模板文本。結(jié)構(gòu)識(shí)別與增強(qiáng)對于格式良好的文檔利用解析器得到的標(biāo)題層級H1, H2, H3自動(dòng)構(gòu)建文檔大綱并將章節(jié)標(biāo)題作為后續(xù)文本塊的元數(shù)據(jù)。對于嘈雜文本/對話這是關(guān)鍵。我采用了基于提示詞Prompt的輕量級大語言模型如GPT-3.5-Turbo或本地部署的Qwen2-7B進(jìn)行“文本片段分類”。例如將客服對話片段分類為[用戶查詢]、[客服回復(fù)-解決方案]、[客服回復(fù)-詢問信息]、[閑聊]等。同時(shí)使用NER命名實(shí)體識(shí)別工具如spaCy提取產(chǎn)品名、版本號、錯(cuò)誤碼等實(shí)體。智能分塊Chunking這是與傳統(tǒng)RAG差異最大的地方。我放棄了簡單的固定長度重疊分塊采用了基于結(jié)構(gòu)的遞歸分塊。策略優(yōu)先按識(shí)別出的結(jié)構(gòu)邊界如章節(jié)標(biāo)題、對話輪次進(jìn)行分割。如果某個(gè)結(jié)構(gòu)塊過長再按語義使用句子分割器或固定長度進(jìn)行二次分割。關(guān)鍵是為每個(gè)塊保留豐富的元數(shù)據(jù)所屬文檔、父級標(biāo)題、內(nèi)容類型、包含的實(shí)體列表、在原文中的位置等。向量化與索引構(gòu)建向量模型選用text-embedding-3-small或BGE-M3這類支持長文本且在多語言和領(lǐng)域表現(xiàn)良好的模型。關(guān)鍵點(diǎn)我們不僅為文本內(nèi)容生成向量還可以選擇為“文本內(nèi)容關(guān)鍵元數(shù)據(jù)”如“標(biāo)題安裝故障類型解決方案實(shí)體產(chǎn)品A, 錯(cuò)誤碼500”生成一個(gè)增強(qiáng)向量用于特定場景的檢索。向量數(shù)據(jù)庫選用Milvus或PgVector如果與現(xiàn)有PostgreSQL生態(tài)結(jié)合緊密。除了存儲(chǔ)向量必須利用其標(biāo)量過濾能力。我們將所有結(jié)構(gòu)元數(shù)據(jù)類型、實(shí)體、文檔ID作為標(biāo)量字段存入以便在檢索時(shí)進(jìn)行高效過濾。混合索引同時(shí)建立全文索引如Elasticsearch用于關(guān)鍵詞召回與向量檢索形成互補(bǔ)。在線服務(wù)管道問答查詢理解與增強(qiáng)接收用戶問題后首先進(jìn)行查詢分類和實(shí)體提取。例如識(shí)別出用戶問題屬于“故障排查”類并提取出“產(chǎn)品B”、“無法啟動(dòng)”等實(shí)體。結(jié)構(gòu)化檢索第一步候選召回。使用增強(qiáng)后的查詢向量進(jìn)行向量相似度搜索召回Top K個(gè)候選塊例如K50。第二步結(jié)構(gòu)過濾與重排。利用查詢中識(shí)別出的類型和實(shí)體對候選集進(jìn)行標(biāo)量過濾。例如優(yōu)先過濾內(nèi)容類型為“解決方案”且實(shí)體包含“產(chǎn)品B”的塊。然后可以結(jié)合BM25分?jǐn)?shù)、元數(shù)據(jù)權(quán)重如賦予“標(biāo)題”匹配更高權(quán)重、以及塊之間的結(jié)構(gòu)連貫性例如優(yōu)先選擇屬于同一章節(jié)的連續(xù)塊進(jìn)行重新排序。上下文構(gòu)建與提示工程將重排后的Top N個(gè)文本塊連同它們的結(jié)構(gòu)元數(shù)據(jù)按照一定的模板組織成提示上下文。模板會(huì)明確告訴大模型每個(gè)塊的“角色”是什么。生成與后處理大模型基于富含結(jié)構(gòu)信息的上下文生成答案。后處理可能包括引用溯源根據(jù)元數(shù)據(jù)標(biāo)注答案來源、格式美化等。實(shí)操心得一結(jié)構(gòu)信息的粒度權(quán)衡結(jié)構(gòu)信息不是越多越好。最初我嘗試為每個(gè)塊標(biāo)記十幾種元數(shù)據(jù)導(dǎo)致索引膨脹和檢索邏輯復(fù)雜。后來發(fā)現(xiàn)針對當(dāng)前對話場景抓住內(nèi)容類型、核心實(shí)體和父級標(biāo)題這三類元數(shù)據(jù)就能解決80%的問題。關(guān)鍵在于分析你的問答場景中最常見的失敗模式然后針對性地設(shè)計(jì)結(jié)構(gòu)標(biāo)簽。3. 關(guān)鍵技術(shù)點(diǎn)實(shí)現(xiàn)與選型解析3.1 嘈雜數(shù)據(jù)下的結(jié)構(gòu)識(shí)別規(guī)則、模型與混合策略處理噪聲數(shù)據(jù)純規(guī)則方法脆弱純模型方法成本高且需要標(biāo)注數(shù)據(jù)。我采用了一種“規(guī)則打底模型精修主動(dòng)學(xué)習(xí)迭代”的混合策略。1. 基于規(guī)則與啟發(fā)式的快速過濾正則表達(dá)式與關(guān)鍵詞列表用于清除明顯的噪聲如版權(quán)聲明、頁眉頁腳、特定聯(lián)系方式模板。例如r^\\s*版權(quán)所有.*$。統(tǒng)計(jì)特征過濾剔除過短如15字符或過長如5000字符未經(jīng)分段的文本塊剔除符號占比過高的行。格式線索對于殘留的Markdown或HTML標(biāo)簽如##, 將其轉(zhuǎn)換為結(jié)構(gòu)標(biāo)記。2. 基于輕量級模型的分類與標(biāo)注任務(wù)文本片段分類、命名實(shí)體識(shí)別NER、關(guān)系抽取可選。選型分類/NER優(yōu)先考慮在特定領(lǐng)域數(shù)據(jù)上微調(diào)過的小模型如RoBERTa-base。如果領(lǐng)域通用spaCy的預(yù)訓(xùn)練管道是一個(gè)快速起步的選擇。對于對話數(shù)據(jù)我使用了Conversational語料微調(diào)的BERT變體來區(qū)分用戶和客服語句。零樣本/少樣本分類當(dāng)標(biāo)簽體系不確定或數(shù)據(jù)未標(biāo)注時(shí)使用大語言模型的function calling或structured output能力。例如讓GPT-4根據(jù)定義好的JSON Schema輸出片段的type和entities。雖然單次調(diào)用成本高但可用于生成初始訓(xùn)練數(shù)據(jù)。實(shí)施將清洗后的文本片段通常是一個(gè)段落或一個(gè)對話回合送入模型獲得類型標(biāo)簽和實(shí)體列表。這里的一個(gè)技巧是對于長文檔先進(jìn)行初步分塊再分類比直接分類整個(gè)文檔準(zhǔn)確率高。3. 主動(dòng)學(xué)習(xí)循環(huán)將模型分類置信度低的樣本自動(dòng)放入一個(gè)待審核隊(duì)列。開發(fā)一個(gè)簡單的標(biāo)注工具讓領(lǐng)域?qū)＜叶ㄆ趯徍岁?duì)列中的樣本并糾正。用新標(biāo)注的數(shù)據(jù)定期微調(diào)模型形成閉環(huán)。這個(gè)過程能顯著提升模型在特定數(shù)據(jù)分布下的表現(xiàn)。3.2 向量模型與數(shù)據(jù)庫選型為結(jié)構(gòu)化檢索鋪路向量模型選型考量上下文長度由于我們采用結(jié)構(gòu)感知分塊塊的大小可能不固定需要模型支持足夠長的上下文如8192 tokens。text-embedding-3-large和BGE-M3都支持長文本。領(lǐng)域適應(yīng)性如果在專業(yè)領(lǐng)域如醫(yī)療、金融需要考慮在領(lǐng)域語料上繼續(xù)訓(xùn)練Post-training或微調(diào)Fine-tuning嵌入模型。BGE系列提供了方便的微調(diào)腳本。多向量檢索BGE-M3模型支持稠密向量、稀疏向量和多向量三種檢索方式。對于結(jié)構(gòu)化檢索我們可以利用稀疏向量類似于關(guān)鍵詞權(quán)重來強(qiáng)化元數(shù)據(jù)匹配。這是一個(gè)值得嘗試的高級特性。實(shí)踐選擇在項(xiàng)目中我主要使用text-embedding-3-small因?yàn)槠湓谕ㄓ萌蝿?wù)上的性價(jià)比極高。在對特定行業(yè)術(shù)語召回要求高的場景我會(huì)用一批領(lǐng)域查詢-相關(guān)文檔對對BGE-M3進(jìn)行輕量級Lora微調(diào)提升效果。向量數(shù)據(jù)庫選型與索引設(shè)計(jì)為什么是MilvusMilvus專為向量搜索設(shè)計(jì)性能強(qiáng)勁尤其擅長處理十億級向量。它強(qiáng)大的標(biāo)量過濾功能與我們存儲(chǔ)大量結(jié)構(gòu)元數(shù)據(jù)的需求完美契合。其IVF_FLAT或HNSW索引能高效處理向量相似度搜索。表結(jié)構(gòu)設(shè)計(jì)示例-- 概念上的表結(jié)構(gòu)Milvus通過Collection和Field實(shí)現(xiàn) Collection: knowledge_chunks Fields: id: String (主鍵) content: String (文本內(nèi)容) content_vector: Float32[1536] (內(nèi)容向量) doc_id: String (來源文檔ID) chunk_type: String (e.g., problem, solution, reference) -- 內(nèi)容類型 parent_headings: List[String] (父級標(biāo)題路徑如 [用戶手冊, 安裝, 常見問題]) entities: List[String] (命名實(shí)體列表如 [ProductX, Error404]) metadata_json: String (其他原始元數(shù)據(jù))檢索時(shí)的過濾與混合搜索 Milvus允許在搜索時(shí)添加布爾表達(dá)式進(jìn)行過濾。例如expr chunk_type solution and ProductX in entities先過濾再在過濾后的結(jié)果中做向量搜索或者先做向量搜索再對結(jié)果進(jìn)行過濾排序。通常對于過濾后數(shù)據(jù)量仍然很大的情況“先搜后濾”更快對于過濾條件能極大縮小范圍的情況“先濾后搜”更優(yōu)。需要根據(jù)數(shù)據(jù)分布進(jìn)行測試。3.3 檢索策略與重排序融合語義與結(jié)構(gòu)信號單純的向量檢索在嘈雜數(shù)據(jù)中容易“失焦”。我們需要融合多種信號。1. 混合檢索Hybrid Search向量檢索捕捉語義相似性。關(guān)鍵詞檢索BM25捕捉精確術(shù)語匹配對于產(chǎn)品型號、錯(cuò)誤代碼等關(guān)鍵詞至關(guān)重要。使用Elasticsearch或Milvus2.3版本支持BM25實(shí)現(xiàn)。融合方法采用加權(quán)分?jǐn)?shù)融合如score 0.7 * vector_score 0.3 * bm25_score或倒數(shù)融合排名RRF。RRF更魯棒因?yàn)樗灰蕾囉诜謹(jǐn)?shù)本身的絕對尺度。# 簡化的RRF示例 def reciprocal_rank_fusion(results_list, k60): fused_scores {} for results in results_list: for rank, doc_id in enumerate(results): fused_scores[doc_id] fused_scores.get(doc_id, 0) 1 / (rank k) return sorted(fused_scores.items(), keylambda x: x[1], reverseTrue)2. 基于結(jié)構(gòu)元數(shù)據(jù)的重排序 這是Structure-Aware的精髓。在混合檢索得到初步排名后引入結(jié)構(gòu)規(guī)則進(jìn)行調(diào)序。規(guī)則重排類型優(yōu)先級解決方案問題描述參考理論。實(shí)體匹配度完全匹配查詢實(shí)體的塊排名提升。結(jié)構(gòu)完整性優(yōu)先返回屬于同一邏輯單元如相同parent_headings的連續(xù)塊組而不是分散的塊。學(xué)習(xí)式重排Learned Reranker 對于更復(fù)雜的場景可以訓(xùn)練一個(gè)輕量級的交叉編碼器Cross-Encoder如bge-reranker-base來對查詢-候選文檔對進(jìn)行精細(xì)打分。我們可以將結(jié)構(gòu)特征如類型是否匹配、實(shí)體重疊度作為特征與文本對一起輸入重排模型進(jìn)行微調(diào)讓模型學(xué)習(xí)結(jié)構(gòu)重要性的權(quán)重。實(shí)操心得二檢索效果的“黃金標(biāo)準(zhǔn)”不要盲目追求復(fù)雜的重排策略。建立一個(gè)由領(lǐng)域?qū)＜覙?biāo)注的小規(guī)模測試集約100-200個(gè)典型查詢及其相關(guān)文檔列表至關(guān)重要。任何檢索策略的調(diào)整都以在這個(gè)測試集上的MRR平均倒數(shù)排名、RecallK或NDCG指標(biāo)的提升為最終依據(jù)。否則很容易陷入主觀感覺的誤區(qū)。4. 基于Spring Boot與LangChain4j的實(shí)戰(zhàn)實(shí)現(xiàn)4.1 項(xiàng)目環(huán)境搭建與核心依賴我們選擇Spring Boot 3.x作為后端框架LangChain4j用于編排RAG流程Milvus作為向量數(shù)據(jù)庫Elasticsearch用于關(guān)鍵詞檢索。Maven核心依賴dependencies dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId /dependency !-- LangChain4j 核心 -- dependency groupIddev.langchain4j/groupId artifactIdlangchain4j/artifactId version0.31.0/version /dependency !-- LangChain4j Spring Boot 集成 -- dependency groupIddev.langchain4j/groupId artifactIdlangchain4j-spring-boot-starter/artifactId version0.31.0/version /dependency !-- Milvus Java SDK -- dependency groupIdio.milvus/groupId artifactIdmilvus-sdk-java/artifactId version2.3.6/version /dependency !-- Elasticsearch Java Client -- dependency groupIdorg.elasticsearch.client/groupId artifactIdelasticsearch-rest-high-level-client/artifactId version7.17.19/version !-- 注意版本與ES服務(wù)匹配 -- /dependency !-- 用于文本解析和NLP處理 -- dependency groupIdorg.apache.tika/groupId artifactIdtika-core/artifactId version2.9.1/version /dependency /dependencies配置文件application.ymlspring: application: name: structure-aware-rag-service langchain4j: open-ai: chat-model: api-key: ${OPENAI_API_KEY} model-name: gpt-4-turbo-preview # 或 gpt-3.5-turbo embedding-model: api-key: ${OPENAI_API_KEY} model-name: text-embedding-3-small dimensions: 1536 milvus: host: localhost port: 19530 collection-name: knowledge_chunks elasticsearch: host: localhost port: 92004.2 結(jié)構(gòu)化知識(shí)庫構(gòu)建管道實(shí)現(xiàn)我們實(shí)現(xiàn)一個(gè)KnowledgeIngestionPipeline服務(wù)它封裝了從原始文檔到入庫的完整流程。1. 文檔解析與清洗組件Service public class DocumentProcessor { Autowired private TikaParser tikaParser; // 封裝Apache Tika public ProcessedDocument parseAndClean(File file) { // 1. 原始解析 String rawText tikaParser.parseToString(file); // 2. 自定義清洗鏈 String cleanedText cleanText(rawText); // 3. 提取基礎(chǔ)元數(shù)據(jù)如文件名、格式、作者等 Metadata metadata extractBasicMetadata(file); return new ProcessedDocument(cleanedText, metadata); } private String cleanText(String text) { // 應(yīng)用一系列清洗規(guī)則 text removeHeaderFooter(text); // 基于正則的頁眉頁腳移除 text normalizeWhitespace(text); text filterShortLines(text, 10); // 過濾短行 // ... 更多領(lǐng)域特定規(guī)則 return text; } }2. 結(jié)構(gòu)識(shí)別與智能分塊組件 這是核心。我們實(shí)現(xiàn)一個(gè)StructureAwareChunker。Component public class StructureAwareChunker { Autowired private TextClassifier textClassifier; // 封裝微調(diào)的文本分類模型 Autowired private NERService nerService; // 封裝spaCy或BERT NER public ListTextChunk chunk(ProcessedDocument doc) { ListTextChunk chunks new ArrayList(); String fullText doc.getContent(); // 策略1: 優(yōu)先按顯式標(biāo)題分割 (假設(shè)已通過解析器提取出標(biāo)題列表) ListHeadingSegment headingSegments splitByHeadings(fullText); for (HeadingSegment segment : headingSegments) { // 策略2: 對每個(gè)標(biāo)題下的內(nèi)容如果過長再按語義句子分割 ListString subSegments splitBySemantic(segment.getContent(), 500); // 目標(biāo)500字符 for (String subContent : subSegments) { // 對每個(gè)子塊進(jìn)行分類和實(shí)體識(shí)別 String chunkType textClassifier.classify(subContent); ListString entities nerService.extractEntities(subContent); // 構(gòu)建富元數(shù)據(jù)的塊對象 TextChunk chunk TextChunk.builder() .id(UUID.randomUUID().toString()) .content(subContent) .docId(doc.getId()) .chunkType(chunkType) .parentHeadings(segment.getHeadingPath()) // 如 [Chapter 3, Installation] .entities(entities) .metadata(/*...*/) .build(); chunks.add(chunk); } } // 如果沒有標(biāo)題結(jié)構(gòu)則回退到遞歸字符分割 if (chunks.isEmpty()) { chunks recursiveSplitByCharacters(fullText, 500, 50); } return chunks; } }3. 向量化與索引入庫組件Service public class VectorIndexingService { Autowired private EmbeddingModel embeddingModel; // LangChain4j注入 Autowired private MilvusService milvusService; // 封裝的Milvus客戶端 Autowired private ElasticsearchService esService; public void indexChunks(ListTextChunk chunks) { for (TextChunk chunk : chunks) { // 1. 生成向量 Embedding embedding embeddingModel.embed(chunk.getContent()).content(); chunk.setEmbedding(embedding.vector()); // 2. 準(zhǔn)備Milvus插入數(shù)據(jù) MapString, Object milvusData Map.of( id, chunk.getId(), content, chunk.getContent(), vector, chunk.getEmbedding(), doc_id, chunk.getDocId(), chunk_type, chunk.getChunkType(), parent_headings, chunk.getParentHeadings(), entities, chunk.getEntities() ); milvusService.insert(milvusData); // 3. 同時(shí)索引到Elasticsearch用于關(guān)鍵詞檢索 esService.index(chunk); } } }4.3 在線問答服務(wù)實(shí)現(xiàn)實(shí)現(xiàn)一個(gè)RAGQueryService處理用戶查詢。1. 查詢理解Component public class QueryAnalyzer { public AnalyzedQuery analyze(String userQuery) { // 使用LLM或規(guī)則進(jìn)行查詢分類和實(shí)體提取 // 例如調(diào)用OpenAI的function calling String prompt 分析以下用戶查詢提取查詢類型和關(guān)鍵實(shí)體。查詢 userQuery; // ... 調(diào)用LLM獲得結(jié)構(gòu)化輸出 // 假設(shè)返回{“type”: “troubleshooting, entities: [ProductZ, slow]} return new AnalyzedQuery(userQuery, “troubleshooting”, List.of(ProductZ, slow)); } }2. 結(jié)構(gòu)化檢索Service public class StructuredRetriever { Autowired private MilvusService milvusService; Autowired private ElasticsearchService esService; Autowired private RerankerService rerankerService; public ListRetrievedChunk retrieve(AnalyzedQuery query) { // 1. 混合召回 ListRetrievedChunk vectorResults milvusService.vectorSearch(query.getOriginalQuery(), 50); ListRetrievedChunk keywordResults esService.keywordSearch(query.getOriginalQuery(), 50); // 2. 融合 (例如使用RRF) ListRetrievedChunk fusedResults reciprocalRankFusion(vectorResults, keywordResults); // 3. 結(jié)構(gòu)過濾 (可選也可在向量搜索時(shí)通過表達(dá)式完成) ListRetrievedChunk filteredResults fusedResults.stream() .filter(chunk - isRelevantByStructure(chunk, query)) // 例如類型匹配或?qū)嶓w包含 .collect(Collectors.toList()); // 4. 學(xué)習(xí)式重排 (如果有訓(xùn)練好的重排器) ListRetrievedChunk finalResults rerankerService.rerank(query.getOriginalQuery(), filteredResults); return finalResults.subList(0, Math.min(8, finalResults.size())); // 返回Top N } private boolean isRelevantByStructure(RetrievedChunk chunk, AnalyzedQuery query) { // 簡單規(guī)則如果查詢類型是“troubleshooting”則優(yōu)先“solution”類型的塊 if (troubleshooting.equals(query.getType())) { return solution.equals(chunk.getChunkType()) || chunk.getEntities().containsAll(query.getEntities()); } return true; } }3. 提示構(gòu)建與答案生成Component public class AnswerGenerator { Autowired private ChatLanguageModel chatModel; public String generateAnswer(String query, ListRetrievedChunk contexts) { // 構(gòu)建富含結(jié)構(gòu)信息的提示詞 StringBuilder contextBuilder new StringBuilder(請根據(jù)以下參考信息回答問題。參考信息已按類型組織\n\n); for (RetrievedChunk ctx : contexts) { contextBuilder.append(String.format([類型%s | 標(biāo)題%s]\n%s\n---\n, ctx.getChunkType(), String.join( - , ctx.getParentHeadings()), ctx.getContent())); } String systemPrompt 你是一個(gè)專業(yè)的助手請嚴(yán)格依據(jù)提供的參考信息回答問題。參考信息中的[類型]和[標(biāo)題]有助于你理解內(nèi)容的結(jié)構(gòu)和重點(diǎn)。如果信息不足請明確說明。; String userPrompt String.format(問題%s\n\n參考信息\n%s, query, contextBuilder.toString()); // 調(diào)用LLM String answer chatModel.generate(userPrompt); return answer; } }4. REST API端點(diǎn)RestController RequestMapping(/api/rag) public class RagController { Autowired private RAGQueryService ragService; PostMapping(/query) public ResponseEntityAnswerResponse query(RequestBody QueryRequest request) { String answer ragService.answerQuestion(request.getQuestion()); // 可以在這里附加檢索到的來源chunk ID等信息 return ResponseEntity.ok(new AnswerResponse(answer)); } }5. 效果評估、問題排查與優(yōu)化經(jīng)驗(yàn)5.1 如何評估Structure-Aware RAG的效果評估不能只靠“感覺”需要建立多維度的評估體系。1. 檢索階段評估召回率RecallK對于一組測試問題標(biāo)準(zhǔn)答案相關(guān)的文檔出現(xiàn)在Top K個(gè)檢索結(jié)果中的比例。這是衡量檢索系統(tǒng)是否“找得全”的核心指標(biāo)。Structure-Aware的目標(biāo)是在相同K下提升召回率尤其是召回高質(zhì)量、結(jié)構(gòu)完整的文檔塊。平均倒數(shù)排名MRR衡量相關(guān)文檔排名的指標(biāo)。提升MRR意味著系統(tǒng)能把更相關(guān)的文檔排到更前面。人工評估檢索結(jié)果相關(guān)性隨機(jī)抽樣一批查詢讓評估人員對Top 5檢索結(jié)果的相關(guān)性打分如1-5分。重點(diǎn)關(guān)注結(jié)構(gòu)感知是否減少了噪聲片段的混入。2. 生成階段評估事實(shí)準(zhǔn)確性Factual Accuracy將生成的答案與標(biāo)準(zhǔn)答案對比檢查關(guān)鍵事實(shí)如日期、數(shù)字、步驟是否一致。可以借助LLM本身進(jìn)行評估如使用GPT-4作為裁判但需設(shè)計(jì)嚴(yán)謹(jǐn)?shù)奶崾驹~。答案相關(guān)性Answer Relevance生成的答案是否直接、完整地回應(yīng)了問題。引用質(zhì)量Citation Quality如果系統(tǒng)支持引用溯源檢查引用的來源塊是否真正支持生成的陳述。3. 端到端評估人工整體評分模擬真實(shí)用戶對問答結(jié)果從“準(zhǔn)確性、有用性、流暢性”等方面進(jìn)行綜合打分1-5分。這是最可靠的終極指標(biāo)。A/B測試在線上環(huán)境將一部分流量導(dǎo)向新Structure-Aware系統(tǒng)一部分導(dǎo)向舊系統(tǒng)對比關(guān)鍵業(yè)務(wù)指標(biāo)如“問題解決率”、“用戶滿意度評分”、“轉(zhuǎn)人工率”等。5.2 常見問題、排查與優(yōu)化技巧在開發(fā)過程中我遇到了不少典型問題以下是排查思路和解決方案。問題1檢索結(jié)果似乎沒有利用到結(jié)構(gòu)信息噪聲依然很多。排查檢查結(jié)構(gòu)識(shí)別環(huán)節(jié)查看chunk_type和entities字段的賦值是否正確。抽樣一些數(shù)據(jù)人工驗(yàn)證分類和NER的結(jié)果。檢查向量數(shù)據(jù)庫過濾表達(dá)式確保在Milvus搜索時(shí)過濾表達(dá)式語法正確且字段名匹配。例如expr chunk_type solution。檢查混合檢索權(quán)重如果關(guān)鍵詞檢索權(quán)重過高可能會(huì)拉回大量包含關(guān)鍵詞但無關(guān)的噪聲。嘗試調(diào)整向量檢索和關(guān)鍵詞檢索的權(quán)重比例或改用RRF。優(yōu)化細(xì)化結(jié)構(gòu)標(biāo)簽如果“solution”標(biāo)簽下仍然混雜了不同內(nèi)容考慮進(jìn)一步細(xì)分如“solution_step_by_step”, “solution_cause_analysis”。增強(qiáng)查詢理解提升查詢分類和實(shí)體提取的準(zhǔn)確率。考慮使用少量標(biāo)注數(shù)據(jù)微調(diào)一個(gè)小模型專門用于查詢意圖分類。問題2生成答案有時(shí)會(huì)“無視”結(jié)構(gòu)提示依然胡編亂造。排查檢查提示詞模板確保提示詞中明確指令模型關(guān)注[類型]和[標(biāo)題]?？梢試L試更強(qiáng)烈的指令如“你必須主要依據(jù)[類型解決方案]下的內(nèi)容來生成回答步驟”。檢查檢索上下文質(zhì)量即使有結(jié)構(gòu)標(biāo)簽如果Top 3的檢索塊本身信息不足或矛盾模型也難以生成好答案。需要回溯檢查檢索階段。檢查模型本身嘗試換用更強(qiáng)大的模型如從gpt-3.5-turbo切換到gpt-4看是否改善。如果必須使用小模型可能需要更嚴(yán)格的上下文過濾。優(yōu)化實(shí)現(xiàn)“引用溯源”要求模型在生成答案時(shí)為每個(gè)主要陳述注明來源塊的ID。這不僅能增加可信度也能反向驗(yàn)證模型是否真的參考了指定內(nèi)容?？梢酝ㄟ^system prompt強(qiáng)制要求并在后處理中解析輸出。上下文壓縮與摘要如果檢索回的上下文過長可以在喂給LLM前先讓另一個(gè)LLM對每個(gè)塊或相關(guān)塊組進(jìn)行摘要保留核心信息去除冗余。問題3系統(tǒng)延遲較高響應(yīng)慢。排查性能剖析使用APM工具如SkyWalking, OpenTelemetry定位耗時(shí)環(huán)節(jié)。通常是向量檢索/混合檢索、LLM API調(diào)用、或復(fù)雜的重排模型。檢查索引Milvus的向量索引類型如HNSW參數(shù)是否優(yōu)化efConstruction和M參數(shù)影響構(gòu)建和搜索的權(quán)衡。檢查緩存頻繁出現(xiàn)的相似查詢是否做了緩存優(yōu)化異步與批處理對于文檔入庫的向量化過程采用批處理異步進(jìn)行。對于查詢中的LLM調(diào)用考慮是否可以使用流式響應(yīng)先返回部分結(jié)果。精簡重排模型如果使用學(xué)習(xí)式重排器確保模型足夠輕量如bge-reranker-base而非large。可以考慮將重排模型部署在GPU上或使用量化版本。設(shè)置超時(shí)與降級為檢索、LLM調(diào)用設(shè)置合理的超時(shí)時(shí)間。當(dāng)某個(gè)環(huán)節(jié)失敗時(shí)有降級方案如跳過重排直接使用向量檢索結(jié)果。問題4處理特定領(lǐng)域術(shù)語或新詞時(shí)效果差。排查檢查嵌入模型和NER模型是否在這些術(shù)語上表現(xiàn)不佳。可以查看這些術(shù)語的向量是否與相關(guān)概念距離過遠(yuǎn)。優(yōu)化領(lǐng)域微調(diào)嵌入模型收集領(lǐng)域內(nèi)的查詢正例文檔對對BGE等可微調(diào)模型進(jìn)行繼續(xù)預(yù)訓(xùn)練或?qū)Ρ葘W(xué)習(xí)微調(diào)。擴(kuò)展實(shí)體詞典將領(lǐng)域內(nèi)的專有名詞、產(chǎn)品型號等加入NER模型的詞典或作為外部詞典進(jìn)行匹配補(bǔ)充。同義詞擴(kuò)展在查詢時(shí)自動(dòng)將專業(yè)術(shù)語擴(kuò)展為常見的同義表述增加召回機(jī)會(huì)。實(shí)操心得三持續(xù)迭代的飛輪Structure-Aware RAG不是一個(gè)一勞永逸的項(xiàng)目。必須建立一個(gè)數(shù)據(jù)飛輪日志收集記錄所有用戶查詢、檢索到的上下文、生成的答案以及用戶的反饋顯式的評分或隱式的后續(xù)行為。失敗案例挖掘定期分析回答不佳或收到負(fù)面反饋的案例。是檢索錯(cuò)了還是結(jié)構(gòu)識(shí)別錯(cuò)了還是生成錯(cuò)了數(shù)據(jù)標(biāo)注與模型更新針對性的失敗案例進(jìn)行數(shù)據(jù)標(biāo)注用于優(yōu)化結(jié)構(gòu)識(shí)別模型、查詢分類模型或重排模型。評估與上線將優(yōu)化后的模型重新評估通過A/B測試驗(yàn)證效果后全量上線。 這個(gè)循環(huán)是系統(tǒng)持續(xù)進(jìn)化的核心動(dòng)力。