多模态知识库怎么控制图片输入成本：分辨率、裁剪与上下文预算

把 PDF、产品截图和扫描表单接入多模态知识库后，很多人会踩一个典型误区：认为图片体积越小，输入成本就一定越低。真正影响整体预算的核心要素是任务需要读取的细节粒度：只判断页面类型的场景，先用低细节输入即可；要识别表格小字或票据字段的场景，才值得把局部区域裁剪后交给高细节链路处理。每次检索都直接把整张原图塞进上下文，通常既拖慢响应速度，又平白消耗大量配额。

先确定图片要回答什么问题

图片送入知识库处理前，先把所有请求按目标划分为三类。分类类请求只需要回答“这是不是合同页”；定位类请求需要找到“金额字段在哪一块”；精读类请求则要把小字、表格行列或印章附近的内容完整读出来。三类任务对清晰度的要求差异很大，对应的输入策略也不应完全相同。

• 分类：缩略图或低细节输入足够，输出结果只用于决定后续检索路径。
• 定位：保留页面完整结构，优先裁掉边缘空白和装饰区域。
• 精读：只把命中的局部区域送入高细节阶段，同时保留来源页码和坐标。

OpenAI 的图像输入接口提供了 detail 选项，文档列出 low、high 和 auto。这说明“清晰度选择”是请求参数的一部分，而不是上传前凭文件扩展名猜出来的固定规则。

原图、裁剪图和缩略图怎么选

一张 4000 像素的扫描页，真正有用的内容可能只有右下角的金额表。直接发送整页会把大量空白和无关区域一起带入视觉理解流程；但只保留金额数字对应区域，又可能失去表头、币种和页码，回答看似准确，实际上完全无法回溯校验。

裁剪前保留三个锚点

裁剪精读区域时，至少要保留字段名称、字段值和一个来源锚点。来源锚点可以是页码、章节标题或表格标题。处理表格内容还要保留一行表头，否则模型读到“12800”时无法判断它对应的是含税金额、数量还是流水编号。

type ImageEvidence struct {
    SourcePage string  // 来源页码或章节
    CropBox    [4]int  // x, y, width, height
    Detail     string  // low / high / auto
    Question   string  // 本次视觉任务
}

这套处理逻辑的重点不是调整描述话术，而是把图片处理的决策链路完整记录下来。后续发现答案输出漂移时，可以直接定位是裁剪范围变了，还是 detail 从高细节降成了低细节，不用靠猜测反复重传原图排查。

low、high、auto 的选择边界

low 适合先做路由：判断文档类型、找出可能包含目标字段的页，或者在召回阶段筛掉明显无关的图片。high 更适合小字、复杂表格和局部证据，但不等于“所有问题都应该用 high”。auto 可以作为默认入口，不过上线后仍要用业务样本检查它是否稳定满足精读要求。

一个经过验证的两段式流程是：第一阶段用低成本输入给每页打标签，第二阶段只对命中的两三页做裁剪和高细节复核。这样做的收益不只是省token配额，还能减少无关图片挤占文本上下文空间，让最终输出的回答更容易引用到正确的证据内容。

把上下文预算变成可测的门槛

不要只盯着图片文件的KB数做成本核算。一次请求的总预算至少包含图片数量、每张图片的detail等级、随图附带的关联文本、检索召回的候选段落，以及模型最大输出上限。可以先给每类任务设一个固定配额上限，再同步观察漏读率、错误引用率和平均延迟表现。

budget = image_count * image_policy + text_tokens + output_limit
if budget > request_limit {
    keep_top_k_images()
    crop_to_evidence()
    downgrade_route_images()
}

这里的 image_policy 不应写成跨模型通用的常数。官方资料只说明低细节会使用更少 token，并给出具体接口的处理方式；不同模型、图片比例和服务版本都可能改变实际消耗。生产环境应把请求用量和响应质量放在同一张评测表里，而不是把某个示例数字硬编码成计费公式。

上线前用一组小样本做选择

准备三类各十张测试样本图：文字清晰的电子文档、表格密集的扫描件、带噪点的手机拍摄图。每张图片绑定固定问题和期望输出字段，分别跑缩略图、裁剪图与不同detail等级的组合测试，记录四项结果：

1. 字段识别是否完整，尤其是小数点、负号和单位的识别准确率。
2. 输出答案能否对应回正确页码或裁剪框区域。
3. 平均延迟和单次输入用量是否提前约定的阈值。
4. 识别失败后是否能正常降级到人工复核流程，而不是输出貌似确定的错误答案。

如果低细节输入已经能稳定完成分类任务，就没必要给分类任务默认开启高细节配置；如果高细节模式仍读不清扫描表格内容，优先优化原图方向、裁剪范围和OCR预处理步骤，而不是无限制追加上下文配额。

相关问答：常见误区与速查结论

把文件压小就等于降低模型成本吗？

不一定。压缩操作可能降低传输体积，却可能把图中的小字直接压到无法识别；模型端的视觉处理逻辑和detail选择策略仍要单独评估，不能直接默认压缩就能降本。

裁剪后还需要保存原图吗？

需要。原图用于后续复核和审计，裁剪后的中间图用于当前业务请求。两者要共享稳定的文档ID、页码和裁剪坐标，不能只保存一张没有来源关联的临时图片。

auto 可以替代全部策略吗？

不建议。auto模式适合快速接入验证原型，但对费用敏感或者小字准确率优先级高的生产流程，仍要把关键样本的处理逻辑固定成可复现的测试策略，在模型或服务升级之后重新走回归测试。

结语：先分流，再精读

多模态知识库的图片预算优化，核心不是追求最低分辨率，而是让每张图片只承担它必须完成的任务。分类阶段用轻量输入，命中目标后裁剪证据区域，再对关键字段做高细节复核；同时把页码、裁剪框、detail等级和实际用量完整写入记录，成本与答案质量才能一起稳定下来。