1. 為什么“帶引用的回答”才是RAG落地的分水嶺做檢索增強(qiáng)生成RAG的同行大概都有過這種體驗(yàn)Demo階段效果驚艷一旦交給業(yè)務(wù)方試用第一個(gè)被質(zhì)疑的問題永遠(yuǎn)是——“這個(gè)結(jié)論你是從哪份文檔里看出來的”如果答不上來哪怕答案本身是對的用戶也不敢信。這不是用戶挑剔而是RAG系統(tǒng)從“玩具”走向“可用”必須跨過的一道坎。我最初搭第一版問答助手時(shí)走的是最樸素的路線把文檔切片、向量化、存進(jìn)向量庫用戶提問就召回Top-K片段拼進(jìn)Prompt讓大模型自由發(fā)揮。結(jié)果上線第二天就翻車了。有同事問“差旅報(bào)銷的標(biāo)準(zhǔn)是多少”模型洋洋灑灑寫了一段數(shù)字看著挺像那么回事但翻遍制度文檔根本找不到對應(yīng)條款——典型的“睜眼說瞎話”。更麻煩的是這種幻覺往往裹著專業(yè)術(shù)語的外衣不逐字核對很難發(fā)現(xiàn)。問題的根子在于純生成模式下模型沒有“必須忠于原文”的硬約束。它只是在做概率續(xù)寫而不是在做信息檢索。RAG的價(jià)值恰恰在于把“生成”錨定在“檢索到的真實(shí)片段”上但如果輸出層不把引用關(guān)系顯式暴露出來這個(gè)錨定就是隱形的用戶無法驗(yàn)證系統(tǒng)也無法自證。所以這篇要聊的就是怎么用Spring AI把RAG問答助手做成“每句話都有出處”的形態(tài)。核心目標(biāo)有三個(gè)回答里的關(guān)鍵結(jié)論能對應(yīng)到具體文檔片段引用來源可點(diǎn)擊、可追溯當(dāng)檢索不到相關(guān)內(nèi)容時(shí)系統(tǒng)要老實(shí)說“不知道”而不是硬編。適合正在做企業(yè)知識庫、客服助手、文檔問答這類場景的開發(fā)者參考無論你是剛接觸Spring AI還是已經(jīng)跑通過基礎(chǔ)RAG鏈路都能從引用鏈路的實(shí)現(xiàn)細(xì)節(jié)里拿到可復(fù)用的東西。2. 引用機(jī)制的技術(shù)底座從向量召回 to 可溯源輸出2.1 RAG的“檢索-生成”兩段式結(jié)構(gòu)里引用信息在哪一環(huán)丟失先把鏈路拆開看。一個(gè)標(biāo)準(zhǔn)RAG流程大致是文檔加載 → 文本切分 → 向量化 → 存入向量庫 → 用戶提問向量化 → 相似度檢索 → 召回片段拼入Prompt → 大模型生成回答。引用信息天然存在于“召回片段”這一步——每個(gè)片段都帶著元數(shù)據(jù)來源文件、頁碼、段落序號。但在“拼入Prompt”和“生成回答”這兩步之間元數(shù)據(jù)往往被丟掉了。原因很直接傳統(tǒng)做法是把召回片段的純文本拼接成一個(gè)長字符串塞給模型模型看到的只是一堆沒有身份標(biāo)識的文字。它生成回答時(shí)自然無法告訴你“這句話來自片段3”。要解決這個(gè)問題必須在Prompt構(gòu)造階段就給每個(gè)片段打上可識別的標(biāo)記并在輸出解析階段把標(biāo)記還原成引用。2.2 Spring AI的Document結(jié)構(gòu)與元數(shù)據(jù)承載能力Spring AI對RAG的支持體現(xiàn)在它的Document抽象上。一個(gè)Document對象不僅包含文本內(nèi)容還包含一個(gè)MapString, Object類型的元數(shù)據(jù)容器。這個(gè)設(shè)計(jì)是引用機(jī)制的基石——你可以在文檔加載階段就把來源信息寫進(jìn)元數(shù)據(jù)比如Document doc new Document( chunkText, Map.of( source, 員工手冊_v3.pdf, page, 12, chunkIndex, 5, section, 差旅報(bào)銷 ) );向量化時(shí)Spring AI的VectorStore會把文本轉(zhuǎn)向量存儲同時(shí)保留元數(shù)據(jù)。檢索時(shí)返回的Document列表里元數(shù)據(jù)是完整帶回來的。這意味著引用所需的一切信息在檢索環(huán)節(jié)就已經(jīng)就緒關(guān)鍵是怎么把它傳遞到最終輸出。2.3 讓模型“學(xué)會引用”的Prompt工程要點(diǎn)模型不會天生就懂“引用”這件事你得在Prompt里明確教它。我的做法是在系統(tǒng)提示詞里定義一套引用標(biāo)記規(guī)范比如要求模型在每句結(jié)論后面用[來源:片段編號]的格式標(biāo)注。同時(shí)把召回片段按編號排列每個(gè)片段前加上【片段1】這樣的標(biāo)識。這里有個(gè)容易踩的坑片段編號和元數(shù)據(jù)的映射關(guān)系必須由程序維護(hù)不能讓模型自己編。模型只負(fù)責(zé)在回答里寫[來源:1]程序拿到回答后根據(jù)編號去查對應(yīng)的Document元數(shù)據(jù)渲染成真實(shí)的文件名和頁碼。如果讓模型直接輸出文件名它極有可能記錯或編造。提示Prompt里要明確告訴模型“如果召回片段中沒有相關(guān)信息直接回答‘根據(jù)現(xiàn)有資料無法回答’不要編造”。這句話對抑制幻覺的作用比任何后處理都大。2.4 引用粒度句子級、段落級還是文檔級引用粒度直接決定實(shí)現(xiàn)復(fù)雜度和用戶體驗(yàn)。文檔級引用實(shí)現(xiàn)最簡單但用戶還得自己去文檔里翻段落級是折中方案能定位到具體章節(jié)句子級最精確但要求模型在生成時(shí)逐句標(biāo)注對模型指令遵循能力要求高且容易因?yàn)闃?biāo)注過密影響可讀性。我的建議是段落級為主、句子級為輔對于關(guān)鍵結(jié)論數(shù)字、條款、定義要求句子級引用對于綜述性描述允許段落級引用。在Prompt里可以這樣區(qū)分“涉及具體數(shù)據(jù)或條款時(shí)必須在句末標(biāo)注來源一般性總結(jié)可在段末統(tǒng)一標(biāo)注?！?. 用Spring AI搭一條可溯源的問答鏈路3.1 文檔入庫階段就把“出處”焊死很多人做RAG時(shí)文檔切分完只存文本元數(shù)據(jù)隨手填個(gè)文件名了事。等到要做引用時(shí)才發(fā)現(xiàn)信息不夠。我的經(jīng)驗(yàn)是入庫時(shí)多花十分鐘補(bǔ)元數(shù)據(jù)后面省十小時(shí)排查。具體做法是在DocumentReader和TextSplitter之間加一層元數(shù)據(jù)注入。以PDF為例用PagePdfDocumentReader讀取時(shí)每頁會生成一個(gè)Document此時(shí)就可以把頁碼寫進(jìn)元數(shù)據(jù)。切分時(shí)Spring AI的TokenTextSplitter會保留原文檔的元數(shù)據(jù)并附加chunk序號。代碼大致如下ListDocument rawDocs new PagePdfDocumentReader(resource).get(); ListDocument enriched rawDocs.stream().map(doc - { MapString, Object meta new HashMap(doc.getMetadata()); meta.put(source, fileName); meta.put(ingestedAt, Instant.now().toString()); return new Document(doc.getContent(), meta); }).toList(); TokenTextSplitter splitter new TokenTextSplitter(500, 100, 5, 10000, true); ListDocument chunks splitter.apply(enriched); vectorStore.add(chunks);注意TokenTextSplitter的構(gòu)造參數(shù)第一個(gè)是目標(biāo)chunk大小token數(shù)第二個(gè)是重疊量。重疊量設(shè)得太小會導(dǎo)致跨段落的語義被切斷引用時(shí)出現(xiàn)“半句話”的情況設(shè)得太大又會讓召回片段冗余。我實(shí)測下來500/100這個(gè)組合對中文技術(shù)文檔比較友好。3.2 檢索環(huán)節(jié)的元數(shù)據(jù)保留與重排序檢索本身用VectorStore.similaritySearch就能跑通但要做引用得關(guān)注返回的Document里元數(shù)據(jù)是否完整。Spring AI默認(rèn)會保留但如果你用了自定義的EmbeddingModel或后處理邏輯要確認(rèn)元數(shù)據(jù)沒被剝離。另一個(gè)提升引用準(zhǔn)確率的技巧是加一層重排序。向量相似度召回有時(shí)會把語義相近但來源不相關(guān)的片段排前面導(dǎo)致引用錯位?？梢栽谡倩豑op-10后用一個(gè)輕量級的交叉編碼器或簡單的關(guān)鍵詞匹配做二次排序把真正包含答案的片段頂上來。Spring AI目前沒有內(nèi)置重排序組件但可以自己實(shí)現(xiàn)一個(gè)DocumentPostProcessor接口在檢索后、拼Prompt前介入。public class KeywordBoostPostProcessor implements DocumentPostProcessor { Override public ListDocument process(ListDocument documents, String query) { // 對包含query關(guān)鍵詞的片段加權(quán) return documents.stream() .sorted((a, b) - Double.compare( score(b, query), score(a, query))) .limit(5) .toList(); } }3.3 Prompt模板里怎么安放引用標(biāo)記Prompt模板是引用機(jī)制的“合同”。我用的模板結(jié)構(gòu)是這樣的你是一個(gè)嚴(yán)謹(jǐn)?shù)膯柎鹬帧Ｕ垉H根據(jù)以下參考資料回答問題。 參考資料 【片段1】{片段1內(nèi)容} 【片段2】{片段2內(nèi)容} ... 回答要求 1. 每個(gè)具體結(jié)論后必須標(biāo)注來源格式為[來源:片段編號] 2. 如果參考資料中沒有相關(guān)信息回答“根據(jù)現(xiàn)有資料無法回答該問題” 3. 不要編造任何未在參考資料中出現(xiàn)的信息 問題{用戶問題}這里的關(guān)鍵是片段編號從1開始連續(xù)排列且程序里維護(hù)一個(gè)MapInteger, Document的映射。模型輸出[來源:2]后程序查映射表拿到片段2的元數(shù)據(jù)渲染成[員工手冊_v3.pdf 第12頁]這樣的可讀引用。3.4 輸出解析把[來源:1]還原成可點(diǎn)擊的引用模型返回的原始文本里帶著[來源:1]標(biāo)記需要用一個(gè)解析器把它替換成真實(shí)引用。我用正則匹配\[來源:(\d)\]然后查映射表替換。如果同一個(gè)片段被多次引用可以合并顯示。public String renderCitations(String rawAnswer, MapInteger, Document chunkMap) { Pattern pattern Pattern.compile(\\[來源:(\\d)\\]); Matcher matcher pattern.matcher(rawAnswer); StringBuilder sb new StringBuilder(); while (matcher.find()) { int idx Integer.parseInt(matcher.group(1)); Document doc chunkMap.get(idx); String citation doc ! null ? [ doc.getMetadata().get(source) 第 doc.getMetadata().get(page) 頁] : [來源未知]; matcher.appendReplacement(sb, citation); } matcher.appendTail(sb); return sb.toString(); }前端拿到渲染后的文本可以把引用部分做成可點(diǎn)擊的鏈接或懸浮卡片展示片段原文。這樣用戶既能看答案又能一鍵核對出處。4. 實(shí)測中暴露的五個(gè)坑與對應(yīng)解法4.1 模型不按格式標(biāo)注引用怎么辦這是最常見的問題。即使Prompt里寫了要求模型有時(shí)還是會漏標(biāo)或標(biāo)錯格式。我的解法是雙保險(xiǎn)一是在Prompt里用few-shot示例強(qiáng)化格式給一兩個(gè)“問題-帶引用回答”的樣例二是在輸出解析時(shí)做容錯如果整段回答沒有任何引用標(biāo)記就在末尾追加一句“本回答未標(biāo)注具體來源請謹(jǐn)慎參考”同時(shí)記錄日志用于后續(xù)優(yōu)化。如果漏標(biāo)率持續(xù)偏高可以考慮換指令遵循能力更強(qiáng)的模型或者降低單次召回片段數(shù)量——片段太多時(shí)模型容易“顧此失彼”。4.2 召回片段本身不相關(guān)引用就成了“偽證”引用機(jī)制有個(gè)前提召回的片段確實(shí)包含答案。如果檢索環(huán)節(jié)拉胯模型要么硬編要么引用一個(gè)不相關(guān)的片段后者更危險(xiǎn)——因?yàn)樗雌饋怼坝谐鎏帯睂?shí)則誤導(dǎo)。所以引用機(jī)制必須和檢索質(zhì)量一起優(yōu)化。我的做法是加一個(gè)相關(guān)性閾值向量相似度低于某個(gè)值的片段直接丟棄不進(jìn)入Prompt。閾值需要根據(jù)你的embedding模型和語料特點(diǎn)調(diào)一般從0.7開始試。另外對于“根據(jù)現(xiàn)有資料無法回答”的情況要在前端明確區(qū)分展示不要和正?；卮鸹煸谝黄?。4.3 中文文檔切分導(dǎo)致的引用錯位中文沒有天然的空格分隔按token切分時(shí)容易出現(xiàn)“斷句”問題。比如一個(gè)完整的條款被切成兩半召回時(shí)只命中后半段引用顯示出來就是半句話。解法是在切分時(shí)優(yōu)先按段落和標(biāo)題切Spring AI的TokenTextSplitter支持按字符切分可以配合自定義的TextSplitter先按\n\n分段再對超長段落做token切分。另外中文的標(biāo)點(diǎn)符號。應(yīng)該作為切分的優(yōu)先邊界。我寫過一個(gè)簡單的后處理器在token切分后檢查chunk末尾是否是完整句子不是的話把最后一個(gè)標(biāo)點(diǎn)之后的內(nèi)容挪到下一個(gè)chunk。4.4 多文檔來源時(shí)的引用去重與合并當(dāng)知識庫里有多個(gè)版本文檔時(shí)同一個(gè)問題可能召回來自不同文檔的相似片段。如果模型分別引用了片段1和片段3而這兩個(gè)片段其實(shí)來自同一份文檔的相鄰頁引用顯示就會冗余?？梢栽阡秩倦A段做合并如果兩個(gè)引用的source相同且頁碼相鄰合并成“第12-13頁”。更復(fù)雜的情況是同一事實(shí)在不同文檔中有不同表述這時(shí)引用反而要保留多個(gè)來源讓用戶看到差異。判斷邏輯可以交給模型在Prompt里要求“如果多個(gè)片段對同一問題有不同說法請分別列出并標(biāo)注各自來源”。4.5 引用帶來的Token開銷與性能權(quán)衡把片段編號、引用標(biāo)記、元數(shù)據(jù)都塞進(jìn)Prompt和輸出會顯著增加token消耗。實(shí)測下來帶引用要求的Prompt比普通RAG Prompt長約30%-40%輸出也長20%左右。對于高頻調(diào)用的場景這個(gè)成本不能忽略。優(yōu)化方向有三個(gè)一是只對關(guān)鍵結(jié)論要求引用綜述性內(nèi)容不強(qiáng)制二是壓縮片段內(nèi)容召回后先用一個(gè)小模型做摘要再拼入Prompt三是緩存映射關(guān)系避免每次請求都重建MapInteger, Document。如果用的是按token計(jì)費(fèi)的API建議先算一筆賬假設(shè)每次多消耗500 token日調(diào)用1萬次一個(gè)月就是1.5億token的增量值不值得取決于業(yè)務(wù)對可信度的要求。5. 讓“不知道”成為一等公民拒答策略的設(shè)計(jì)5.1 為什么拒答比胡答更難做好讓模型說“我不知道”聽起來簡單做起來難。模型的默認(rèn)行為是“盡力回答”哪怕信息不足也會編一個(gè)看似合理的答案。要讓它老實(shí)拒答需要在Prompt、檢索閾值、輸出校驗(yàn)三個(gè)層面同時(shí)施壓。Prompt層面已經(jīng)說了要明確寫“沒有相關(guān)信息就拒答”。但這還不夠因?yàn)槟Ｐ蛯Α皼]有相關(guān)信息”的判斷標(biāo)準(zhǔn)很模糊。更可靠的做法是在檢索層面就做判斷如果Top-1片段的相似度低于閾值直接不走生成返回預(yù)設(shè)的拒答話術(shù)。這樣既省token又避免模型“強(qiáng)行發(fā)揮”。5.2 檢索置信度閾值怎么定閾值定高了很多能回答的問題被拒定低了不該答的也答了。我的經(jīng)驗(yàn)是分場景設(shè)閾值事實(shí)型問題數(shù)字、日期、條款閾值設(shè)高一些比如0.75開放型問題解釋、總結(jié)可以低一些比如0.6。另外可以結(jié)合召回片段的數(shù)量做判斷如果Top-3片段的相似度都低于0.65基本可以判定知識庫覆蓋不到。這個(gè)閾值不是拍腦袋定的要用一批標(biāo)注好的測試問題跑一遍畫一條“閾值-準(zhǔn)確率/拒答率”曲線找平衡點(diǎn)。我一般會準(zhǔn)備50-100個(gè)測試問題其中一半是知識庫能覆蓋的一半是不能覆蓋的用來自動化調(diào)參。5.3 拒答話術(shù)的設(shè)計(jì)與用戶體驗(yàn)拒答不是冷冰冰地說“不知道”就完事。好的拒答應(yīng)該告訴用戶為什么答不了、可以怎么調(diào)整。比如“根據(jù)現(xiàn)有資料無法回答該問題建議補(bǔ)充相關(guān)文檔或換個(gè)問法”。如果檢索到了一些弱相關(guān)片段可以附上“你可能想了解”的推薦把弱相關(guān)片段作為參考列出但不作為答案。前端展示上拒答回答要用不同的視覺樣式比如灰色背景、提示圖標(biāo)和正?；卮饏^(qū)分開避免用戶誤以為這是正式答案。6. 從能用到好用引用體驗(yàn)的進(jìn)階優(yōu)化6.1 引用懸浮預(yù)覽與原文高亮基礎(chǔ)版引用只是文本標(biāo)注進(jìn)階版應(yīng)該支持懸浮預(yù)覽鼠標(biāo)移到引用上彈出片段原文并把命中的關(guān)鍵詞高亮。這需要前端配合但后端要把片段原文和命中位置一起返回。實(shí)現(xiàn)方式是在渲染引用時(shí)除了返回文件名和頁碼再附帶片段文本和query關(guān)鍵詞的位置信息。6.2 多輪對話中的引用繼承多輪對話里用戶追問“那第二條呢”系統(tǒng)需要知道“第二條”指的是上一輪引用的文檔里的第二條。這要求對話狀態(tài)里保存上一輪的引用上下文。Spring AI的ChatMemory可以存對話歷史但引用映射需要額外維護(hù)。我的做法是在ChatMemory之外再掛一個(gè)CitationContext記錄每輪回答的引用片段ID追問時(shí)把相關(guān)片段重新召回或直接從上下文取。6.3 引用準(zhǔn)確率的自動化評估上線后怎么知道引用準(zhǔn)不準(zhǔn)人工抽查成本太高?？梢宰鲆粋€(gè)自動化評估腳本用一批測試問題跑完RAG鏈路后用另一個(gè)模型判斷“回答中的每個(gè)引用是否真的支持對應(yīng)結(jié)論”。雖然這個(gè)判斷本身也有誤差但能篩出明顯錯位的引用作為優(yōu)化線索。評估指標(biāo)可以定兩個(gè)引用覆蓋率有引用的結(jié)論占比和引用準(zhǔn)確率引用正確的占比。前者低說明模型不愛標(biāo)注后者低說明檢索或映射有問題。兩個(gè)指標(biāo)一起看能快速定位問題環(huán)節(jié)。7. 一些個(gè)人實(shí)踐中的體會這套帶引用的RAG方案我在幾個(gè)內(nèi)部知識庫場景里跑過最大的感受是引用機(jī)制的價(jià)值不只是“可信”更是“可調(diào)試”。以前模型答錯了你只能猜是檢索問題還是生成問題有了引用一眼就能看出是召回片段不對還是模型沒按片段說。排查效率提升非常明顯。另一個(gè)體會是不要追求100%的引用覆蓋率。有些綜述性、過渡性的句子本來就不需要引用強(qiáng)行標(biāo)注反而讓回答變得支離破碎。把精力放在關(guān)鍵結(jié)論的引用準(zhǔn)確性上比追求形式上的“句句有出處”更有價(jià)值。最后分享一個(gè)小技巧在Prompt里給模型一個(gè)“引用示例”比單純描述格式要求有效得多。我通常會在系統(tǒng)提示詞里放一個(gè)完整的問答示例展示“問題-召回片段-帶引用回答”的全過程模型模仿這個(gè)示例的格式準(zhǔn)確率能到90%以上。這個(gè)示例不用長兩三句話就夠但一定要包含引用標(biāo)記的正確位置和格式。