四种 PageIndex 检索方案的 Token 消耗对比

Thu, 09 Jul 2026 15:21:34 +0800

背景链接到标题

PageIndex 是一个无向量（vectorless）、基于推理（reasoning-based）的 RAG 框架。核心思路是将文档解析为树状索引，让 LLM 通过推理来导航定位内容，而不是靠向量相似度搜索。

这次实验的数据源是一本人教版《物理必修第二册》扫描版 PDF。因为纯扫描件没有文字层，先用 MinerU（vlm-engine）OCR 提取了结构化文本，再插入  标记以使页码可追溯。最后用 PageIndex 对这份带页码的 markdown 建立树索引。

基于同一份数据，实现了四种检索方案，对比它们的实现差异和 Token 消耗。

两步走，两次独立 LLM 调用：

LLM #1 看树结构 → 返回行号范围
LLM #2 取内容 → 回答

没有验证步骤，LLM 一次定生死。

三步走，三次独立 LLM 调用：

LLM #1 identify_ranges → 返回候选行号列表
LLM #2 evaluate → 判断内容是否包含答案
LLM #3 final_answer → 基于内容给出最终回答

写了 for 循环遍历候选清单，显式 evaluate 确认命中后才回答。

Fri, 19 Jun 2026 20:14:37 +0800

用《杜骗新书》“假馬脫緞"一文测试本地 LLM 的文言文翻译能力，记录上下文配置和多模型对比过程。

Ollama 默认 num_ctx=2048，客户端设到 4096 仍然不够。日志：

slot release: stop processing: n_tokens = 4095, truncated = 1

prompt 占 ~1000 tokens，只剩 3000 给生成，翻译到一半就被截断。

客户端不支持按模型调参时，在 Ollama 服务端创建定制模型即可：

echo 'FROM gemma4:12b
PARAMETER num_ctx 16384' > gemma4-16k.Modelfile

ollama create gemma4:12b-16k -f gemma4-16k.Modelfile

模型	模型大小	每 token KV cache	建议上下文
qwen3.5:9b	6.6 GB	~32 KB	128K
gpt-oss-abliterated:20b	13 GB	~34 KB	64K
gemma4:12b	7.4 GB	~448 KB	16K

Gemma4 的 KV 投影维度 512 per head，48 层中 40 层为 8 KV heads，导致 KV cache 开销远大于前两者。但滑动窗口层（8 层 1 KV head）用环形缓冲区节省了空间。