技术 · 熟练
长文档问答，一定要先建向量库吗？
瓶颈常常在「切成块」那一步，而不在找答案那一步
给几百页手册做问答，默认动作是先切块、算嵌入、存向量库 —— 但这三步每一步都在丢信息、加部件。一份有章节层级的文档，其实已经把语义分好类了：把这份现成的层级丢掉再让模型从零找回来，是白扔信号。这一页给的是另一条路：先判文档有没有结构，再建一张「章节 → 小节 → 段」的树，让模型在树上先选路径、只把挑中的段落喂回去。顺带去掉两个会漂移的部件：切块参数与嵌入模型。最后用二十个真问题做一次离线对比，再决定要不要上向量库。
方法 · 一图看懂
1
先判你的文档有没有「结构」 — 有目录、有标题层级、章节之间边界清楚的，树形索引天生可用；连段落都没有的散装文本，才轮到切块
2
建一张「章节 → 小节 → 段」的树，而不是先切固定字数的块 — 每个节点写一句摘要，摘要给检索用、原文只给回填用
3
让模型在树上先选路径，再在小节内挑段 — 两级挑选：先挑章节（十选二），再在挑中的小节里挑段，⛔ 不要把整棵树一次喂进去
4
想清楚什么时候仍然需要向量库 — 同义改写多 · 问题与原文用词差得远 · 要跨章节综合 · 文档本身没结构，这四种仍然用向量
5
用二十个真问题做一次离线对比 — 树形 / 向量 / 两者各跑一遍，只比两样：答案对不对、喂回去的字数多少
原理 · 为什么有效
为什么有效 —— 「切块-嵌入-存库」这条默认路线里藏着一个假设：语义相近就等于字面相近（向量近邻）。可长文档里，答案的位置本身就是极强的信号 —— 「这一章讲的是安装，那一章讲的是排错」，标题已经把语义分了类。你先把它切成等长的块，等于把这层已经免费的分类信息亲手抹掉，再让模型从零开始找。第二层机理是部件数：向量这条路多出两个会独立漂移的可动件 —— 切块大小与重叠、以及对嵌入模型本身的依赖（换嵌入模型意味着全量重嵌，这件事拖着不做，检索会悄悄变差而不报错）。去掉它们，等于去掉两个故障点。第三层是成本结构不同：向量路线把成本花在建库那一次（全量嵌入），树形路线把成本花在每次提问上（模型多挑一层）。⇒ 文档稳定、提问频繁的场合，两条都行；文档天天变、提问不频繁的场合，树形明显更省。
适用场景
适用：手上是手册、规范、合同模板、内部制度这类有结构的长文档的人；文档会持续更新、重嵌入成本吃不消的团队；提问量不大、但每次都要准确的人；已经建过一版向量库「答得不准又不知道从哪查」的人。
⛔ 不适用：文档是海量短消息、论坛帖、聊天记录（没有结构可依）；问题与原文用词差得远、必须靠语义近似命中的场合；已经在用向量且效果够好的场景 —— 本条不是「向量不好」，是「不是所有文档都需要向量」。
自测 · 5 问
我的文档有没有现成的章节层级，还是需要我自己先分出结构
我现在这套检索里，有多少个「可动件」——切块大小、重叠字数、嵌入模型版本、索引刷新频率
如果换了嵌入模型，我需要重新处理多少内容、大概多久
我的问题是「术语能对上」的那类，还是「换个说法也要找到」的那类
我有没有一组固定的真问题，能在改检索之前和之后各跑一次
怎么上手 · 验证步骤
按这个顺序做，一次只动一层：
第一步看结构 —— 打开你的目标文档，数一遍它的标题层级到第几层。三层以上 ⇒ 树形可用；只有一层或干脆没有 ⇒ 先别做树。
第二步建树 —— 按章节 → 小节 → 段三层建索引文件，每个节点只写一句摘要（摘要会进检索，原文只负责回填）。这件事可以全交给模型批量做，但你要抽十条核对摘要有没有写偏。
第三步跑对照 —— 准备二十个你真被问过的问题（⛔ 不要用「文档里有什么」这种通用问法），树形与向量各跑一遍，记录「答对没」与「喂回去多少字」。
第四步再定 —— 只有当树形在「同类改写问法」上明显吃亏时，才把向量加回来做混合检索；⛔ 不要两条都上再靠调权重找平衡。
第五步留触发条件 —— 写一行「什么时候该改建向量库」：文档量翻倍、或提问里出现三成以上同义改写，就重跑一次对照。
做完自己核对三件：① 我数得出文档的层级深度，也说得清树是几层 ② 二十个问题上，我能同时给出树形与向量各自的「答对率 + 回填字数」，而不是只凭印象说哪个好 ③ 索引里每个节点的摘要是可读的句子，不是从原文截断的半句。三条缺一条，结论就还不能用。