刚刚在整理检索中的问题分类最开始我是分成了简单的事实/细节查询总结/宏观查询和多跳推理查询结果发现目前还存在一些设计上的缺漏要补上这个分类也要调整一下。首先是这个多跳推理我们这个项目是个人金融分析师助手涉及多agent协作前面的顶层路由器设计也区分了问题的标签根据问题复杂度划分为可以直答的要调用一次工具的以及调用多次工具的。那么多跳推理在这里面会被划分到多工具调用中然后被分析agent划分成多个子问题每个问题都是基本事实查询所以即便调用了rag工具那也只是基本事实查询不会涉及多跳这个标签可以去掉。然后就是总结/宏观查询这个要求我们维护一个目录树前面增强版json中有增加section_path这个天然支持目录树维护的属性然后每个section我们都要去生成一个summary层层向上到最后生成顶层摘要之后问题如果被归类为总结/宏观查询我们就可以直接来这个目录树上查询。这样做有很多好处最明显的就是用户如果经常问某个章节的摘要我们不可能每次都去让多智能体拆分成每一章每一节然后将全文都塞入总结这是非常耗费token的成本非常高而建立了目录树可以让智能体根据目录树决策相关的段落然后再去里面调用rag工具增加精确度。所以我们在chunk生成完之后生成向量的同时要开始生成目录树。知识库检索工具 kb_rag 封装经过前面的分析到了调用rag工具时没有多跳推理我们只需要关注事实查询和宏观总结查询。对于事实查询我打算使用hyde来回答问题之后以这个答案来进行关键词命中和稠密计算当然鉴于金融的独特性专有名词层出不穷所以对于hyde的提示词我会让llm回答的同时尽可能地将专有名词扩充充当一个splade的作用但是减去了splade的长耗时。当然这个肯定还是比不过专用的splade模型的使用splade我们如果对其进行剪枝操作还是可以大幅度缩短耗时的。所以我总共会设计三路dense, hyde_dense, hyde_bm25各返回top100然后进行融合排名凸组合算法可以等项目跑起来有了数据我们去调优那个参数之后再使用所以目前先用rrf返回top50之后将子块映射到父块并去重后续重排多样性都靠父块来进行rrf找出的是相关性而相关却有可能高度同质这种情况也需要警惕我们引入MMR最大边际收益通过计算块之间的相似度将高相似度的去掉保留低于阈值的块确保多样性。之后则使用reranker重排得到最终结果当然最后块的放置这些也要考虑提示词工程U型模型注意力曲线将chunk放到prompt的首尾。这是最初的设计没有使用colbert我们是个人聊天助手延迟方面可以稍微放缓一些所以可以适当的追求精确度。同时针对总结/宏观的查询我们就要用前面提到的目录树设计通过路由器确定是哪一章或者是总体的概要方便sql查询当然由于是摘要可能会太少我们可以降级到前面讲的事实查询链路去搜寻对应section下的父块。大致工作流如下内部实现 query已经由llm确认要用rag了所以这里主要区分问题类型 └── 路由器(r1正则/长度 r2相似度 r3LLM) ├── A:事实/细节查询 - hyde bm25, dense, hyde dense -[每路返回top100]- rrf -[top50]- 先把子块映射到父块并去重后续使用父块 - mmr -[top20若剩余过多则截断到20按照阈值去重]- bge-reranker-v2-m3重排 -[top5]- 将最终的chunk放到提示词的首尾利用U型曲线 └── B:总结/宏观查询 -[将目录树喂给LLM]- 确定SQL语句到底要查啥是具体的章节还是全文概览因为有可能有模糊主题所以需要LLM来识别需要哪些章节 └─[兜底]─当 LLM 选出的章节摘要太短、或用户追问细节时降级为“带 section 过滤的 A 链路”WHERE section_path LIKE X% 的混合检索附件检索工具 attachment_rag 封装知识库跟附件的区别也就是差在附件是临时的在会话中处理比较粗糙力求能回复而知识库要求精细检索什么的都要设计仔细一些前面几篇文章中已经把附件知识库的数据流基本上都设计完啦我们会发现大部分都差不多就是可以复用。在这个检索工具的设计上也是差不多同样的路由器同样的query分类标签。数据流如下A类标签事实查询的相关细节就是前面设计的信息包相关。attachment_rag(query, 信号包) | ├── 路由器(复用KB: r1正则/长度 → r2目录相似度 → r3LLM) ── 区分A/B | ├── [A 事实/细节] 语料装配(单次混合检索): | ├── 语义路: 向量库 top-k, filter file_key IN semantic_scope | ├── 关键词路: BM25 over chunks, filter file_key IN bm25_scope | └── 融合(RRF) ── 重排 ── top-5 | ├── [B 总结/宏观] 目录树查询(scope限定): | ├── scope内小文件(tiercontext): 不查树, 全文已在stuff_texts, LLM直接总结 | └── scope内大文件(tierindex): 查 section_summaries(file_id IN scope) | ├── 全文概览 → level0 根摘要 | ├── 明确章节 → 匹配 section_path | ├── 模糊主题 → LLM 从该file目录菜单选章节 | └── 兜底: 摘要未就绪 → 该file section定向召回(捞父块runtime总结) | ├── 塞入路: stuff_texts 按token预算直接进上下文(优先占预算) | └── 组装: top-k(A) 或 目录摘要(B) stuff_texts skipped/failed名单 ── tool result对了对于bm25前面忘了讨论了我决定使用elasticsearch来自动构建bm25相关索引算法直接倒排即可分词器直接用默认的ik插件。当然各位大佬想自建也行从jieba/pkuseg中挑分词器然后自行构建。由于我们是对子块构建索引属于短文段所以我们的b设置为0.5不用原来的默认0.7配置。增量更新对于增量更新我前面提到过我会在知识库界面每个文档那里都提供重新上传按钮用于增量更新。然后前面设计的时候不是每个block都有计算hash值吗这个要派上用场了。我们不可能在block级别的时候就覆盖不同hash值得文本因为按照这么改不还是后续的分块啊嵌入啊都改变了因为我的文本block都改了随之而来的分块可能要重新划分那么嵌入ES的索引等等都要重新来过那我还不如不覆盖来的好嘞。但是有的东西是特例我们的image/chart/table都是我们去交给vlm模型去意图识别的或者表格转换过嘟交过钱嘟这个可以复用只要hash值没变我们就复用前面增强处理的内容然后其他都重建。大致流程如下用户点更新(同一 file_id) ├─ 新对象存 MinIO → 新 file_key; 更新 files.file_key/size/updated_at ├─ 行锁条件转态 status→processing 拿 doc 锁(复用现有锁纪律) │ └─ statusprocessing 使门控/KB scope 立即隐藏该文件(KB scope 加 statuscompleted 过滤) └─ 重建管线: ① extract → blocks(每块算 content_hash) ② enrich: image/chart/table 类block hash命中 block_cache → 复用 vlm_insight/表格MD 未命中 → 调 VLM → 写 block_cache ③ 事务内 DELETE: child_chunks / parent_chunks / section_summaries WHERE file_id? ES delete_by_query(file_id) ④ chunk → 插 parent/child ⑤ embed → 写向量 ES 批量索引 ⑥ summary → 重建目录树(自顶向下) ⑦ file_tasks.content_hash新值, statuscompleted, 释锁
刚刚在整理检索中的问题分类最开始我是分成了简单的事实/细节查询总结/宏观查询和多跳推理查询结果发现目前还存在一些设计上的缺漏要补上这个分类也要调整一下。首先是这个多跳推理我们这个项目是个人金融分析师助手涉及多agent协作前面的顶层路由器设计也区分了问题的标签根据问题复杂度划分为可以直答的要调用一次工具的以及调用多次工具的。那么多跳推理在这里面会被划分到多工具调用中然后被分析agent划分成多个子问题每个问题都是基本事实查询所以即便调用了rag工具那也只是基本事实查询不会涉及多跳这个标签可以去掉。然后就是总结/宏观查询这个要求我们维护一个目录树前面增强版json中有增加section_path这个天然支持目录树维护的属性然后每个section我们都要去生成一个summary层层向上到最后生成顶层摘要之后问题如果被归类为总结/宏观查询我们就可以直接来这个目录树上查询。这样做有很多好处最明显的就是用户如果经常问某个章节的摘要我们不可能每次都去让多智能体拆分成每一章每一节然后将全文都塞入总结这是非常耗费token的成本非常高而建立了目录树可以让智能体根据目录树决策相关的段落然后再去里面调用rag工具增加精确度。所以我们在chunk生成完之后生成向量的同时要开始生成目录树。知识库检索工具 kb_rag 封装经过前面的分析到了调用rag工具时没有多跳推理我们只需要关注事实查询和宏观总结查询。对于事实查询我打算使用hyde来回答问题之后以这个答案来进行关键词命中和稠密计算当然鉴于金融的独特性专有名词层出不穷所以对于hyde的提示词我会让llm回答的同时尽可能地将专有名词扩充充当一个splade的作用但是减去了splade的长耗时。当然这个肯定还是比不过专用的splade模型的使用splade我们如果对其进行剪枝操作还是可以大幅度缩短耗时的。所以我总共会设计三路dense, hyde_dense, hyde_bm25各返回top100然后进行融合排名凸组合算法可以等项目跑起来有了数据我们去调优那个参数之后再使用所以目前先用rrf返回top50之后将子块映射到父块并去重后续重排多样性都靠父块来进行rrf找出的是相关性而相关却有可能高度同质这种情况也需要警惕我们引入MMR最大边际收益通过计算块之间的相似度将高相似度的去掉保留低于阈值的块确保多样性。之后则使用reranker重排得到最终结果当然最后块的放置这些也要考虑提示词工程U型模型注意力曲线将chunk放到prompt的首尾。这是最初的设计没有使用colbert我们是个人聊天助手延迟方面可以稍微放缓一些所以可以适当的追求精确度。同时针对总结/宏观的查询我们就要用前面提到的目录树设计通过路由器确定是哪一章或者是总体的概要方便sql查询当然由于是摘要可能会太少我们可以降级到前面讲的事实查询链路去搜寻对应section下的父块。大致工作流如下内部实现 query已经由llm确认要用rag了所以这里主要区分问题类型 └── 路由器(r1正则/长度 r2相似度 r3LLM) ├── A:事实/细节查询 - hyde bm25, dense, hyde dense -[每路返回top100]- rrf -[top50]- 先把子块映射到父块并去重后续使用父块 - mmr -[top20若剩余过多则截断到20按照阈值去重]- bge-reranker-v2-m3重排 -[top5]- 将最终的chunk放到提示词的首尾利用U型曲线 └── B:总结/宏观查询 -[将目录树喂给LLM]- 确定SQL语句到底要查啥是具体的章节还是全文概览因为有可能有模糊主题所以需要LLM来识别需要哪些章节 └─[兜底]─当 LLM 选出的章节摘要太短、或用户追问细节时降级为“带 section 过滤的 A 链路”WHERE section_path LIKE X% 的混合检索附件检索工具 attachment_rag 封装知识库跟附件的区别也就是差在附件是临时的在会话中处理比较粗糙力求能回复而知识库要求精细检索什么的都要设计仔细一些前面几篇文章中已经把附件知识库的数据流基本上都设计完啦我们会发现大部分都差不多就是可以复用。在这个检索工具的设计上也是差不多同样的路由器同样的query分类标签。数据流如下A类标签事实查询的相关细节就是前面设计的信息包相关。attachment_rag(query, 信号包) | ├── 路由器(复用KB: r1正则/长度 → r2目录相似度 → r3LLM) ── 区分A/B | ├── [A 事实/细节] 语料装配(单次混合检索): | ├── 语义路: 向量库 top-k, filter file_key IN semantic_scope | ├── 关键词路: BM25 over chunks, filter file_key IN bm25_scope | └── 融合(RRF) ── 重排 ── top-5 | ├── [B 总结/宏观] 目录树查询(scope限定): | ├── scope内小文件(tiercontext): 不查树, 全文已在stuff_texts, LLM直接总结 | └── scope内大文件(tierindex): 查 section_summaries(file_id IN scope) | ├── 全文概览 → level0 根摘要 | ├── 明确章节 → 匹配 section_path | ├── 模糊主题 → LLM 从该file目录菜单选章节 | └── 兜底: 摘要未就绪 → 该file section定向召回(捞父块runtime总结) | ├── 塞入路: stuff_texts 按token预算直接进上下文(优先占预算) | └── 组装: top-k(A) 或 目录摘要(B) stuff_texts skipped/failed名单 ── tool result对了对于bm25前面忘了讨论了我决定使用elasticsearch来自动构建bm25相关索引算法直接倒排即可分词器直接用默认的ik插件。当然各位大佬想自建也行从jieba/pkuseg中挑分词器然后自行构建。由于我们是对子块构建索引属于短文段所以我们的b设置为0.5不用原来的默认0.7配置。增量更新对于增量更新我前面提到过我会在知识库界面每个文档那里都提供重新上传按钮用于增量更新。然后前面设计的时候不是每个block都有计算hash值吗这个要派上用场了。我们不可能在block级别的时候就覆盖不同hash值得文本因为按照这么改不还是后续的分块啊嵌入啊都改变了因为我的文本block都改了随之而来的分块可能要重新划分那么嵌入ES的索引等等都要重新来过那我还不如不覆盖来的好嘞。但是有的东西是特例我们的image/chart/table都是我们去交给vlm模型去意图识别的或者表格转换过嘟交过钱嘟这个可以复用只要hash值没变我们就复用前面增强处理的内容然后其他都重建。大致流程如下用户点更新(同一 file_id) ├─ 新对象存 MinIO → 新 file_key; 更新 files.file_key/size/updated_at ├─ 行锁条件转态 status→processing 拿 doc 锁(复用现有锁纪律) │ └─ statusprocessing 使门控/KB scope 立即隐藏该文件(KB scope 加 statuscompleted 过滤) └─ 重建管线: ① extract → blocks(每块算 content_hash) ② enrich: image/chart/table 类block hash命中 block_cache → 复用 vlm_insight/表格MD 未命中 → 调 VLM → 写 block_cache ③ 事务内 DELETE: child_chunks / parent_chunks / section_summaries WHERE file_id? ES delete_by_query(file_id) ④ chunk → 插 parent/child ⑤ embed → 写向量 ES 批量索引 ⑥ summary → 重建目录树(自顶向下) ⑦ file_tasks.content_hash新值, statuscompleted, 释锁
