交接 · 知识库分块：两项补查 + 单章 A/B 对照（2026-10-02 续）

上一轮：工作区\交接-知识库修复与EPUB碎块-20261002.md（重排修复、碎块根因、723 块候选方案）。 本轮做的是 ChatGPT 回复里要求的补查与单章对照测试。全部结论均为本机实测，命令与产物路径见文末。

一、补查 1：阅读顺序 —— 本机数据「ZIP 顺序恰好等于 spine 顺序」，但实现的正确性是偶然的

实测（脚本 _tmp\epub_spine_check.py，直接读 content.opf）：

META-INF/container.xml → rootfile OEBPS/content.opf
manifest 251 项 = xhtml 29 + image/jpeg 219 + css 2 + ncx 1
spine itemref = 29，顺序 text00000.html … text00028.html
ZIP 内 29 个 html 的字母序      = text00000.html … text00028.html
两者顺序完全一致：True        集合一致：True

结论要限定范围：

二、补查 2：219 张图 ↔ 217 个占位 —— 差异是两个「结构性图片」，不是丢失

实测（_tmp\epub_img_refs.py）：

ZIP 内 .jpg 文件        219 个，编号 Image00000–00219，其中 00218 缺号（共 219 个 = 0..219 去掉 218）
HTML 中 <img> 标签      217 个，对应 217 个不同文件名（无重复引用）
孤儿图片（存在但无 <img> 引用） Image00217.jpg、Image00219.jpg
存档文本图片占位 ![](ImageNNNNN.jpg) 217 个，使用的文件名最大到 Image00216.jpg

两个孤儿的身份（content.opf manifest 属性 + 引用关系）：

逐项对应：217 个占位 ↔ 217 个 <img>，文件名一一对应，无缺失、无多余、无重复。差 2 = 封面 1 + 封底类 1。

顺带核到的可访问性（此前未测）：

三、补查 3（顺带修正）：真实字符预算是 1824，不是 1280

按插件自己的口径复算（chunkSize=800、chunkOverlap=100、smartChunk=true）：

normalizeText 后长度 283093；estimateTokens(ck/1.5 + 其他/4) = 124162
charsPerToken = 2.2800  →  safeSize = round(800×2.28) = 1824 字符，safeOverlap = 228

上一轮交接里「折算 1280 字符」需更正为 1824。对结论无实质影响（现状仍是 0 个块超限），但后续拆分阈值要按 1824 判断。

四、复刻：抽取链路第一次做到与库内逐字一致

写了两版抽取器，第二版才对齐（差异全在非 <p> 结构上）：

抽取器同时输出可追溯字段：page（原始 XHTML）、elemIndex（页内第几个 <p>）、id（如 filepos203143）、class、spans、images。这满足「每块能定位到版本、章节、原 XHTML/锚点」的要求。

五、单章 A/B 对照：结论是「分块必须落在插件解析层，Markdown 聚合会被入库时重新切掉」

按上轮 §五.2 的做法执行：第三章（手太阴经络与腧穴，text00011.html），两个临时库、同一套嵌入/重排/检索参数。

文件与库：

关键实测：B 的源文件本来就是 20 片，但入库后仍变成 184 块 —— 因为插件的 splitBlocks 按空行分段，B 片内部为了保留段落结构必然留有换行分隔，于是入库时被重新切开；我为超预算穴位条目加的「章·节」来源前缀也因此被单独切成了 第三章手太阴经络与腧穴 · 第二节 手太阴腧穴 这种小片（库内块 134/142/175 实测）。

也就是说：

1. 在 Markdown 层面聚合无法改变入库块边界 —— 只要走「导入文件」这条路，splitBlocks 就按空行把聚合拆回去。
2. 想让「章 → 节 → 穴位条目 → 字段」真正成为块边界，只有两条路：

• 改插件 parseEpub / splitBlocks：让 EPUB 解析按 OPF spine + 元素结构产出块（推荐，一次到位，且能顺带修 §一 的 spine 问题）；
• 或走文本导入通道并在导入前把单元内的空行全部消掉（能保住单元原子性，但章节内段落层级会被压平，需另存结构元数据）。

1. 现状策略 A 的检索并不差：12–20 道本章问题（穴位定位、主治、循行、络脉、经别、经筋、脚注引文）两库 TopK=4 结果几乎一致，B 只在个别题上把正确条目提到第 2 位（如「天府 定位」A 的第 2 位是无关的「取法：先确定云门…」（0.700），B 是正确【定位】（0.998））。检索退步没有出现，噪声下降很轻微。

六、结构优先分块的量化效果（在同一份解析文本上，纯离线计算）

在同一 6535 块基线上按 §五 规则离线重排（_tmp\seg_v9.py）：

（注：401 是全书穴位条目数，与单章 A/B 的 11 个不矛盾。）

七、下一步建议（未动手）

1. 先定路线：是否允许改插件 dsh-knowledge（改 parseEpub 读 spine + 按元素层级切块）。这是唯一能让结构优先真正生效的位置；插件升级会覆盖改动，需记录还原点。
2. 若暂不改插件：可先把 A/B 测试扩到 3–5 章 + 全书离线评估，用 §六 的离线指标证明收益，再决定。
3. 图片文字仍按上轮 §五.3 分类处理（字形/正文/注释图提字核对；经络示意图描述另存并标注；封面装饰图保留资源不生成图注）；imageCaptionProvider=off，尚未启用。
4. 原 EPUB、原「中医新」库、旧「中医」库均未改动。
5. 临时库（_tmp-策略验证-可删、_tmp-第三章策略A/B）用完即删。

八、本轮产物（均在 工作区\_tmp\，未清理）

凭据提醒（上轮遗留未处理）：GET /knowledge/config 与 GET /knowledge/bases 会把嵌入/重排/图注/mi​​neru 的 key 明文返回；本机环回口暂无鉴权。本轮未把任何 key 写入文件或回复。