长PDF切段检索还是整份通读？覆盖范围与耗豆的对照评测
查一个具体数字，相关片段可能足够；列出全文交付要求，需要覆盖全部相关章节。 通读的价值在覆盖范围，代价是输入通常更多。本次同一模型、同一问题的受控对照中，三节输入覆盖3/6项，全文输入覆盖6/6项；按下文注明的代码费率快照计算，分别为157豆和1958豆。这不是线上账户的实际扣费记录，也不是所有长PDF的固定价格。
上传整份文档，直接问全文要点。不用先选模式；系统会判断是否自动通读，预计消耗较高时先确认。回答后检查“已读完整份文档”提示，并核对关键要求。
先看对照条件：测输入范围，不给模型排名
我们在2026年10月12日构造一份84节、19,964字符的虚构招标文本，把6项交付要求放在第3、17、32、48、66、82节。两组均调用 deepseek-flash，关闭思考、temperature为0、最多输出3000 token；问题相同，明确要求列出六类交付事项。
三节组人为选定第3、17、32节，全文组输入全部84节。每组一次，两次都正常结束。原文六项要求逐项核对后，三节组缺手册、回收与备件，全文组全部覆盖。
这不是生产检索管线的A/B测试：没有测线上检索能否找到某节，没有经过PDF解析，也没有测试自动通读是否触发。它用实际模型回答展示“少量片段输入”和“全文输入”的区别。不能把3/6当成当前产品检索准确率，或把6/6当成通读保证。
这几类问题，区别在哪里
| 问题 | 相关片段能做什么 | 全文输入多解决什么 | 还需核对什么 |
|---|---|---|---|
| “第17节试运行几天？” | 找到该节即可回答 | 本样例没有额外必要性 | 单位是工作日，起点是初验后 |
| “列出全文全部交付义务” | 未取到的章节可能缺项 | 跨章节要求有机会一起进入答案 | 是否遗漏附件或后文限定 |
| “手册要求是否存在？” | 没检索到不能证明不存在 | 可在更完整范围内检查 | 解析是否漏了表格或扫描页 |
| “三份文件合成一张交付表” | 局部答案难以证明每份都覆盖 | 可先逐份通读，再对齐 | 文件名、版本与要求来源不能丢 |
除“全文交付义务”外，表中是基于任务范围的用法分析，不是本轮额外跑过的测试。具体问一条信息时，不必为了看到通读提示而每次都要求总结全文。
耗豆对比：先公开token，再说明用哪套费率
接口实际返回如下，两次均无缓存命中：
| 本轮实测 | 输入token | 命中缓存token | 输出token | 完成情况 |
|---|---|---|---|---|
| 三节输入 | 480 | 0 | 142 | 正常结束 |
| 全文输入 | 11732 | 0 | 331 | 正常结束 |
输入包含材料、问题和系统提示，不是把汉字数乘固定比例。两组输出长度不同，因全文组还回答了另外三项，并对备件作了重复说明。
计算依据是chat-server主分支快照 c5ef554a88fb2463694dd0dd6872e0816f8b64b7 的 src/services/user.ts：modelTieredRateMap 中 deepseek/deepseek-flash 的输入未命中费率为0.15豆/token、缓存命中为0.01豆/token、输出为0.6豆/token；consumeBeans 在具备token明细且无插件、无显式计数覆盖时按这三档加总，最后 Math.round 四舍五入。
公式为：
豆数 = round(未命中输入 × 0.15 + 缓存命中输入 × 0.01 + 输出 × 0.6)
三节 = round(480 × 0.15 + 0 × 0.01 + 142 × 0.6) = 157
全文 = round(11732 × 0.15 + 0 × 0.01 + 331 × 0.6) = 1958
差额 = 1801豆；全文约为三节的12.5倍
这只是实测usage按特定费率快照的换算。本次直连模型，未经过不墨账户消费接口，没有产生可用于验收的账户扣豆记录；也未证实当前线上服务端与该提交完全一致。写作时另有尚未合并的计费修改，因此不将快照数值当成长期报价。实际使用以当时页面提示和账户明细为准。
不能由本次约12.5倍推导“通读固定贵12.5倍”。文档长度、历史对话、模型、输出长度和缓存都可能改变差额；本次没有测扫描件、表格密集PDF或多轮追问。也不将豆数换算成固定人民币价格。
缓存为什么会改变对比？这里单独做一个假设
只为说明上面公式，假设全文组的11732个输入token中有10000个命中缓存，输出仍为331个token，按同一快照：
round(1732 × 0.15 + 10000 × 0.01 + 331 × 0.6) = 558豆
这是算术情景，不是第三次实测；不承诺第二问一定有缓存，也不承诺修改问题后还能命中相同数量。省豆判断应看账户记录，不能按“同一文件问过一次”就假定后续全部免费。
对实际使用的评测结论
本样例的全文输入多花了1801个“按快照换算的豆”，多覆盖了3项预设要求。若目标是交付清单，这个范围差异有价值；若只查试运行天数，三节组已经正确给出了9个工作日及起算条件。选择应由问题需要决定，不能只比一次回答的总消耗。
在不墨里完成一轮核查只需三步：上传并等解析；直接问需要的范围；检查通读提示和原文。没有模式开关。自动通读的首版只支持一次送入模型，材料超出可读范围时要拆分；解析上限也不等于一次通读容量。
多份文件可以逐份问“列出本文件全部交付要求，标明文件名与出处”，再把核对过的表合并。不要只检查最后一个回答的成功提示，就默认所有文件都完整读过；合并后的重复项和矛盾条件仍要回看原文。
详细上传与排查步骤见DeepSeek读取PDF、Word、Excel。开始时用一份能自己核对的小材料，确认输入范围和回答依据，再扩大到长文件。