這篇不先堆名詞。我們把《GraphRAG實(shí)戰(zhàn)真正難的不是調(diào)用而是穩(wěn)定交付》拆成幾級臺階看完至少知道下一步該學(xué)什么、該練什么。摘要之前幫一個做企業(yè)知識庫的客戶做技術(shù)選型對方業(yè)務(wù)方提需求時特別干脆我們要一個能理解復(fù)雜關(guān)系的問答系統(tǒng)傳統(tǒng)RAG搞不定得上GraphRAG。 聽起來很合理對吧知識圖譜RAG這組合在論文和Demo里確實(shí)好看。但問題出在后面。Demo跑通后他們發(fā)現(xiàn)兩個事情一是權(quán)限控制根本無從下手圖譜里的實(shí)體關(guān)系沒有清晰的訪問邊界二是日志幾乎沒法用一次查詢可能涉及圖譜遍歷、向量檢索、LLM調(diào)用出了問題根本定位不到。這讓我重新思考一個問題GraphRAG真正難的不是調(diào)用圖譜和RAG而是上線后的穩(wěn)定性和可觀測性。今天這篇我不講怎么搭GraphRAG因?yàn)榫W(wǎng)上一搜一大堆。我想講的是從Demo到生產(chǎn)你們會碰到哪些真正的問題以及怎么判斷自己該不該上GraphRAG。---目錄傳統(tǒng)RAG的瓶頸為什么業(yè)務(wù)方會想要GraphRAG知識圖譜建模別一上來就搞復(fù)雜schema實(shí)體關(guān)系抽取質(zhì)量比數(shù)量重要圖檢索增強(qiáng)不是所有查詢都要走圖譜評估與優(yōu)化Demo和生產(chǎn)的差距權(quán)限、日志和可觀測Demo和生產(chǎn)的真正差距總結(jié)GraphRAG不是銀彈工程化才是傳統(tǒng)RAG的瓶頸為什么業(yè)務(wù)方會想要GraphRAG我們先說清楚什么情況下傳統(tǒng)RAG不夠用。我見過最常見的場景是多跳問答。比如 張總負(fù)責(zé)的項(xiàng)目里有哪些供應(yīng)商的合同還在執(zhí)行期傳統(tǒng)RAG的做法是把這個問題切片分別去檢索張總、項(xiàng)目、供應(yīng)商、合同執(zhí)行期然后拼答案。問題在于這種切分完全丟失了實(shí)體之間的關(guān)系。另一種場景是一致性校驗(yàn)。比如知識庫里有兩份文檔一份說某產(chǎn)品2024年Q1上線另一份說2024年Q2上線傳統(tǒng)RAG沒有能力發(fā)現(xiàn)這個矛盾而知識圖譜可以通過實(shí)體關(guān)系直接比對。還有一類是全局視圖需求。比如我們目前有哪些AI相關(guān)的項(xiàng)目每個項(xiàng)目用了什么模型模型之間有沒有重疊這種問題需要跨文檔的全局理解傳統(tǒng)RAG做不到。但這里我要潑一盆冷水不是所有復(fù)雜問題都需要GraphRAG。很多團(tuán)隊(duì)上GraphRAG的原因是聽說這個更厲害而不是真的遇到了傳統(tǒng)RAG解決不了的問題。我的判斷標(biāo)準(zhǔn)很簡單——如果你的問題只需要單文檔檢索就能回答別折騰GraphRAG。---知識圖譜建模別一上來就搞復(fù)雜schema這是很多團(tuán)隊(duì)踩的第一個坑。業(yè)務(wù)方一提需求技術(shù)團(tuán)隊(duì)就開始設(shè)計本體、定義關(guān)系類型、規(guī)劃實(shí)體層次。我見過一個團(tuán)隊(duì)光schema設(shè)計就開了三周會最后做出來的圖譜結(jié)構(gòu)復(fù)雜到維護(hù)成本極高。我的建議是先做最小可行圖譜MVP Graph再迭代。具體來說從一個場景出發(fā)。比如你們最核心的需求是多跳問答那就只抽取和這個需求相關(guān)的實(shí)體和關(guān)系。假設(shè)你們做的是客戶咨詢系統(tǒng)那核心實(shí)體可能就是客戶、產(chǎn)品、合同、項(xiàng)目核心關(guān)系就是購買、簽約、負(fù)責(zé)。# 最小可行圖譜的實(shí)體關(guān)系定義 from pydantic import BaseModel from typing import Optional class Entity(BaseModel): type: str # 實(shí)體類型客戶、產(chǎn)品、合同、項(xiàng)目 name: str # 實(shí)體名稱 properties: dict {} # 屬性比如合同開始時間、結(jié)束時間 class Relation(BaseModel): source: str # 源實(shí)體名稱 relation_type: str # 關(guān)系類型購買、簽約、負(fù)責(zé) target: str # 目標(biāo)實(shí)體名稱 properties: dict {} # 關(guān)系屬性比如合同金額、執(zhí)行狀態(tài)這個schema很簡單但它能覆蓋你們80%的場景。剩下的20%等真的遇到問題再擴(kuò)展。另一個常見的錯誤是過度抽取關(guān)系。有些團(tuán)隊(duì)恨不得把文檔里所有可能的關(guān)系都抽出來結(jié)果圖譜變得極其稀疏質(zhì)量反而下降。我的建議是只抽取和業(yè)務(wù)強(qiáng)相關(guān)的關(guān)系其他的交給向量檢索來處理。---實(shí)體關(guān)系抽取質(zhì)量比數(shù)量重要抽取環(huán)節(jié)是GraphRAG里最容易翻車的地方。我之前帶過一個項(xiàng)目用了開源的NER模型做實(shí)體識別效果看著不錯F1分?jǐn)?shù)很高。但一上線業(yè)務(wù)方反饋張總被識別成了人名實(shí)際上在你們公司里張總是一個職位對應(yīng)的是具體的某個人。這個問題在通用模型里幾乎不可能解決因?yàn)閺埧傔@種稱謂完全依賴業(yè)務(wù)語境。我的做法是在抽取環(huán)節(jié)加一層業(yè)務(wù)規(guī)則過濾# 業(yè)務(wù)規(guī)則過濾示例 BUSINESS_RULES { title_patterns: [ r^(張|李|王|劉|陳).{1,2}總$, # 職位稱謂 r^(張|李|王|劉|陳).{1,2}經(jīng)理$, ], entity_mappings: { 張總: 張偉, # 映射到具體人名 李總: 李明, } } import re def apply_business_rules(text: str, entities: list) - list: 應(yīng)用業(yè)務(wù)規(guī)則過濾實(shí)體 filtered [] for entity in entities: matched False for pattern in BUSINESS_RULES[title_patterns]: if re.match(pattern, entity[name]): # 映射到具體實(shí)體 mapped_name BUSINESS_RULES[entity_mappings].get( entity[name], entity[name] ) filtered.append({ **entity, name: mapped_name, type: person # 統(tǒng)一映射為人名 }) matched True break if not matched: filtered.append(entity) return filtered這個例子很簡單但思路很重要通用模型做通用抽取業(yè)務(wù)規(guī)則做精準(zhǔn)修正。另一個建議是先做小規(guī)模驗(yàn)證再大規(guī)模抽取。不要一次性抽取整個知識庫先拿10-20個核心文檔測試抽取效果確認(rèn)質(zhì)量后再擴(kuò)展。我見過有人直接抽幾萬份文檔結(jié)果發(fā)現(xiàn)抽取質(zhì)量很差全部返工。---圖檢索增強(qiáng)不是所有查詢都要走圖譜這是很多GraphRAG實(shí)現(xiàn)里最容易被忽略的一點(diǎn)混合檢索策略。不是每個查詢都需要走圖譜遍歷。比如用戶問你們的產(chǎn)品有哪些功能這種問題用傳統(tǒng)向量檢索就夠了走圖譜反而會增加延遲和復(fù)雜度。我的建議是設(shè)計一個查詢路由層根據(jù)查詢類型決定走哪條路from enum import Enum from typing import Literal class QueryType(Enum): SIMPLE_RETRIEVAL simple # 簡單檢索走向量 MULTI_HOP multi_hop # 多跳查詢走圖譜 CONSISTENCY_CHECK consistency # 一致性校驗(yàn)走圖譜 GLOBAL_VIEW global_view # 全局視圖走圖譜 def classify_query(query: str) - QueryType: 簡單的查詢分類實(shí)際項(xiàng)目可以用LLM做 multi_hop_keywords [負(fù)責(zé), 關(guān)聯(lián), 哪些, 之間, 通過] consistency_keywords [矛盾, 沖突, 不一致, 差異] global_view_keywords [全部, 所有, 有哪些, 全局] for kw in multi_hop_keywords: if kw in query: return QueryType.MULTI_HOP for kw in consistency_keywords: if kw in query: return QueryType.CONSISTENCY_CHECK for kw in global_view_keywords: if kw in query: return QueryType.GLOBAL_VIEW return QueryType.SIMPLE_RETRIEVAL def route_query(query: str, query_type: QueryType): if query_type QueryType.SIMPLE_RETRIEVAL: return vector_search(query) elif query_type in [QueryType.MULTI_HOP, QueryType.CONSISTENCY_CHECK, QueryType.GLOBAL_VIEW]: return graph_search(query) else: # 兜底策略 return hybrid_search(query)這個路由層的設(shè)計還有一個好處便于日志和可觀測。 你知道每次查詢走了哪條路出了問題可以快速定位。---評估與優(yōu)化Demo和生產(chǎn)的差距GraphRAG的評估比傳統(tǒng)RAG復(fù)雜得多。傳統(tǒng)RAG主要看檢索準(zhǔn)確率和生成質(zhì)量GraphRAG還要考慮圖譜質(zhì)量、關(guān)系抽取準(zhǔn)確率、多跳推理的正確率。我的建議是建立一個分層評估體系1. 圖譜質(zhì)量層實(shí)體識別準(zhǔn)確率、關(guān)系抽取準(zhǔn)確率、圖譜覆蓋率2. 檢索層單跳檢索準(zhǔn)確率、多跳檢索準(zhǔn)確率3. 生成層答案準(zhǔn)確性、答案完整性、答案一致性具體做法是構(gòu)建一個黃金測試集包含100-200個真實(shí)業(yè)務(wù)問題每個問題都有標(biāo)準(zhǔn)答案。每次模型或圖譜更新后跑一遍測試集看指標(biāo)變化。# 評估指標(biāo)計算 def evaluate_graphrag(golden_set: list, predictions: list) - dict: 計算GraphRAG評估指標(biāo) metrics { entity_recall: 0.0, relation_precision: 0.0, answer_accuracy: 0.0, multi_hop_accuracy: 0.0 } correct_entities 0 correct_relations 0 total_entities 0 total_relations 0 correct_answers 0 correct_multi_hop 0 total_multi_hop 0 for gold, pred in zip(golden_set, predictions): # 實(shí)體識別評估 total_entities len(gold[entities]) correct_entities len(set(gold[entities]) set(pred[entities])) # 關(guān)系抽取評估 total_relations len(gold[relations]) correct_relations len(set(gold[relations]) set(pred[relations])) # 答案準(zhǔn)確性評估 if gold[answer] pred[answer]: correct_answers 1 # 多跳問題評估 if gold.get(is_multi_hop): total_multi_hop 1 if gold[answer] pred[answer]: correct_multi_hop 1 metrics[entity_recall] correct_entities / max(total_entities, 1) metrics[relation_precision] correct_relations / max(total_relations, 1) metrics[answer_accuracy] correct_answers / len(golden_set) metrics[multi_hop_accuracy] correct_multi_hop / max(total_multi_hop, 1) return metrics這里我想強(qiáng)調(diào)一點(diǎn)不要只看整體準(zhǔn)確率要分場景看。 多跳問題的準(zhǔn)確率可能只有60%但簡單檢索問題的準(zhǔn)確率有90%。如果業(yè)務(wù)方只關(guān)心多跳問題那60%可能就夠了如果關(guān)心所有問題那就要看整體。---權(quán)限、日志和可觀測Demo和生產(chǎn)的真正差距回到開頭那個問題為什么GraphRAG Demo能跑上線就崩我認(rèn)為核心原因不是技術(shù)而是工程化能力。具體來說有三個關(guān)鍵點(diǎn)第一權(quán)限控制要貫穿整個鏈路。GraphRAG的權(quán)限控制比傳統(tǒng)RAG復(fù)雜因?yàn)槟阋瑫r控制文檔級別的權(quán)限和圖譜實(shí)體的權(quán)限。比如某個供應(yīng)商的合同信息只有采購部門能看但供應(yīng)商的名稱可能出現(xiàn)在多個文檔里你不能因?yàn)槟硞€文檔可見就把整個實(shí)體暴露出去。我的做法是在圖譜查詢層加一個權(quán)限過濾中間件class PermissionMiddleware: 權(quán)限過濾中間件 def __init__(self, graph_db, permission_service): self.graph graph_db self.perm permission_service def query(self, user_id: str, query: str) - list: 查詢前過濾不可見實(shí)體 # 獲取用戶可見的實(shí)體ID集合 visible_entities self.perm.get_visible_entities(user_id) # 在圖譜查詢中加入權(quán)限過濾 results self.graph.query( query, filters{entity_id: list(visible_entities)} ) return results第二日志要覆蓋完整鏈路。一次GraphRAG查詢可能涉及查詢路由、向量檢索、圖譜遍歷、LLM調(diào)用。如果出了問題你需要知道每一步的耗時、輸入輸出、錯誤信息。建議的日志結(jié)構(gòu)import time import logging logger logging.getLogger(graphrag) def trace_query(query: str, user_id: str): 查詢追蹤 trace_id generate_trace_id() start_time time.time() logger.info({ trace_id: trace_id, event: query_start, user_id: user_id, query: query, timestamp: start_time }) try: # 路由 query_type classify_query(query) logger.info({ trace_id: trace_id, event: query_routed, query_type: query_type.value }) # 執(zhí)行 if query_type QueryType.SIMPLE_RETRIEVAL: result vector_search(query) else: result graph_search(query) # 生成 answer llm_generate(result, query) elapsed time.time() - start_time logger.info({ trace_id: trace_id, event: query_complete, elapsed_ms: elapsed * 1000, answer_length: len(answer) }) return answer except Exception as e: elapsed time.time() - start_time logger.error({ trace_id: trace_id, event: query_error, error: str(e), elapsed_ms: elapsed * 1000 }) raise有了這個日志結(jié)構(gòu)出問題的時候你可以按trace_id追蹤完整鏈路快速定位是哪一步出了問題。第三可觀測性要量化。除了日志還需要一些關(guān)鍵的監(jiān)控指標(biāo)查詢P99延遲分路由類型圖譜查詢失敗率LLM調(diào)用失敗率權(quán)限過濾后的結(jié)果召回率多跳查詢的平均跳數(shù)這些指標(biāo)能幫你快速發(fā)現(xiàn)性能瓶頸和問題模式。---總結(jié)GraphRAG不是銀彈工程化才是寫到這里我想回到最初的問題什么時候該用GraphRAG我的判斷標(biāo)準(zhǔn)1. 你的問題需要多跳推理傳統(tǒng)RAG經(jīng)常答不對2. 你的數(shù)據(jù)有強(qiáng)結(jié)構(gòu)關(guān)系適合用圖譜表達(dá)3. 你有足夠的工程能力能處理權(quán)限、日志和可觀測性如果以上三點(diǎn)只滿足前兩點(diǎn)我建議先上傳統(tǒng)RAG把權(quán)限日志做扎實(shí)等真的遇到瓶頸再考慮GraphRAG。最后說一個真實(shí)案例。我之前幫一個金融客戶做GraphRAG他們的核心需求是關(guān)聯(lián)交易識別——判斷兩家公司之間是否存在關(guān)聯(lián)關(guān)系。這個問題傳統(tǒng)RAG完全搞不定必須用圖譜。但他們上線后第一個月故障率很高。原因不是圖譜質(zhì)量差而是權(quán)限控制沒做好導(dǎo)致部分敏感實(shí)體被錯誤暴露觸發(fā)了合規(guī)警報。第二個問題是無日志追蹤出問題后完全定位不到原因運(yùn)維團(tuán)隊(duì)花了三天才找到問題所在。這兩個問題都不是技術(shù)難題而是工程化問題。如果他們在Demo階段就把權(quán)限和日志考慮進(jìn)去后面的路會順很多。所以我的建議是別急著上GraphRAG先把權(quán)限、日志和可觀測性這塊補(bǔ)齊。 這才是從Demo到生產(chǎn)真正需要跨過的坎。資料展示下面是我整理的AI大模型學(xué)習(xí)資料和工具包預(yù)覽適合收藏后按主題逐步學(xué)習(xí)。如果你想看完整資料目錄可以在評論區(qū)留言「資料」也歡迎告訴我你更關(guān)注AI大模型里的哪類內(nèi)容。