要解决的问题

传统 RAG 在多跳问题上翻车：比如「欧拉（Euler）的老师（Johann）的儿子（Daniel）做了哪些贡献？」。

普通相似度检索的原理是「查询和段落的语义贴近」，但答案藏在隔着两跳的关系里：

Euler ←是学生→ Johann ←是儿子→ Daniel ←贡献→ 流体力学

查询和 Daniel 的段落语义上离得很远，naive RAG 直接搜不到。

答案：Graph RAG —— 用实体关系连成图，沿着图走多跳。但常见的 GraphRAG（如微软版）要装图数据库。这个 notebook 的创新是：只用向量库（Milvus）就做出图推理，不装图库。

核心思想：不存图，算图

整个系统的灵魂一句话：把「图」拆成 3 个向量集合，图结构不存，查询时用邻接矩阵现算多跳。

入库：3 个向量集合 + 邻接映射

原始数据：段落 + 三元组

{
  "passage": "Jakob Bernoulli (1654–1705): ... 他做了X贡献 ...",
  "triplets": [
    ["Jakob Bernoulli", "was the older brother of", "Johann Bernoulli"],
    ["Jakob Bernoulli", "is known for", "the Bernoulli numbers"]
  ]
}

拆成 3 类

entities  = []   # 实体：三元组的 subject 和 object
relations = []   # 关系：三元组拼成一句话
passages  = []   # 原文段落

for triplet in triplets:
    entities.append(triplet[0])   # subject
    entities.append(triplet[2])   # object
    relations.append(" ".join(triplet))  # "Jakob Bernoulli was the older brother..."

关键：关系不是存结构化 (subject, predicate, object)，而是拼成自然语言句子再嵌入，这样向量才有语义。

建 2 张邻接映射表（这才是「图」）

entityid_2_relationids = defaultdict(list)  # 实体 → 参与哪些关系
relationid_2_passageids = defaultdict(list) # 关系 → 出自哪个段落

entityid_2_relationids[entities.index(triplet[0])].append(relation_id)
entityid_2_relationids[entities.index(triplet[2])].append(relation_id)  # 两端都连
relationid_2_passageids[relation_id].append(passage_id)

图从没作为图存过 —— 就两张 Python dict 记录「实体↔关系」「关系↔段落」谁连着谁。

3 个向量集合（Milvus）—— 标准的 embedding 入库

3 个列表各自 embedding 进对应集合，跟普通 RAG 入库没区别：

create_milvus_collection("entity_collection")   # 实体向量
create_milvus_collection("relation_collection") # 关系向量
create_milvus_collection("passage_collection")  # 段落向量

def milvus_insert(collection_name, text_list):
    for row_id in range(0, len(text_list), 512):
        batch_texts = text_list[row_id : row_id + 512]
        batch_embeddings = embedding_model.embed_documents(batch_texts)  # 文本→向量
        batch_data = [{"id": id_, "text": text, "vector": vector} ...]
        milvus_client.insert(collection_name, data=batch_data)

milvus_insert(relation_col_name, relations)  # 关系列表 → relation 向量库
milvus_insert(entity_col_name,   entities)   # 实体列表 → entity 向量库
milvus_insert(passage_col_name,  passages)   # 段落列表 → passage 向量库

每条记录 {id, text, vector}：id = 在列表里的下标，text = 原文，vector = embedding。

注意：向量库是「3 列表分别 embedding」来的，不是从 dict 转的。dict 和向量库是两条平行线，都来自同一批 3 列表，dict 只记连接、向量库存向量，靠 id 对齐。

邻接矩阵：把 dict 变成能算的矩阵

查询前把「实体-关系」dict 转成稀疏矩阵：

entity_relation_adj = np.zeros((len(entities), len(relations)))
entity_relation_adj[entity_id, entityid_2_relationids[entity_id]] = 1
entity_relation_adj = csr_matrix(entity_relation_adj)  # 稀疏省内存

entity_relation_adj[i][j]=1 ⟺ 实体 i 参与了关系 j。

矩阵乘法 = 图遍历（核心魔法）：

# 1跳：A @ A.T
entity_adj_1_degree = entity_relation_adj @ entity_relation_adj.T
# N跳：乘 N 次
for _ in range(target_degree - 1):
    entity_adj_target_degree = entity_adj_target_degree @ entity_adj_1_degree.T

直觉：A @ A.T 里，实体 i 和 k 若连到同一关系 j，乘积为 1 —— 说明 i、k 隔一跳相连。乘一次 = 扩一跳。

查询：向量召回 → 矩阵展开 → LLM 过滤 → 回段落

① 双路向量召回（找「图的入口种子」）

查询进来，两条路并行去向量库搜，各得一个种子：

路 1：实体路 —— NER 提实体，搜实体库

query_ner_list = ["Euler"]            # NER 从查询里抽出实体名
# query_ner_list = ner(query)         # 实际做法，这里写死省事
query_ner_emb = embedding_model.embed_query("Euler")
entity_search = milvus_client.search(entity_collection, data=query_ner_emb, limit=3)

目的：精确定位到查询里明确提到的实体节点（如 “Euler”）。

路 2：关系路 —— 整句查询，搜关系库

query_emb = embedding_model.embed_query("What contribution did the son of Euler's teacher make?")
relation_search = milvus_client.search(relation_collection, data=query_emb, limit=3)

目的：整句语义去匹配意图接近的关系（如「师生/父子」这类模式）。

为什么两路都要：实体是「点」，关系是「线」。多跳问题光有点（Euler）不够，还得有线（谁是谁的老师/儿子）。实体路抓锚点，关系路抓结构，一路漏了另一路补。

NER = Named Entity Recognition，命名实体识别，从文本里抽出人名/地名/机构名这类专有名词。

② 邻接矩阵多跳展开

# 从召回的关系出发，扩出所有邻居关系
for hit_id in 召回的关系:
    expanded_from_relation |= relation_adj_target_degree[hit_id].nonzero()

# 从召回的实体出发，扩出相关的所有关系
for hit_id in 召回的实体:
    expanded_from_entity |= entity_relation_adj_target_degree[hit_id].nonzero()

relation_candidate_ids = expanded_from_relation | expanded_from_entity  # 并集

这一步是图遍历：拿到种子实体/关系，用矩阵查出它们一跳（或多跳）能连到的所有关系。

③ LLM rerank（CoT 挑关系）

候选关系太多，用 LLM 聪明地挑 3 条，带 one-shot 例子 + 思维链：

rerank_res = rerank_chain.invoke({"question": query, "relation_des_str": 候选关系})

LLM 理解「欧拉的老师是谁 → 谁是他儿子 → 儿子做了啥」，选中关键关系。

④ 映射回段落，生成答案

for relation_id in rerank_relation_ids:
    for passage_id in relationid_2_passageids[relation_id]:  # 靠 dict 找原文
        if passage_id not in final_passages:
            final_passages.append(passages[passage_id])

选中关系 → 用 relationid_2_passageids 找回段落 → 喂 LLM 生成。

完整流程

入库是两条平行线：向量线（3列表→embedding→3向量库）和图线（3列表→数id→2张邻接dict），靠 id 对齐，dict 不是向量库的来源。

入库: 文本 → 三元组
   ├─ 向量线: 实体/关系/段落 3列表 → 各自embedding → 3个Milvus向量库
   └─ 图线:   同一批3列表 → 数id → 2张邻接dict（只记连接，不产生向量）
                                 │ 查询时 dict 转稀疏邻接矩阵

查询: 查询文本
   ├─ 路1: NER提实体("Euler") → embed → 搜【实体库】 → 种子实体 id
   ├─ 路2: 整句embed → 搜【关系库】 → 种子关系 id
   └─ 两路种子 → 邻接矩阵扩N跳 → 候选关系集
      → LLM CoT rerank 挑3条关键关系
      → 靠 relationid_2_passageids 找回段落 → 生成答案

双路召回：实体路（NER 抽名词搜实体库）+ 关系路（整句搜关系库），各提供一个「图的入口种子」。召回找入口，矩阵做蔓延，然后 LLM 挑关系、dict 回段落。

效果对比

同一个多跳问题，naive RAG 和本方法：

naive RAG 失败原因：查询与 Daniel 段落语义距离远，表面关键词对不上。GraphRAG 靠矩阵展开 + rerank 沿着关系链找到了答案。

技术要点

• 只用向量库做出图推理，省掉图数据库
• 稀疏矩阵做多跳展开，向量化快、省内存，可扩展到数千实体毫秒级
• 双路召回（实体 + 关系）提供冗余，一路漏了另一路补
• LLM CoT rerank 模拟图的社区过滤，比纯相似度更懂多跳意图

一句话总结

Graph RAG with Milvus = 向量召回找入口 + 邻接矩阵现算多跳 ≈ 图遍历 + LLM rerank 过滤 ≈ 社区。用「一个向量库」拼出伪图推理，省掉图数据库，代价是这些都得现算。

参考

• 仓库：https://github.com/NirDiamant/RAG_Techniques
• Milvus / Zilliz Cloud：https://cloud.zilliz.com

要解决的问题

普通 RAG 用的是 flat index（扁平索引）：所有 chunk 一股脑塞进向量库，查询时全局相似度搜索。文档大或语料多时，flat 检索有两个问题：

1. 效率低：每次都要扫全部 chunk。
2. 丢失上下文：chunk 太小，脱离了它在文档里的位置，可能召回不相关的东西。

Hierarchical Indices 的做法：建两级索引 —— 先存文档级摘要，再存细节 chunk。检索时「先粗后细」：先扫摘要定位到相关文档，再进到该文档的 chunk 里挖细节。

两级索引怎么建

key：摘要和 chunk 共享 page 元数据，这是两级能串起来的关键。

文档(按页) → 摘要向量库(summary)  ← 存每页摘要
           → chunk向量库(detailed) ← 存每页拆出的细节块
                    │
        两边都带 metadata["page"]  —— 靠页码把两级连起来

① 生成摘要（异步 + 限流）

用 load_summarize_chain 的 map_reduce 逐页摘要，配合 asyncio 并发 + 指数退避处理限流：

async def summarize_doc(doc):
    summary_output = await retry_with_exponential_backoff(summary_chain.ainvoke([doc]))
    summary = summary_output['output_text']
    return Document(
        page_content=summary,
        metadata={"source": path, "page": doc.metadata["page"], "summary": True}
    )

# 分批处理，每批5个，避免撞限流
batch_size = 5
for i in range(0, len(documents), batch_size):
    batch_summaries = await asyncio.gather(*[summarize_doc(doc) for doc in batch])
    summaries.extend(batch_summaries)
    await asyncio.sleep(1)   # 批间暂停

② 生成 chunk 并打标

细节 chunk 用 RecursiveCharacterTextSplitter 切，metadata 里标记 summary: False 和 page：

chunk.metadata.update({
    "chunk_id": i,
    "summary": False,
    "page": int(chunk.metadata.get("page", 0))
})

③ 两个向量库

summary_vectorstore, detailed_vectorstore = await asyncio.gather(
    create_vectorstore(summaries),
    create_vectorstore(detailed_chunks)
)

层级检索：先粗后细

def retrieve_hierarchical(query, summary_vectorstore, detailed_vectorstore,
                          k_summaries=3, k_chunks=5):
    # 第一级：扫摘要定位相关文档
    top_summaries = summary_vectorstore.similarity_search(query, k=k_summaries)

    relevant_chunks = []
    for summary in top_summaries:
        # 第二级：只在该摘要对应的页码里挖细节 chunk
        page_number = summary.metadata["page"]
        page_filter = lambda metadata: metadata["page"] == page_number
        page_chunks = detailed_vectorstore.similarity_search(
            query, k=k_chunks, filter=page_filter
        )
        relevant_chunks.extend(page_chunks)

    return relevant_chunks

流程：

用户查询 → 扫夏摘要库 → 找到相关文档(页码) → 限定该页 → 扫chunk库 → 返回细节块

关键点：第二级用 page_filter 按页码过滤，只从第一级命中的文档页里取 chunk。这样细节不会跑偏到别的章节。

对比 flat index

技术细节亮点

• 持久化：向量库 save_local 存盘，避免每次重算：

  summary_store.save_local("../vector_stores/summary_store")
  detailed_store.save_local("../vector_stores/detailed_store")
  

• 限流处理：retry_with_exponential_backoff + 分批 + asyncio.sleep，是调用外部 LLM 摘要时的工程标配。
• 异步：用 asyncio.to_thread + asyncio.gather 并发建两个向量库，I/O 密集场景提速。

一句话总结

Hierarchical Index = 摘要粗筛定位 + 页码过滤细取。用两级索引换取「效率 + 上下文保真」，适合大文档/大语料，代价是入库时要多跑一遍摘要。

参考

• 仓库：https://github.com/NirDiamant/RAG_Techniques

要解决的问题

普通 RAG 检索时，用户查询是短问句，库里存的是长文档。两者的向量分布在 embedding 空间里相隔很远 —— 论文里叫 query-document style mismatch。短问句直接去匹配长文档，经常匹配不准。

HyDE 和 HyPE 是解决这个「风格鸿沟」的两个方向。核心思路一致：用 LLM 生成一个「假的东西」，让查询和存储的形态对齐。但方向恰好相反。

HyDE：查询时生成假文档

HyDE = Hypothetical Document Embedding（假设文档嵌入）。

核心：查询时，先让 LLM 根据问题生成一个假装已经答好的文档，再用这个假文档去向量库检索。

class HyDERetriever:
    def __init__(self, files_path, chunk_size=500, chunk_overlap=100):
        self.hyde_prompt = PromptTemplate(
            input_variables=["query", "chunk_size"],
            template="""Given the question '{query}', generate a hypothetical document
            that directly answers this question. The document should be detailed and in-depth.
            the document size has be exactly {chunk_size} characters.""",
        )
        self.hyde_chain = self.hyde_prompt | self.llm

    def retrieve(self, query, k=3):
        hypothetical_doc = self.generate_hypothetical_document(query)  # 先生成假文档
        similar_docs = self.vectorstore.similarity_search(hypothetical_doc, k=k)  # 用假文档检索
        return similar_docs, hypothetical_doc

流程：

用户问题 → LLM 生成假文档(假设的答案) → 用假文档去 FAISS 检索 → 返回真实 chunk

关键设定：prompt 里要求假文档长度 exactly {chunk_size}，让假文档和库里的 chunk 长度形态一致，向量更贴近。

• 时机：查询时（在线）
• 成本：每次查询都要调 LLM 生成，有额外开销
• 匹配：文档 ↔ 假文档

HyPE：入库时生成假问题

HyPE = Hypothetical Prompt Embeddings（假设提示词嵌入）。

核心：与 HyDE 反过来 —— 入库时，让 LLM 对每个 chunk 猜几个「用户可能会问的问题」，把这些问题向量存进库，而不是存 chunk 原文向量。

def generate_hypothetical_prompt_embeddings(chunk_text: str):
    question_chain = question_gen_prompt | llm | StrOutputParser()
    questions = question_chain.invoke({"chunk_text": chunk_text}).replace("\n\n", "\n").split("\n")
    return chunk_text, embedding_model.embed_documents(questions)

入库时一对多：一个 chunk 生成 N 个问题向量，但都指向同一个 chunk，所以一个 chunk 被存 N 次。

chunks_with_embedding_vectors = [(chunk.page_content, vec) for vec in vectors]
vector_store.add_embeddings(chunks_with_embedding_vectors)

流程：

chunk → LLM 猜N个问题 → 分别embed → N个问题向量(都指向同一chunk) → FAISS
用户查询 → embed → 问题↔问题匹配 → 映射回chunk原文

• 时机：入库时（离线）
• 成本：一次性，入库多花；查询零额外开销
• 匹配：问题 ↔ 问题

对比

一句话总结

HyDE 和 HyPE 是同一个思路的两个方向：都用 LLM 弥合「用户怎么问」和「文档怎么存」之间的风格鸿沟。

• HyDE 把查询变成假文档，改的是查询侧。
• HyPE 把文档变成假问题，改的是存储侧。

HyPE 把成本挪到入库的一次性开销，换来查询时的零额外成本，这是它「可扩展」的最大卖点。HyPE 论文宣称检索精度最高可提升 42 个百分点。

参考

• HyPE 预印本：https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5139335
• 仓库：https://github.com/NirDiamant/RAG_Techniques

一、两种思维模式

1. 遍历二叉树，外部变量实现
2. 分解为子问题

> 快排类似于前序遍历，归并类似于后序遍历

二、前/中/后序遍历的区别

核心：遍历位置决定它们能根据多少信息做判断

三、以树的视角看 DP / 回溯 / DFS

四、解题核心思路

1. 节点视角

> 如果单独抽出一个二叉树节点，它需要做什么事？需要在什么时候（前/中/后序）做？

2. DFS / 路径类问题

• 递归到底部
• 保存类似路径的，使用递归
• 用一个变量保存路径

3. 最近公共祖先（LCA）

使用递归思路，将问题拆分： 永find(root,val1,val2) 若根节点val=val1或val2，那根节点就是lca 左右子树各找到一个，那root还是祖先 只在一侧找到，结果在那一侧，返回（子树，val1，val2）

常见题型

在dfs中，一般为遍历和分解问题等题型 在bfs中，显然只能遍历

代码

dfs

// 二叉树的遍历框架
void traverse(TreeNode* root) {
    if (root == nullptr) {
        return;
    }
    // 前序位置
    traverse(root->left);
    // 中序位置
    traverse(root->right);
    // 后序位置
}

bfs

void levelOrderTraverse(TreeNode* root) {
    if (root == nullptr) {
        return;
    }
    queue<TreeNode*> q;
    q.push(root);
    // 记录当前遍历到的层数（根节点视为第 1 层）
    int depth = 1;

    while (!q.empty()) {
        int sz = q.size();
        for (int i = 0; i < sz; i++) {
            TreeNode* cur = q.front();
            q.pop();
            // 访问 cur 节点，同时知道它所在的层数
            cout << "depth = " << depth << ", val = " << cur->val << endl;

            // 把 cur 的左右子节点加入队列
            if (cur->left != nullptr) {
                q.push(cur->left);
            }
            if (cur->right != nullptr) {
                q.push(cur->right);
            }
        }
        depth++;
    }
}

一、核心观点

所有 RAG 技术本质上都在优化同一个目标：

在成本、延迟、质量、可控性之间取得平衡，让 LLM 拿到最合适、最相关、最可控的上下文。

传统的线性流水线可以抽象为：

Query → Query处理 → Embedding → 检索 → 重排/压缩 → 上下文组装 → LLM生成

不同技术是在这个漏斗的不同位置做优化，但很多先进技术已经跨层甚至形成反馈循环。

二、按 Pipeline 阶段分类

1. Query 层：查询理解与改写

这些技术不改知识库，只改用户 query 或查询策略：

Insight：这一层优化的不是”检索本身”，而是让 query 更接近索引内容的语义分布。

2. Encoding / 表示层：文档如何被嵌入

这些技术改变”文档以什么形式进入向量空间”：

Insight：

• proposition_chunking 做语义粒度精细化，代价是索引膨胀。
• document_augmentation 做查询-文档对齐。
• ColPali 是端到端视觉检索，captioning 是间接文本检索。

3. Indexing / 索引结构层

这些技术改变知识库的组织方式：

Insight：GraphRAG 和 RAPTOR 都在解决”全局综合类问题”，前者用图+社区摘要，后者用树状语义聚类。

4. Retrieval / 检索策略层

这些技术改变”怎么从索引里把内容捞出来”：

Insight：dartboard 解决结果冗余，fusion_retrieval 解决向量检索对关键词不敏感的问题。

5. Post-Retrieval / 上下文组装层

这些技术发生在”捞出候选文档后，送给 LLM 前”：

Insight：context_enrichment_window 是”小块+周边”，relevant_segment_extraction 是”基于相关性拼成大块”，方向不同。

6. Generation / LLM 交互层

这些技术重点在 LLM 如何消费检索结果：

Insight：self_rag 和 crag 是”检索-生成闭环”，LLM 不再只是最后一步。

7. 系统级 / Agentic / 反馈层

这些技术跨多个阶段，是整体架构设计：

三、按失败模式选技术

比阶段分类更实用的是”失败模式”视角：

四、最重要的三个洞察

1. 跨层技术是常态 真正有效的方案往往跨多个阶段。例如 RAPTOR 同时改了 indexing（树）和 retrieval（分层），Self-RAG 同时改了 retrieval 和 generation。

2. 代价转移而非消除 GraphRAG 把成本从在线移到离线，HyDe 把成本从检索后移到检索前，document_augmentation 用索引膨胀换检索精度。RAG 优化本质上是成本在时间轴和空间轴上的重新分配。

3. 优化对象不是”检索质量”，而是”对 LLM 生成的边际贡献” 检索到的 chunk 相关性高，不一定对最终答案最有帮助。有时需要多样性、反事实证据或结构化关系。

MemoRAG 在标准 RAG 的检索阶段之前，增加了一个记忆模型。这个模型先对文档库做一次压缩记忆，查询时基于记忆生成更精确的检索线索，从而提高模糊、隐式、长上下文查询的检索质量。

2. 解决什么痛点？

标准 RAG 直接对 query 做向量检索，遇到以下情况效果不好：

• query 有歧义或指代（如”那件事后来怎么样了？”）
• query 需要结合文档背景才能理解
• 长文档中信息分散，需要全局上下文
• 用户问题与文档答案在字面上不匹配

MemoRAG 通过记忆模型让检索器”提前知道文档里有什么”。

3. 与 Query Transformation 的关系

可以把 MemoRAG 理解为”带全局上下文的 Query Rewriting”。

4. 核心流程

文档
    ↓
切分成 chunks
    ↓
Memory Model 抽取/压缩记忆
    ↓
记忆存入向量库
    ↓

用户 query
    ↓
在记忆中检索相关主题
    ↓
生成 text spans + surrogate queries
    ↓
用这些线索检索原始文档
    ↓
LLM 生成最终答案

5. 本 notebook 中的简化实现

5.1 记忆结构：topic-details pairs

用 LLM 从每个文档 chunk 中提取结构化键值对：

{
  "pairs": [
    { "topic": "气候变暖对生物多样性的影响", "details": "气温上升导致许多物种因栖息地丧失而面临灭绝。" },
    { "topic": "海洋酸化", "details": "海洋吸收过量二氧化碳，导致酸化加剧。" }
  ]
}

5.2 建记忆

def memorize(self, document: str):
    response = client.chat.completions.create(
        model="qwen-turbo",
        messages=[...],
        response_format={"type": "json_object"}
    )
    pairs = self._parse_into_pairs(response)
    # 存入 FAISS

5.3 查询时生成检索线索

def create_retrieval_queries(self, query: str):
    # 1. 在 memory store 中检索相关 topic-details
    results = self.store.similarity_search_with_score(query, k=10)

    # 2. 生成 text spans（关键词/片段线索）
    # 3. 生成 surrogate queries（替代/子问题）

    return text_spans + surrogate_queries + [query]

6. Memory Model 一般是什么？

7. 成本分析

MemoRAG 比 GraphRAG 便宜，但比标准 RAG 贵。适合查询频繁、需要更好检索质量的场景。

8. 优缺点

优点

1. 提高模糊/隐式查询的检索效果；
2. 复用标准 RAG 检索链路；
3. 实现比 GraphRAG 简单；
4. 适合长文档和对话式 RAG。

缺点

1. 索引阶段需要额外 LLM 调用；
2. 记忆质量依赖 LLM 抽取能力；
3. topic 粒度需要调优；
4. 不是真正的跨文档推理，只是增强检索线索。

9. 实践注意事项

1. 文档一定要切分后再 memorize，不要整篇传入；
2. OpenAI 兼容接口必须设置 base_url，否则默认连 OpenAI 官方；
3. chunk size 建议 2000-4000 token，太小会导致 topic 太碎，太大会超时；
4. 给 memory model 设置 timeout 和 retry，长文本生成可能较慢。

10. 核心 Insight

MemoRAG 的核心价值不是”改写问题”，而是”让检索拥有全局上下文”：

• 普通 Query Rewriting：把用户的话翻得更清楚；
• MemoRAG：像读过整本书的助手，不仅翻译问题，还告诉你要查哪几个关键词。

11. 相关技术

• [[query-transformations-summary]]：不带记忆的 query 改写
• [[raptor-summary]]：用主题树组织文档
• [[microsoft-graphrag-summary]]：用知识图谱组织文档
• [[proposition-chunking-summary]]：把文档拆成原子化事实

Microsoft GraphRAG 是一种把文档先转换成知识图谱，再基于图谱中的实体、关系和社区进行检索与回答的 RAG 方案。它擅长处理需要跨文档连接信息、全局综合理解的复杂查询。

2. 解决什么痛点？

传统 RAG 把文档切成 chunk 后做向量检索，擅长回答”某段文字说了什么”，但不擅长：

• 连接分散信息：比如”Elon Musk 创立/收购了哪些公司？它们之间有什么关系？”
• 全局理解：比如”这篇文章的主题是什么？整体趋势如何？”
• 复杂综合推理：需要把多个来源的信息拼凑起来

GraphRAG 通过知识图谱把实体和关系显式建模，解决这些问题。

3. 索引阶段流程

原始文本
    ↓
Text Chunking（文本切分）
    ↓
Element Extraction（LLM 提取实体和关系）
    ↓
Graph Construction（构建知识图谱）
    ↓
Community Detection（发现社区/簇）
    ↓
Community Summarization（为每个社区生成摘要）

各步骤说明

4. 查询阶段：两种搜索模式

4.1 Local Search（局部搜索）

针对具体实体的查询，展开该实体的邻居节点和相关概念。

示例：

“What and how many companies and subsidiaries founded by Elon Musk?”

4.2 Global Search（全局搜索）

针对整体语料的查询，综合多个社区摘要给出宏观回答。

示例：

“What are the major accomplishments of Elon Musk?”

5. 代码实现要点

这个 notebook 使用 GraphRAG 官方 CLI 工具：

# 初始化配置
python -m graphrag.index --init --root data/graphrag

# 建索引
python -m graphrag.index --root ./data/graphrag

# 查询
python -m graphrag.query --root ./data/graphrag --method local "query"

配置

• LLM：gpt-4o
• Embedding：text-embedding-3-large
• 支持 Azure OpenAI 或 OpenAI

注意：按照 .claude.md，这个 notebook 没有被迁移到阿里云百炼，因为它明确依赖 Azure OpenAI/OpenAI。

数据源

notebook 用 BeautifulSoup 抓取 Wikipedia 上 Elon Musk 的词条，保存为 data/elon.md，再喂给 GraphRAG 建索引。

6. 与传统 RAG 的对比

7. 主要局限

1. 索引成本极高：每个 chunk 都要调 LLM 提取实体和关系；
2. 对 LLM 质量敏感：实体关系提取错误会传播到整个图谱；
3. 不适合简单事实查询：如”BLEU 是多少”用传统 RAG 更快更便宜；
4. 图规模管理：文档量大时图谱可能很庞大，成本上升。

8. 适用场景

• 人物关系网分析
• 企业架构与股权关系
• 医学文献中的疾病-药物-症状关系
• 法律案例中的主体关系
• 任何实体关系密集、需要跨文档综合的语料

9. 核心 Insight

GraphRAG 的本质是把”语义检索”升级成”关系检索”：

• 向量 RAG 回答”哪段文字和我的问题语义最像”；
• GraphRAG 回答”哪些实体通过什么关系连接在一起”。

10. 与 RAPTOR 的对比

• RAPTOR：用树的层级抽象解决”宏观 vs 细节”的问题；
• GraphRAG：用图的节点关系解决”连接 vs 综合”的问题。

两者甚至可以结合：先用 GraphRAG 找到相关实体和社区，再在 RAPTOR 树中定位这些实体的详细描述。

11. 相关技术

• [[raptor-summary]]：用主题树组织文档
• [[proposition-chunking-summary]]：把文档拆成原子化事实
• [[query-transformations-summary]]：改写问题提高检索匹配度
• [[colpali-multimodal-rag-qa]]：多模态图像检索

Multimodal RAG with Captioning 不是直接检索图片，而是先用多模态模型把图片/表格生成文字描述（caption），再把 caption 和原始文本一起存入向量库做传统文本检索。

2. 核心思想

PDF 页面
    ├──→ 提取文字 ───────────┐
    └──→ 提取图片 ─→ Gemini 生成 caption ─┘
                              ↓
                    统一变成文本块
                              ↓
                    Cohere 嵌入 → Chroma 向量库
                              ↓
                    文本检索 → Cohere LLM 生成答案

所有非文本内容都被多模态模型”看懂”后”写成文字”，最终全部走传统文本 RAG 链路。

3. 完整流程

3.1 PDF 解析

使用 PyMuPDF（fitz）同时提取：

• 每页文字
• 页内所有图片

with fitz.open('attention_is_all_you_need.pdf') as pdf_file:
    for page_number in range(len(pdf_file)):
        page = pdf_file[page_number]
        text = page.get_text().strip()
        # 提取图片并保存

3.2 图片 Captioning

用 Gemini-1.5-flash 看图并生成适合检索的摘要：

response = model.generate_content([image,
    "You are an assistant tasked with summarizing tables, images and text for retrieval. ..."])

例如一张 BLEU 分数表可能被描述为：

Table showing BLEU scores for Transformer base and big models. The base model achieves 27.3 BLEU.

3.3 统一嵌入和检索

把文字和图片描述统一成 Document，一起存入 Chroma：

vectorstore = Chroma.from_documents(
    documents=doc_splits + img_splits,
    embedding=embedding_model,
)

3.4 问答

检索回文字或 caption，交给 LLM 生成答案：

docs = retriever.invoke(query)
generation = rag_chain.invoke({"documents": docs[0].page_content, "question": query})

4. 与 ColPali 路线的对比

5. 优缺点

优点

1. 复用文本 RAG 基础设施：不需要特殊多模态向量库；
2. 检索粒度更细：可以精确到某段文字或某张图片；
3. 索引体积小：不存原始图片；
4. 生成阶段更简单：给 LLM 的是文字，无需多模态模型。

缺点

1. Caption 质量是瓶颈：描述错误会传递到检索和生成；
2. 丢失视觉细节：复杂图表、布局、颜色信息会被简化；
3. 无法处理纯视觉问题：如”图中红色曲线代表什么”；
4. 额外 LLM 调用成本：每张图片都要生成 caption。

6. 选型建议

7. 实践注意事项

1. Caption 和原始文本混合检索时，建议给 caption 加前缀标记，如 IMAGE_CAPTION: ...，便于区分来源；
2. 不要只取 top-1：生产环境建议 k=3~5；
3. Caption 提示词很关键：要指导模型生成”适合检索”的描述，而不是泛泛而谈。

8. 核心 Insight

Captioning 路线的本质是用 LLM 做”有损的多模态→文本转换”：

• 优势是把多模态问题降维成文本问题，复用成熟技术栈；
• 代价是图片信息经过 LLM 压缩后，会丢失原始视觉细节；
• 它不是”真正理解图片”，而是”让图片能被文本检索理解”。

9. 相关技术

• [[colpali-multimodal-rag-qa]]：直接基于视觉特征检索页面图像
• [[proposition-chunking-summary]]：把文档拆成原子化事实
• [[query-transformations-summary]]：改写问题提高检索匹配度

ColPali 不是传统 RAG 的替代品，而是处理视觉密集型文档的专用工具。它把 PDF 页面当作图像直接检索，再由多模态 LLM 读懂返回的页面图像。

1. ColPali 是为了解决什么痛点？

传统文本 RAG 处理 PDF 时通常先 OCR 提取文字，但会丢失或破坏：

• 页面布局和视觉结构
• 表格、图表、公式的原始形式
• 手写内容、扫描件、复杂排版

ColPali 让检索器直接”看”PDF 页面图像，绕过 OCR，保留完整的视觉信息。

2. ColPali 和普通的 text embedding 模型有什么区别？

普通 embedding 把 query 和文档各压缩成一个向量；ColPali 保留 query token 和图像 patch 之间的细粒度对应关系。

3. 什么是 Late Interaction（后期交互）？

Late Interaction 是 ColBERT 提出的思想，也被 ColPali 继承：

普通双塔模型：
query → [一个向量]    doc → [一个向量]    → 算一次相似度

Late Interaction：
query token1 ─┐
query token2 ─┼→ 分别和 doc 的每个 patch 算相似度
query token3 ─┘
                → 聚合所有 token-patch 相似度得到最终分数

好处：能定位到文档中具体哪个区域和 query 相关，比如”左下角的表格”。

4. 代码里为什么要把 PDF 页面存成 base64？

因为 ColPali 检索返回的是最相关页面的索引/id，而不是页面内容。要让人或多模态 LLM 看到这一页，必须从索引里把原始图像还原出来。

base64 就是原始页面图像的编码形式。入库时 store_collection_with_index=True 会把每页图片以 base64 存进索引；检索时用 base64.b64decode() 解码回图片。

5. ColPali 检索回来的是什么？能直接当答案吗？

检索回来的是页面图像（以 base64 编码），不能直接当答案。

需要再经过一步：把解码后的图片传给多模态 LLM（如 Gemini、Qwen-VL），让 LLM 看图并回答问题。

完整链路：

ColPali 负责"找哪一页" → 多模态 LLM 负责"读懂这一页"

6. ColPali 最适合什么场景？

适合以下文档类型：

• 学术论文（包含公式、图表、架构图）
• 财报/年报（大量表格和可视化）
• 产品说明书/手册（图文混排）
• 扫描件/手写笔记
• 任何 OCR 效果差或版式复杂的文档

如果文档是纯文字且版式简单，传统文本 RAG 更便宜、更成熟。

7. ColPali 的主要局限是什么？

1. 检索粒度是页：无法精确到某一段文字；
2. 索引体积大：要存图片 base64 和视觉特征；
3. 依赖多模态 LLM：检索后必须再调一次大模型读图；
4. 不支持跨页推理：答案分散在多页时需要额外处理；
5. 计算成本高：视觉编码比文本编码慢且贵。

8. 整个 pipeline 里各组件分别负责什么？

核心 Insight

掌握 ColPali 的标志是：能清晰地区分三个层次：

1. 检索层（ColPali）：用视觉特征找页面；
2. 存储层（base64 + 向量索引）：保存页面图像和特征；
3. 生成层（多模态 LLM）：读懂返回的图片并回答问题。

ColPali 只负责找图，看懂图的是后面的多模态 LLM。

相关技术

• [[raptor-summary]]：用主题树组织文档
• [[proposition-chunking-summary]]：把文档拆成原子化事实
• [[query-transformations-summary]]：改写问题提高检索匹配度

Proposition Chunking 不是简单地改写句子，而是把文档拆解成原子化、自包含的事实单元，让每个检索单元只表达一个明确事实，从而提高被相关 query 命中的概率。

2. 核心动机

传统 chunking 关注的是”切多大”，Proposition Chunking 关注的是”切多细”。

向量检索的效果很大程度上取决于检索单元的语义纯度：

• 长句/长段落包含多个事实，向量会被稀释；
• 代词和指代让单独句子语义不完整；
• 过渡词、修饰语占用 embedding 空间但不贡献事实。

Proposition Chunking 用 LLM 把文本变成一条条独立事实，解决这些问题。

3. 完整流程

原始文档
    ↓
RecursiveCharacterTextSplitter 切 chunk（控制 LLM 输入长度）
    ↓
LLM 把每个 chunk 拆成多个 propositions
    ↓
LLM 对每个 proposition 从 4 个维度打分
    ↓
低于阈值的命题丢弃
    ↓
命题嵌入向量库（FAISS）
    ↓
检索并对比：命题检索 vs 原始 chunk 检索

4. 什么是好的 Proposition？

好的命题满足：

1. 表达单一事实：一个命题一个 claim；
2. 自包含：无需上下文即可理解；
3. 用全称不用代词：避免 He/It/This 等模糊指代；
4. 包含必要细节：时间、地点、限定词；
5. 一个主谓关系：不含复杂从句或连词。

示例：

原文：
Brian Chesky, co-founder of Airbnb, shared his experience of being advised to run the company in a traditional managerial style, which led to poor outcomes. He eventually found success by adopting a different approach, influenced by how Steve Jobs managed Apple.

命题：
- Brian Chesky is a co-founder of Airbnb.
- Brian Chesky was advised to run Airbnb in a traditional managerial style.
- Running Airbnb in a traditional managerial style led to poor outcomes.
- Brian Chesky adopted a different approach to running Airbnb.
- Steve Jobs' management style at Apple influenced Brian Chesky's approach.

5. 质量检查

每个命题从四个维度 1–10 打分：

• Accuracy：是否忠实反映原文；
• Clarity：是否无需上下文即可理解；
• Completeness：是否包含必要细节；
• Conciseness：是否简洁不冗余。

低于阈值（如 7 分）的命题会被丢弃。

6. 为什么第一步不直接用句子切分？

用 。 切句子确实语义边界清晰，但直接作为 LLM 输入有问题：

RecursiveCharacterTextSplitter 默认会优先按段落、行、空格切分，只在必要时才切断句子，是在语义连贯性和 token 预算之间取折中。

如果想让句子优先不被切断，可以自定义分隔符：

text_splitter = RecursiveCharacterTextSplitter.from_tiktoken_encoder(
    chunk_size=200,
    chunk_overlap=50,
    separators=["\n\n", "。", "！", "？", "\n", " ", ""]
)

7. 与原始 Chunk 检索的对比

8. 成本与收益的权衡

Proposition Chunking 的代价：

• 每个 chunk 都要调用 LLM 生成命题；
• 每个命题都要调用 LLM 打分；
• 索引构建成本高。

收益：

• 在线检索更精确；
• 检索单元直接对应事实；
• 特别适合问答型 RAG。

9. 与 Query Rewriting 的关系

• Query Rewriting：改的是问题，让问题更容易匹配文档；
• Proposition Chunking：改的是文档，让文档更容易匹配问题。

两者方向相反，目标一致。理想情况下可以组合使用。

10. 一句话总结

Proposition Chunking = 把文档拆成原子化事实，让检索从”匹配文本块”升级为”匹配事实”。

11. 相关技术

• [[query-transformations-summary]]：改问题来提高检索匹配度
• [[raptor-summary]]：用主题树组织文档
• [[contextual-compression-summary]]：检索后再压缩噪声