目录
介绍
PIKE-RAG是 “sPecIalized KnowledgE and Rationale Augmented Generation”(专领域知识与推理增强生成)的缩写,由微软推出,它通过专注于提取、理解和应用领域特定的知识,并构建推理逻辑来逐步引导大型语言模型(LLMs)生成准确答案,解决传统 RAG 系统在复杂工业应用中的局限。
Chunk流程
1. 数据准备
在data/biology/contents目录下放待解析文件,例如:

2. chunking.yaml
修改examples/biology/configs/chunking.yml(点击展开)
由于使用的素材是中文的,这里的prompt也使用对应官方的。更改后的配置文件如下:
1 | # Environment Variable Setting |
1 | # 运行: |
3. split_documents
进入文档切分流程:

4. first_chunk_summary
对第一个chunk进行summary(点击展开)
1 | # 原文来源 |

输出第一个chunk对应的chunk_summary(点击展开)
1 | 1. 招标编号:皖E0-51-2025-0160 |

5. resplit_chunk_and_generate_summary
对chunk进行重新切分和生成对应summary(点击展开):
1 | # 原文来源 |

6. 第一个完整的chunk
第一个完整的chunk内容(点击展开)
1 | 一、招标编号:皖E0-51-2025-0160 |

并且在原文中可以高亮:

接着根据输出的Line Number来算对应的dropped_len,下一次的text=text[dropped_len:]
。

chunk流程总结
- 使用Text Splitter对text(原文)进行初次切分,得到
chunks
。 - 对
chunk[1]
进行总结得到chunk summary
。 - 基于
chunk summary
+(chunk[1] + chunk[2])
得到based llm chunk
、current llm chunk summary
、下一个chunk的summary
,此时的text=text[dropped_len:]
。 - 以
下一个chunk的summary
作为新一轮的chunk summary
, 重复步骤3,直至获取所有切片。
与传统基于固定字符数切分不同,PIKE-RAG 的切分过程是一个滚动窗口
+语义引导
的迭代过程。它先生成chunk summary
,再利用summary
+下一段文本
判断切分边界并生成新的chunk
,直到文本处理完毕。这保证了chunk间的上下文衔接,并让后续的Atomic Question Tagging
更精准。
注意:我们可以看到,每次的切分是动态的,但是每次切分的chunk_size是固定的。
至此我们屡清了基于LLM来做Chunk(LLMPoweredRecursiveSplitter)的流程,但同时我们也可以看到,基于LLM来做Chunk切分很考验LLM的理解能力。你可以从这里下载精简后代码。
Atomic Question Tagging
流程
入口:

对这段内容生成尽可能多的可以回答的问题:

总结
用deepseek-chat模型来生成question,虽不会出现例如prompt中简单的他她它
这种,但是仍然会存在不完善的情况,例如:
1 | 招标代理机构的名称是什么? |
而这种不完善的情况就会导致下游在召回时带来更多影响,而ChatGPT效果会更好些。。
所以生成的question质量直接决定了召回的粒度和准确度,因为下游检索完全依赖这个问题库来定位相关chunk。
QA
入口和整体流程


1. propose question decomposition(对用户输入的问题进行分解)
分解query提示词(点击展开):
1 | # Task |

至此拿到用户输入question分解后的子问题,当然子问题是可以为空的,如果为空:
- 说明这个子问题无法能够继续拆分了,但是这里并不成立。
- 更可能在于基于已经给的
{chosen_context}
能够回答用户问题,如果{chosen_context}
为空,那肯定会进行拆分子问题的。
所以这一步结果为空,则直接进入回复用户问题阶段,不会走下面流程了。
2. Retrieve relevant atom information(召回相关chunk)

2.1 基于用户question生成的sub-questions进行召回

这里流程简述如下:
step1: 例如当用户问,
当黄庄遭遇百年一遇洪水时,丹江口如何调度?
得到的sub-questions如下:
1 | { |
step2: 对于每一个sub_questions,对Atomic Question Tagging
生成的question库进行召回。例如每个限制返回个数为4,那么可以上述10个sub_questions可以返回40个搜索结果,由于Atomic Question Tagging
生成的question库会包含每个question从哪个chunk进行生成的,所以也会返回这些chunks信息。
2.2 Backup retrieval1
如果没有sub-questions,则用用户query直接到questions库去搜。
2.3 Backup retrieval2
如果前面两步搜索还是空,则是query to document这种搜索了。
3. 让大模型决定搜索结果
对sub-questions进行筛选(点击展开)
1 | # Task |


总结:
- 根据召回的sub-questions,来让LLM决定哪一条sub-question对回答用户问题有帮助。(为啥只选择一条sub-question?)
- 如果LLM一条也不选择,那就走备选prompt,备选prompt是将这些sub-questions对应的chunks给LLM,让其选择一条最合适的chunk(chunk同时也包含了sub-question以及chunk_id等信息,所以又相当是获取了sub-question)。
- 注意:每个prompt都有
chosen_context
这一部分,其核心目的是我已经选择了哪些相关context,你(LLM)要基于我已经选择的进行思考再决定选择新的chunk来塞入context。 - 重复这个过程,达到设置循环次数,最终将用户提出的question和获取到的
chosen_context
来交由LLM进行最终回复。(至此我们也看到了另外一个ReAct思想实现,基于每次sub-question返回的chunk,来决定下次选择哪个新的sub-question以及chunk)。
备选prompt(点击展开)
1 | # Task |
总结
至此我们完成了这三个部分的分析,如果有什么不对之处还请多指出~。