结构化索引

为什么把原始文档直接放进知识库不够？

案例一（黑猫白猫计数）: 知识库有 100 个独立案例文档（90 只黑猫、10 只白猫，各为一个文本块），用户问“比例是多少”时受 top-k（如 20）限制大部分案例不会被检索到;
案例一的后果: 模型只能基于不完整样本（如 15 只黑猫、3 只白猫）得出错误结论;
案例一的解法: 预先生成摘要“共有 100 只猫：90 只黑猫（90%）和 10 只白猫（10%）”并索引，一次检索即可获得准确信息;
案例二（Xfinity 优惠资格）: 知识库是几百条客服工单，每条只写清一个个案的结论（退伍军人 John 通过、医生 Sarah 拿到折扣、教师 Mike 不符合），没有任何一条写着资格范围本身;
障碍一最近邻偏置: “护士”与“医生”语义最近，Sarah 那条排在最前，模型顺势推断护士也可以；若 Mike 那条排得更前，同一个问题会得到相反答案;
障碍二边界语义缺失: “仅限……，其他一律不适用”这种带全称与否定的边界不存在于任何单条工单中，调大 k 也解决不了;
障碍三完整性信号缺失: 模型无从判断自己是否已看全，于是不会追问，只照着手里这几条自信作答;
案例二的解法: 离线通读整个工单库，提炼出规则卡“Xfinity 优惠适用于现役与退伍军人、持证医护人员（含护士）；教师等其他职业不适用”;

结论: 把原始案例或文档不加处理地直接放进知识库远远不够——无论存入向量数据库、检索后注入上下文，还是直接塞进长上下文，未经提炼和结构化的知识模型都无法可靠利用;
对策: 必须在索引阶段投入计算资源，对原始知识主动提炼、抽象和结构化;
两个方向: 把“100 个个体案例”压缩为统计摘要；把“散落在几百条工单里的个案”提炼为带边界的明确规则;
定位: 结构化索引的思路是索引前先用 LLM 把知识整理一遍——归纳、抽象、建立关联，用额外计算换更好的检索质量;

全称: Recursive Abstractive Processing for Tree-Organized Retrieval，自下而上的递归抽象;
第一步: 将长文档切分为小的文本块作为“叶子节点”;
第二步: 用聚类算法把语义相近的叶子节点分组——算法计算文本块之间的相似度，把最相似的归为一类，每一类代表一个主题;
例子: 关于 SSE 指令的多个叶子节点（“SSE2 支持 128 位整数运算”“SSE4.1 新增字符串比较指令”）被聚到同一组，系统自动生成父节点摘要“x86 SIMD 指令集的各代演进”;
第三步: 用语言模型为每个分组生成更高层次的摘要作为父节点，过程不断递归，最终形成从具体细节（叶子）到高度概括（根）的知识树;
收益: 检索可在多个抽象层次上进行，既能精确回答细节问题，也能提供对宏观概念的理解;

建模: 把文档知识建模为实体（Entities）与关系（Relationships）构成的知识图谱;
基本单元: 实体—关系—实体三元组（Triple），用“主语-关系-宾语”表达一条知识，如（北京, 是首都, 中国）、（张三, 就职于, 腾讯）;
构建: 先用 LLM 从文本中提取关键实体（人物、地点、概念、术语）与实体间关系，再用社区发现（Community Detection）算法找出语义紧密的实体集群并生成摘要，自动发现主题聚类形成思维导图;

多跳关系推理: 用户问“我的医生所在医院的地址”时，系统需依次解析“用户 → 医生 → 医院 → 地址”这条关系链;
多跳对比: 扁平化记忆存储中这类查询要么需多次独立检索再由 LLM 拼接（效率低且容易断链），要么无法表达；图结构天然支持沿关系边遍历，既高效又可靠;
实体消歧: 与前文稠密嵌入讨论的“一词多义”不同——判断“bank”指河岸还是银行是词义消歧（Word Sense Disambiguation），靠上下文感知嵌入即可解决;
实体消歧的对象: 区分现实世界中两个同名的“张医生”，需要维护关于实体本身的知识;
图谱中的消歧: （张医生-A, 科室, 牙科）与（张医生-B, 科室, 心脏科）是图中不同节点，通过各自关系边连接不同的人与机构，消歧成为图结构的原生能力，无需额外推理;
对照: Advanced JSON Cards 靠 person、relationship 等人工设计字段完成同样的区分，见用户记忆的四种存储格式;

语义降级: 把自然语言转为三元组不可避免——“如果下周还下雨，我就取消去海边的计划，改成去博物馆”包含条件判断与时间依赖，分解后只剩孤立事实（我, 有计划, 海滩旅行）与（我, 有备选计划, 博物馆旅行），核心条件逻辑与时间依赖全部丢失;
准确性风险: 三元组提取高度依赖 LLM 的理解能力，错误提取会导致知识污染;
推荐策略: 分层互补——以完整自然语言保存核心信息（保留语义完整性），辅以结构化元数据做索引和检索（兼顾查询效率）;
垂直场景: 需要多跳推理和精确消歧时（医疗问诊、法律案件分析、家族关系管理），把知识图谱作为专项索引手段，与自然语言记忆协同工作;

够用的场景: 查询主要是“找到包含某信息的文档片段”（如“退款政策是什么”）时，混合检索就够了;
值得投入的场景: 查询经常需要跨文档综合（如“CPU 的 SSE 指令集和 AVX 指令集在架构上有什么区别”）或多层次导航（如“从整体架构到具体指令的逐步深入”）;
代价: 相比简单混合检索，结构化索引在索引构建和查询时都需要更多次 LLM 调用，成本和延迟都显著增加;
实验观察: 以查询“请解释 SSE 指令集”为例，RAPTOR 进行“跨层穿梭”（先在高层摘要定位“SIMD 指令集”宏观概念，再沿树向下钻取到叶子节点的详细描述），GraphRAG 在“关系网”中漫游（定位“SSE”实体，遍历关系边找到“XMM 寄存器”“浮点运算”及 ADDPS 等具体指令，并从所在社区给出架构位置上下文）;
实验结论: RAPTOR 适合“从概念逐步钻进细节”的查询，GraphRAG 适合“A 和 B 之间是什么关系”的查询，生产场景组合使用通常比单选一种更好;