05篇講高級(jí)RAG架構(gòu)時(shí)GraphRAG只占了一小節(jié)——當(dāng)時(shí)受限于篇幅只給了LlamaIndex的基本用法。但GraphRAG是2024-2025年RAG領(lǐng)域最重要的突破之一微軟開(kāi)源的GraphRAG項(xiàng)目已經(jīng)拿了2萬(wàn)多star值得專(zhuān)門(mén)一篇拆透。你可能會(huì)問(wèn)向量檢索已經(jīng)夠用了為什么要搞知識(shí)圖譜我舉個(gè)真實(shí)場(chǎng)景公司有500份文檔用戶(hù)問(wèn)我們公司所有產(chǎn)品線之間的技術(shù)依賴(lài)關(guān)系是什么。向量檢索能做的是找到跟產(chǎn)品線和技術(shù)依賴(lài)語(yǔ)義相似的文檔片段。但這些片段是分散的——產(chǎn)品A用了技術(shù)X產(chǎn)品B依賴(lài)產(chǎn)品A產(chǎn)品C集成了產(chǎn)品B——這些跨文檔的實(shí)體關(guān)聯(lián)向量檢索根本串不起來(lái)。GraphRAG的思路先從文檔里抽取實(shí)體和關(guān)系構(gòu)建知識(shí)圖譜然后用圖的結(jié)構(gòu)化信息做檢索。向量檢索找的是像不像GraphRAG找的是有沒(méi)有關(guān)系。這篇把GraphRAG從原理到實(shí)現(xiàn)拆透實(shí)體抽取→關(guān)系構(gòu)建→社區(qū)檢測(cè)→全局/局部檢索→工程落地。GraphRAG vs 向量RAG什么時(shí)候該換方案先搞清楚一個(gè)問(wèn)題不是所有場(chǎng)景都需要GraphRAG。維度向量RAGGraphRAG擅長(zhǎng)的問(wèn)題“X是什么”、“怎么做X”“X和Y什么關(guān)系”、“整體趨勢(shì)是什么”檢索粒度文本片段chunk實(shí)體關(guān)系社區(qū)摘要全局性問(wèn)題差只能找局部相似片段強(qiáng)圖結(jié)構(gòu)天然支持全局推理多跳推理靠迭代檢索容易丟線索圖遍歷一次到位建索引成本低切分Embedding高LLM抽取實(shí)體關(guān)系索引耗時(shí)500篇文檔約5分鐘500篇文檔約30-60分鐘索引成本Embedding API費(fèi)用LLM調(diào)用費(fèi)用抽取實(shí)體很費(fèi)token查詢(xún)延遲200-500ms500-2000ms圖遍歷社區(qū)摘要判斷標(biāo)準(zhǔn)很簡(jiǎn)單如果你的用戶(hù)經(jīng)常問(wèn)A和B什么關(guān)系、“整體情況怎么樣”、X影響了哪些東西這類(lèi)需要跨文檔關(guān)聯(lián)的問(wèn)題向量RAG搞不定就該上GraphRAG。如果用戶(hù)問(wèn)的都是退貨流程是什么這種單文檔能回答的向量RAG就夠了別折騰。GraphRAG的核心流程四步走微軟GraphRAG的流程分四個(gè)階段文檔 → ① 文本切分 → ② 實(shí)體關(guān)系抽取 → ③ 社區(qū)檢測(cè) → ④ 社區(qū)摘要 ↓查詢(xún) → 局部檢索實(shí)體關(guān)系 或 全局檢索社區(qū)摘要每個(gè)階段都有坑咱們逐個(gè)拆。階段一文本切分GraphRAG的切分和向量RAG不一樣。向量RAG追求chunk大小均勻200-500字符GraphRAG追求實(shí)體完整性——一個(gè)chunk里應(yīng)該包含完整的實(shí)體描述和關(guān)系信息。from langchain_text_splitters import RecursiveCharacterTextSplitterdef graph_rag_chunking(documents, chunk_size1200, chunk_overlap100): GraphRAG專(zhuān)用切分chunk比向量RAG大保證實(shí)體完整 微軟默認(rèn)用1200 token約1800字符比向量RAG的500字符大很多。 原因小chunk會(huì)把一個(gè)實(shí)體描述截?cái)喑槿〕龅年P(guān)系不完整。 splitter RecursiveCharacterTextSplitter( chunk_sizechunk_size, chunk_overlapchunk_overlap, separators[\n\n, \n, 。, , , ], ) chunks splitter.split_documents(documents) print(f切分完成{len(chunks)}個(gè)chunk平均長(zhǎng)度{sum(len(c.page_content) for c in chunks)//len(chunks)}字符) return chunks坑1chunk太大導(dǎo)致抽取遺漏。我一開(kāi)始用2400字符的chunk結(jié)果LLM抽取實(shí)體時(shí)只抽了前半部分的關(guān)系后半部分的實(shí)體被忽略了。原因是LLM的注意力在長(zhǎng)文本里會(huì)衰減。微軟默認(rèn)1200 token是經(jīng)驗(yàn)值別隨便改大。階段二實(shí)體和關(guān)系抽取這是GraphRAG最核心也是成本最高的一步。用LLM從每個(gè)chunk里抽取實(shí)體人名、公司名、產(chǎn)品名、技術(shù)名和關(guān)系A(chǔ)是B的CEO、A依賴(lài)B、A包含B。from langchain_core.prompts import ChatPromptTemplatefrom langchain_core.output_parsers import PydanticOutputParserfrom pydantic import BaseModel, Fieldfrom typing import Optionalclass Entity(BaseModel): 實(shí)體定義 name: str Field(description實(shí)體名稱(chēng)) type: str Field(description實(shí)體類(lèi)型PERSON/ORGANIZATION/PRODUCT/TECHNOLOGY/CONCEPT/LOCATION) description: str Field(description實(shí)體描述一句話說(shuō)明這個(gè)實(shí)體是什么)class Relationship(BaseModel): 關(guān)系定義 source: str Field(description源實(shí)體名稱(chēng)) target: str Field(description目標(biāo)實(shí)體名稱(chēng)) description: str Field(description關(guān)系描述如是CEO、依賴(lài)、包含) strength: float Field(description關(guān)系強(qiáng)度0-11表示強(qiáng)關(guān)系, default0.5)class ExtractionResult(BaseModel): 單個(gè)chunk的抽取結(jié)果 entities: list[Entity] relationships: list[Relationship]def extract_entities_relations(chunks, llm): 從每個(gè)chunk抽取實(shí)體和關(guān)系 這一步是GraphRAG成本的大頭每個(gè)chunk都要調(diào)用一次LLM。 500個(gè)chunk 500次LLM調(diào)用GPT-4o約$30-50。 parser PydanticOutputParser(pydantic_objectExtractionResult) extract_prompt ChatPromptTemplate.from_template( 你是一個(gè)信息抽取專(zhuān)家。請(qǐng)從以下文本中抽取實(shí)體和關(guān)系。抽取規(guī)則1. 實(shí)體類(lèi)型PERSON人物、ORGANIZATION組織、PRODUCT產(chǎn)品、TECHNOLOGY技術(shù)、CONCEPT概念、LOCATION地點(diǎn)2. 關(guān)系實(shí)體之間的關(guān)聯(lián)如任職于、開(kāi)發(fā)、依賴(lài)、收購(gòu)、合作等3. 每個(gè)實(shí)體必須有簡(jiǎn)短描述4. 關(guān)系強(qiáng)度明確提到0.9間接推斷0.5弱關(guān)聯(lián)0.35. 只抽取文本中明確出現(xiàn)的信息不要編造文本{text}{format_instructions} ) all_entities [] all_relationships [] for i, chunk in enumerate(chunks): chain extract_prompt | llm | parser result chain.invoke({ text: chunk.page_content, format_instructions: parser.get_format_instructions(), }) # 記錄每個(gè)實(shí)體來(lái)自哪個(gè)chunk方便后續(xù)追溯 for entity in result.entities: entity.description f (來(lái)源: chunk_{i}) all_entities.append(entity) for rel in result.relationships: all_relationships.append(rel) if (i 1) % 50 0: print(f已處理 {i1}/{len(chunks)} 個(gè)chunk累計(jì)抽取{len(all_entities)}個(gè)實(shí)體{len(all_relationships)}條關(guān)系) return all_entities, all_relationships坑2實(shí)體名稱(chēng)不統(tǒng)一。同一個(gè)張三可能被抽成張三、“張三CEO”、Zhang San三種。后面構(gòu)建圖譜時(shí)這會(huì)被當(dāng)成三個(gè)不同節(jié)點(diǎn)。解決加一層實(shí)體合并/消歧。def merge_entities(entities): 合并同名實(shí)體簡(jiǎn)單版名稱(chēng)歸一化后合并描述 entity_map {} # 歸一化名稱(chēng) → 合并后的實(shí)體 for entity in entities: # 歸一化去空格、去括號(hào)注釋、統(tǒng)一大小寫(xiě) normalized_name entity.name.strip() # 去掉括號(hào)里的注釋如 張三CEO → 張三 if in normalized_name: normalized_name normalized_name.split()[0] if ( in normalized_name: normalized_name normalized_name.split(()[0] if normalized_name in entity_map: # 已存在合并描述 entity_map[normalized_name].description | entity.description else: entity.name normalized_name entity_map[normalized_name] entity return list(entity_map.values())Java類(lèi)比實(shí)體合并就像你做用戶(hù)數(shù)據(jù)清洗——同一個(gè)用戶(hù)在三個(gè)系統(tǒng)里注冊(cè)了三個(gè)賬號(hào)你得按手機(jī)號(hào)或郵箱歸一化成一個(gè)用戶(hù)。GraphRAG的實(shí)體合并是同樣的邏輯。不合并的話圖里全是孤立節(jié)點(diǎn)跟沒(méi)有圖一樣。階段三社區(qū)檢測(cè)抽取完實(shí)體和關(guān)系后你有一個(gè)圖節(jié)點(diǎn)是實(shí)體邊是關(guān)系。但這個(gè)圖可能很大很亂——500個(gè)文檔可能抽出上萬(wàn)個(gè)實(shí)體幾萬(wàn)條關(guān)系。直接用這個(gè)圖檢索效率很低。社區(qū)檢測(cè)Community Detection把圖分成若干社區(qū)——每個(gè)社區(qū)是一組緊密關(guān)聯(lián)的實(shí)體。比如產(chǎn)品線A相關(guān)的所有人和技術(shù)可能構(gòu)成一個(gè)社區(qū)產(chǎn)品線B構(gòu)成另一個(gè)社區(qū)。GraphRAG用的是Leiden算法比Louvain更精確的社區(qū)檢測(cè)算法import networkx as nxdef build_graph_and_detect_communities(entities, relationships): 構(gòu)建圖 社區(qū)檢測(cè) # 1. 構(gòu)建NetworkX圖 graph nx.Graph() # 添加節(jié)點(diǎn) for entity in entities: graph.add_node(entity.name, typeentity.type, descriptionentity.description) # 添加邊關(guān)系強(qiáng)度作為邊權(quán)重 for rel in relationships: if graph.has_edge(rel.source, rel.target): # 已有邊取最大強(qiáng)度 graph[rel.source][rel.target][weight] max( graph[rel.source][rel.target][weight], rel.strength ) graph[rel.source][rel.target][description] | rel.description else: graph.add_edge(rel.source, rel.target, weightrel.strength, descriptionrel.description) print(f圖構(gòu)建完成{graph.number_of_nodes()}個(gè)節(jié)點(diǎn){graph.number_of_edges()}條邊) # 2. 社區(qū)檢測(cè)使用貪婪模塊度算法NetworkX內(nèi)置效果接近Leiden communities nx.community.greedy_modularity_communities(graph, weightweight) print(f社區(qū)檢測(cè)完成{len(communities)}個(gè)社區(qū)) for i, community in enumerate(communities): print(f 社區(qū){i}: {len(community)}個(gè)實(shí)體 - {list(community)[:5]}...) return graph, communities坑3社區(qū)粒度不好控制。社區(qū)太大一個(gè)社區(qū)幾百個(gè)實(shí)體摘要會(huì)丟失細(xì)節(jié)社區(qū)太小一個(gè)社區(qū)2-3個(gè)實(shí)體摘要沒(méi)什么信息量。微軟GraphRAG用分層社區(qū)——先檢測(cè)大社區(qū)再在大社區(qū)里檢測(cè)子社區(qū)構(gòu)建多層級(jí)結(jié)構(gòu)。查詢(xún)時(shí)可以根據(jù)問(wèn)題粒度選擇不同層級(jí)的社區(qū)。def build_hierarchical_communities(graph, max_levels3): 分層社區(qū)檢測(cè)每層在前一層的社區(qū)內(nèi)繼續(xù)細(xì)分 all_levels [] # 第0層全圖社區(qū)檢測(cè) communities list(nx.community.greedy_modularity_communities(graph, weightweight)) all_levels.append(communities) # 遞歸在每個(gè)社區(qū)內(nèi)繼續(xù)檢測(cè)子社區(qū) for level in range(1, max_levels): sub_communities [] for community in all_levels[-1]: if len(community) 5: # 太小的社區(qū)不再細(xì)分 sub_communities.append(community) continue subgraph graph.subgraph(community) sub_comms list(nx.community.greedy_modularity_communities(subgraph, weightweight)) sub_communities.extend(sub_comms) if len(sub_communities) len(all_levels[-1]): break # 沒(méi)有進(jìn)一步細(xì)分停止 all_levels.append(sub_communities) return all_levels階段四社區(qū)摘要每個(gè)社區(qū)生成一段LLM摘要描述這個(gè)社區(qū)包含哪些實(shí)體、它們之間的關(guān)系、整體在講什么。全局檢索時(shí)就用這些摘要。def generate_community_summaries(communities, graph, llm): 為每個(gè)社區(qū)生成摘要 summary_prompt ChatPromptTemplate.from_template( 請(qǐng)總結(jié)以下實(shí)體及其關(guān)系形成一段連貫的概述。實(shí)體和關(guān)系{graph_info}要求1. 提煉核心主題和關(guān)鍵關(guān)系2. 不要簡(jiǎn)單羅列實(shí)體要總結(jié)出這個(gè)群體在做什么3. 200字以?xún)?nèi)概述 ) summaries [] for i, community in enumerate(communities): # 收集社區(qū)內(nèi)所有實(shí)體和關(guān)系 graph_info [] for node in community: desc graph.nodes[node].get(description, ) graph_info.append(f[{node}] {desc}) # 收集社區(qū)內(nèi)部的關(guān)系不含跨社區(qū)關(guān)系 for edge in graph.subgraph(community).edges(dataTrue): source, target, data edge graph_info.append(f{source} --{data.get(description, 關(guān)聯(lián))}-- {target}) # 生成摘要 chain summary_prompt | llm summary chain.invoke({graph_info: \n.join(graph_info)}).content summaries.append(summary) if (i 1) % 10 0: print(f已生成 {i1}/{len(communities)} 個(gè)社區(qū)摘要) return summaries坑4社區(qū)摘要成本高。100個(gè)社區(qū) 100次LLM調(diào)用。如果你有1000個(gè)社區(qū)光摘要就要$100。解決小社區(qū)5個(gè)實(shí)體可以用規(guī)則摘要直接拼接實(shí)體描述不用LLM。只有大社區(qū)才用LLM生成摘要。查詢(xún)階段局部檢索 vs 全局檢索GraphRAG有兩種查詢(xún)模式對(duì)應(yīng)不同類(lèi)型的問(wèn)題。局部檢索查實(shí)體關(guān)系用戶(hù)問(wèn)張三跟A公司什么關(guān)系——這是實(shí)體級(jí)問(wèn)題用局部檢索。def local_search(query, graph, entities, vectorstore, llm, top_k5): 局部檢索找到query相關(guān)的實(shí)體遍歷其鄰居關(guān)系 局部檢索結(jié)合了向量檢索找相關(guān)實(shí)體和圖遍歷找關(guān)系。 # 1. 用向量檢索找到query最相關(guān)的實(shí)體 relevant_entities vectorstore.similarity_search(query, ktop_k) entity_names [doc.metadata[entity_name] for doc in relevant_entities] # 2. 圖遍歷找到這些實(shí)體的鄰居1跳關(guān)系 context [] for entity_name in entity_names: if entity_name not in graph: continue # 實(shí)體本身的描述 node_data graph.nodes[entity_name] context.append(f實(shí)體: {entity_name} ({node_data.get(type, )})) context.append(f 描述: {node_data.get(description, )}) # 鄰居關(guān)系 for neighbor in graph.neighbors(entity_name): edge_data graph[entity_name][neighbor] neighbor_type graph.nodes[neighbor].get(type, ) context.append(f 關(guān)系: {entity_name} --{edge_data.get(description, 關(guān)聯(lián))}-- {neighbor} ({neighbor_type})) # 3. 用LLM基于圖信息生成回答 graph_context \n.join(context) answer_prompt ChatPromptTemplate.from_template( 基于以下知識(shí)圖譜信息回答問(wèn)題。知識(shí)圖譜信息{graph_context}問(wèn)題{question}回答 ) chain answer_prompt | llm return chain.invoke({graph_context: graph_context, question: query}).content全局檢索查社區(qū)摘要用戶(hù)問(wèn)公司所有產(chǎn)品線的整體技術(shù)架構(gòu)是什么——這是全局問(wèn)題用社區(qū)摘要。def global_search(query, community_summaries, llm, max_communities10): 全局檢索把所有社區(qū)摘要分批喂給LLM做Map-Reduce Map階段每個(gè)社區(qū)摘要單獨(dú)生成一個(gè)中間回答 Reduce階段匯總所有中間答案生成最終回答 # Map階段每個(gè)社區(qū)摘要生成中間回答 map_prompt ChatPromptTemplate.from_template( 基于以下社區(qū)摘要回答問(wèn)題。如果該社區(qū)的信息與問(wèn)題無(wú)關(guān)回復(fù)無(wú)關(guān)。社區(qū)摘要{summary}問(wèn)題{question}中間回答 ) intermediate_answers [] for summary in community_summaries[:max_communities]: chain map_prompt | llm answer chain.invoke({summary: summary, question: query}).content if 無(wú)關(guān) not in answer: intermediate_answers.append(answer) # Reduce階段匯總中間答案 reduce_prompt ChatPromptTemplate.from_template( 以下是多個(gè)信息來(lái)源對(duì)同一問(wèn)題的回答請(qǐng)綜合成一個(gè)完整的答案。問(wèn)題{question}各來(lái)源回答{answers}綜合答案 ) chain reduce_prompt | llm return chain.invoke({ question: query, answers: \n---\n.join(intermediate_answers), }).content坑5全局檢索延遲高。Map階段要調(diào)用10次LLM10個(gè)社區(qū)摘要Reduce階段再調(diào)1次。總延遲5-10秒。解決可以并行Map階段用asyncio或減少社區(qū)數(shù)量只選跟query最相關(guān)的社區(qū)用向量檢索篩選。完整Pipeline從文檔到查詢(xún)class GraphRAGPipeline: GraphRAG完整Pipeline def __init__(self, llm, embedding_model): self.llm llm self.embedding embedding_model self.graph None self.communities None self.community_summaries None self.entity_vectorstore None # 實(shí)體描述的向量索引 def index(self, documents): 建索引切分→抽取→構(gòu)圖→社區(qū)檢測(cè)→摘要 # 1. 切分 chunks graph_rag_chunking(documents) # 2. 抽取實(shí)體和關(guān)系 entities, relationships extract_entities_relations(chunks, self.llm) entities merge_entities(entities) # 合并同名實(shí)體 # 3. 構(gòu)圖 社區(qū)檢測(cè) self.graph, self.communities build_graph_and_detect_communities(entities, relationships) # 4. 社區(qū)摘要 self.community_summaries generate_community_summaries(self.communities, self.graph, self.llm) # 5. 實(shí)體描述建向量索引用于局部檢索 from langchain_community.vectorstores import Chroma entity_docs [] for entity in entities: entity_docs.append(Document( page_contententity.description, metadata{entity_name: entity.name, entity_type: entity.type} )) self.entity_vectorstore Chroma.from_documents(entity_docs, self.embedding) print(fGraphRAG索引完成{len(entities)}實(shí)體, {self.graph.number_of_edges()}關(guān)系, {len(self.communities)}社區(qū)) def query(self, question, modeauto): 查詢(xún)auto模式自動(dòng)選擇局部或全局檢索 if mode local: return local_search(question, self.graph, None, self.entity_vectorstore, self.llm) elif mode global: return global_search(question, self.community_summaries, self.llm) else: # auto用LLM判斷問(wèn)題類(lèi)型 route_prompt f判斷以下問(wèn)題的類(lèi)型 - 如果是具體實(shí)體關(guān)系問(wèn)題X和Y什么關(guān)系、X是誰(shuí)→ local - 如果是全局分析問(wèn)題整體情況、所有X的、趨勢(shì)→ global 問(wèn)題{question} 類(lèi)型local/global route self.llm.invoke(route_prompt).content.strip().lower() if global in route: return global_search(question, self.community_summaries, self.llm) else: return local_search(question, self.graph, None, self.entity_vectorstore, self.llm)GraphRAG的成本優(yōu)化GraphRAG最大的問(wèn)題是貴。500篇文檔建索引GPT-4o要$30-50。這里有幾個(gè)省錢(qián)方案優(yōu)化手段節(jié)省比例代價(jià)實(shí)體抽取用小模型GPT-4o-mini省70%抽取質(zhì)量下降約15%小社區(qū)用規(guī)則摘要不用LLM省30%小社區(qū)摘要質(zhì)量略差增量索引只處理新文檔省80%需要維護(hù)索引版本實(shí)體抽取緩存相同chunk不重復(fù)抽取省50%需要hash去重批量API調(diào)用OpenAI Batch API省50%延遲增加24小時(shí)我的建議開(kāi)發(fā)階段用GPT-4o-mini做實(shí)體抽取效果驗(yàn)證后再用GPT-4o重新建索引。或者用本地模型Qwen-14B做抽取零API成本。什么時(shí)候該上GraphRAG你的RAG遇到什么問(wèn)題│├── 用戶(hù)問(wèn)A和B什么關(guān)系→ 向量檢索找不到跨文檔關(guān)聯(lián)│ └── 該上GraphRAG│├── 用戶(hù)問(wèn)整體趨勢(shì)/所有產(chǎn)品的依賴(lài)關(guān)系│ └── 該上GraphRAG全局檢索│├── 用戶(hù)問(wèn)X影響了哪些東西│ └── 該上GraphRAG圖遍歷│├── 用戶(hù)問(wèn)退貨流程是什么→ 單文檔能回答│ └── 不需要GraphRAG向量RAG夠了│└── 預(yù)算有限文檔量100篇 └── 不建議上LLM抽取成本太高本篇要點(diǎn)要點(diǎn)說(shuō)明GraphRAG核心流程切分→實(shí)體關(guān)系抽取→社區(qū)檢測(cè)→社區(qū)摘要局部檢索向量檢索找實(shí)體 圖遍歷找關(guān)系適合實(shí)體級(jí)問(wèn)題全局檢索Map-Reduce社區(qū)摘要適合全局分析問(wèn)題社區(qū)檢測(cè)Leiden算法把圖分成緊密關(guān)聯(lián)的子圖分層社區(qū)支持多粒度查詢(xún)成本優(yōu)化小模型抽取 規(guī)則摘要 增量索引 緩存適用場(chǎng)景實(shí)體關(guān)系密集 全局性問(wèn)題 跨文檔推理踩坑清單chunk太大抽取遺漏超過(guò)1500字符LLM注意力衰減后半部分實(shí)體被忽略。默認(rèn)1200 token別改大。實(shí)體名稱(chēng)不統(tǒng)一同一實(shí)體被抽成多個(gè)名字圖里變成多個(gè)孤立節(jié)點(diǎn)。必須做實(shí)體合并/消歧。社區(qū)粒度不可控一個(gè)社區(qū)太大或太小都不好用。用分層社區(qū)檢測(cè)查詢(xún)時(shí)選合適層級(jí)。社區(qū)摘要成本高100個(gè)社區(qū)100次LLM調(diào)用。小社區(qū)用規(guī)則摘要大社區(qū)才用LLM。全局檢索延遲高M(jìn)ap階段串行調(diào)用10次LLM要5-10秒。用asyncio并行化或減少參與Map的社區(qū)數(shù)。增量更新困難新增文檔后不能只更新局部圖可能影響社區(qū)結(jié)構(gòu)。微軟GraphRAG的增量更新還在迭代中目前最穩(wěn)妥的方案是定期全量重建。圖太大查詢(xún)慢上萬(wàn)節(jié)點(diǎn)的圖遍歷會(huì)卡。給圖建索引如Neo4j的索引或者用圖數(shù)據(jù)庫(kù)替代NetworkX。踩坑清單補(bǔ)充坑癥狀解決chunk太大LLM抽取后半部分實(shí)體被忽略默認(rèn)1200token別改大實(shí)體名稱(chēng)不統(tǒng)一圖里全是孤立節(jié)點(diǎn)加實(shí)體合并層社區(qū)粒度不好太大丟細(xì)節(jié)太小沒(méi)信息量分層社區(qū)檢測(cè)社區(qū)摘要成本高100個(gè)社區(qū)100次LLM調(diào)用小社區(qū)用規(guī)則摘要全局檢索慢Map階段串行10次LLMasyncio并行增量更新難新文檔可能影響社區(qū)結(jié)構(gòu)定期全量重建學(xué)AI大模型的正確順序千萬(wàn)不要搞錯(cuò)了2026年AI風(fēng)口已來(lái)各行各業(yè)的AI滲透肉眼可見(jiàn)超多公司要么轉(zhuǎn)型做AI相關(guān)產(chǎn)品要么高薪挖AI技術(shù)人才機(jī)遇直接擺在眼前有往AI方向發(fā)展或者本身有后端編程基礎(chǔ)的朋友直接沖AI大模型應(yīng)用開(kāi)發(fā)轉(zhuǎn)崗超合適就算暫時(shí)不打算轉(zhuǎn)崗了解大模型、RAG、Prompt、Agent這些熱門(mén)概念能上手做簡(jiǎn)單項(xiàng)目也絕對(duì)是求職加分王給大家整理了超全最新的AI大模型應(yīng)用開(kāi)發(fā)學(xué)習(xí)清單和資料手把手幫你快速入門(mén)學(xué)習(xí)路線:?大模型基礎(chǔ)認(rèn)知—大模型核心原理、發(fā)展歷程、主流模型GPT、文心一言等特點(diǎn)解析?核心技術(shù)模塊—RAG檢索增強(qiáng)生成、Prompt工程實(shí)戰(zhàn)、Agent智能體開(kāi)發(fā)邏輯?開(kāi)發(fā)基礎(chǔ)能力—Python進(jìn)階、API接口調(diào)用、大模型開(kāi)發(fā)框架LangChain等實(shí)操?應(yīng)用場(chǎng)景開(kāi)發(fā)—智能問(wèn)答系統(tǒng)、企業(yè)知識(shí)庫(kù)、AIGC內(nèi)容生成工具、行業(yè)定制化大模型應(yīng)用?項(xiàng)目落地流程—需求拆解、技術(shù)選型、模型調(diào)優(yōu)、測(cè)試上線、運(yùn)維迭代?面試求職沖刺—崗位JD解析、簡(jiǎn)歷AI項(xiàng)目包裝、高頻面試題匯總、模擬面經(jīng)以上6大模塊看似清晰好上手實(shí)則每個(gè)部分都有扎實(shí)的核心內(nèi)容需要吃透我把大模型的學(xué)習(xí)全流程已經(jīng)整理好了抓住AI時(shí)代風(fēng)口輕松解鎖職業(yè)新可能希望大家都能把握機(jī)遇實(shí)現(xiàn)薪資/職業(yè)躍遷這份完整版的大模型 AI 學(xué)習(xí)資料已經(jīng)上傳CSDN朋友們?nèi)绻枰梢晕⑿艗呙柘路紺SDN官方認(rèn)證二維碼免費(fèi)領(lǐng)取【保證100%免費(fèi)】