pxpipe Grok 图像压缩的精确召回验证：Image-only 与 Image+Factsheet 契约的实测对比

本文是 pxpipe（通过将文本上下文渲染为图像来削减 Claude Code token 消耗的项目）对 Grok 模型在 OpenAI Responses 路径上的专项验证报告解读。核心要回答的问题是：当 Grok 使用与 Opus 相同的 5×8 高密度字模渲染时，纯图像方案能否逐字精确召回会话中的 token 形状；如果不行，"图像 + verbatim fact-sheet" 的生产契约能否把它救回来，以及为此要付出多少 token 节省率。读完本文，你将理解 pxpipe 的 density sweep 测量方法、factsheet 的提取与预算机制、Grok 保持 opt-in 的产品决策依据，以及如何复现这套 A/B 验证。

一、实验背景：为什么 Grok 需要单独的密度验证

pxpipe 的核心思路是用图像代替文本承载大段上下文（system slab、历史会话、tool_result），从而降低按 token 计费的输入成本。此前eval/opus-density的召回研究覆盖了 Fable 5、Opus 4.8 和 GPT 系列，但 Grok 走的是OpenAI Responses 路径，页面几何与视觉计费方式都和 Anthropic Messages 路径不同，因此需要一个独立的 harness——这正是 eval/grok-density/README.md 里"Why a separate harness"一节说明的动机：Grok 到达 pxpipe 时带着不同的 page geometry 与 vision billing，需要自己的客户端和成本核算；共享的 fixture 与评分规则刻意镜像 Opus harness，保证结果可比。

FACTSHEET_RESULTS.md 记录的是一次live run（2026-07-09，模型grok-4.5，脚本为 factsheet-vs-image.mjs），它只回答一个精确问题：

一个候选方案保留5×8打包密度，同时依赖 image + factsheet 契约。该组合能否通过本 fixture 的精确门槛？与更低密度、纯图像 profile 相比表现如何？

二、实验设计：fixture、arms 与评分规则

2.1 精度关键型合成会话（fixture）

与密度 harness 使用同一个精度关键型合成会话，内部埋入四个精确 token 形状（TRUTH常量，见 factsheet-vs-image.mjs）：

会话正文在助手消息中依次植入这四个值，另含 40 轮step i: processed shard i ...流水日志，模拟真实长会话的"长尾重复内容 + 少量精确标识符"结构。测试问题固定为 6 个：4 个 exact（hex / camel / path / port）、1 个 gist（retry budget=3）、1 个 guard（未声明的数据库密码必须回答 "NOT STATED"）。

2.2 五个对照 arms

脚本中定义的 arms（factsheet-vs-image.mjs）：

• 5x8_image_only：生产密度（cellWBonus:0, cellHBonus:0）+ 抗锯齿，纯图像；
• 5x8_image_plus_factsheet：同一 5×8 密度，图像后附加 factsheet（生产 Responses transform 实际发送的形态）；
• 5x8_grid_plus_factsheet：5×8 + 网格线样式 + factsheet；
• 5x8_color_plus_factsheet：5×8 + 颜色循环样式 + factsheet；
• d4_c84_image_only：cellWBonus:4, cellHBonus:4（等效 9×12 单元格）、84 列、纯图像——已知能通过 Opus 精确门槛的密度，用于横向对比。

渲染由生产渲染器renderTextToPngs完成，宽度上限 768 px（避免供应商把 5 px 字模按短边降采样）。成本核算采用visionTokensForModel计算图像 token、SESSION.length/4估算文本 token，savings =1 - (imageTok + sheetTok)/textTok。

2.3 通过标准

沿用 opus-density 的精神，一个密度"足够好"必须同时满足：exact ≥ 4/4、0 confabulation、gist ok、guard ok（拒绝编造、回答 "NOT STATED"）、相对文本仍有正的图像 token 节省。若只有比生产更稀的单元格能通过，候选就只能是opt-in 的低密度 Grok profile，绝不能悄悄改变默认。

三、核心结果：factsheet 恰好救回四个 token 形状

原始结果表完整继承如下（同日 JSON 收据见 factsheet-vs-image-results.json）：

几个关键读数：

• 纯图像在 5×8 密度下全军覆没：exact 0/4，且 4 个答案全部是自信的编造（confab），gist 与 guard 却正常——说明问题不是"看不懂"，而是精确字符级别的幻觉；
• 追加 factsheet 后 4/4 全对、0 编造，代价是节省率从 76% 微降到 70%（factsheet 本体约 78 个 token，见 JSON 中sheetTokens: 78，而图像 277、文本 1168）；
• 网格线与颜色循环两个样式旋钮在 5×8 密度下"带 sheet 时无恶化"，但正如 verdict 第 4 条强调的，它们并不能替代更大的单元格或 factsheet 来达成精确召回；
• 9×12/84 列纯图像 arm 作为参照：4/4、零编造，但图像 token 从 277 涨到 820（2 页 764×728 + 764×344），节省率只剩 30%——约为 5×8 密度一半的收益。

3.1 5×8 纯图像的具体编造（confabulation）样本

这是最有诊断价值的数据，四个 token 形状的误读模式各不相同（FACTSHEET_RESULTS.md 与 JSON 收据一致）：

• hexa3f9c1e0b7d2→5c5e4e0b9d2（长度都变了）
• cameltokenLedgerShard→tokenEdgeShard（仅中间一个词干被替换）
• pathsrc/core/anthropic-vision.ts→pro/core/anthropic-client.ts（目录与文件名同时"合理但错误"）
• port47821→97821（一个数字位翻转）

这些例子直观说明：在 5×8 像素级密度下，Grok 的视觉管线丢失的并非语义而是字形级细节，而模型倾向于用"看起来最合理的值"填空，正是这种补全在精确场景（缓存 key、SHA、端口、CLI 参数）中是最危险的失败模式。

四、factsheet 是什么：为什么它能逐字救回被图像吞掉的 token

要理解"为什么加了 sheet 就从 0/4 变 4/4"，需要看 factsheet 的实现——src/core/factsheet.ts。

4.1 提取目标与正则集

pxpipe 渲染一个块（system slab、history、tool_result、reminder）为 PNG 时，会把其中精度关键、难以 OCR的字符串提取出来，以纯文本形式紧贴图像发送：文件路径、URL、SHA/UUID、版本号、CLI flag、大数字、CONST_IDS 等。模型直接引用这些文本，无需重新读图，且它们留在缓存前缀里。

提取按固定顺序的正则模式进行（src/core/factsheet.ts），覆盖：LABEL=value语义对、URL、email、UUID、IBAN 类账号串、货币金额、带扩展名路径、多段目录路径、git SHA/长 hex、版本号、CLI flag、大/带分隔符数字、小数、CONST_IDS/环境变量名、camelCase/PascalCase 标识符、PROJ-1482/CVE-2024-30078类票据码。全部为全局模式且无回溯爆炸风险（先按空白切块、跳过 blob 长度块，保证 O(n)）。

4.2 预算与优先级：短、零冗余的 token 永远优先

两个硬预算：MAX_TOKENS = 96（每页保留 token 上限）与MAX_URLS = 8。预算按 token形状（而非长度）分三档分配（priorityTier，src/core/factsheet.ts）：

• tier 0（永远保护）：LABEL=value赋值对、hex/SHA、UUID、email、IBAN、货币、CONST_IDS、票据码、CLI flag、数字/端口/小数、长度 ≥8 的 camelCase；
• tier 1：一般路径、版本、杂项；
• tier 2：URL（长、结构化、OCR 风险低、通常可重建，故设上限且最后填充）。

设计注释点明了反直觉的理由：长度与 OCR 风险是反相关的——70 字符的 URL 是结构化的、可重建的，而 7 字符的 hex SHA 或端口零冗余，读错一个字符就静默失败。所以预算紧张时，短的高后果 token 必须排在长 URL 之前。

4.3 确定性、缓存稳定性与 ×N 计数

extractFactSheetEntries全流程（子串折叠 + 按 tier/长度/字典序全序排序）是输入的纯函数，输出字节稳定，跨轮次不破坏 Anthropic prompt cache；文档实测约 5% 的源字符（中位 4.9%、最大 12.1%、N=10）进入 sheet，因此不侵蚀图像化的 token 收益。条目还携带出现次数，生成形如tokenLedgerShard ×41的计数注释（对应OPEN_COUNTS文案："×N marks a token that occurs N times"），使"这段图像里 X 出现了几次"这类 tally 问题可以从文本回答，而不是去数 5×8 像素的行。

本 fixture 实际产出的 sheet 全文（来自 JSON 收据）为：

[Exact identifiers from the rendered context above (paths, ids, versions, numbers) — quote these verbatim instead of transcribing them from the image; ×N marks a token that occurs N times within the imaged content: --max-visual-tokens · tokenLedgerShard ×41 · a3f9c1e0b7d2 · 47821 · src/core/anthropic-vision.ts]

注意四个 probe 全部被提取且顺序正确——这正是该 arm 能 4/4 的直接原因。

五、生产路径如何把 sheet 贴到图像旁边

factsheet 不是实验独有机制，而是 Responses transform 的真实行为。在 src/core/openai.ts 中：

• 静态 system slab 压缩时，factSheetText(combinedRaw, profile.factSheetFormat)生成的 sheet 紧随 slab 图像插入消息（第 1146、1375 行附近，注释明确写着 "Verbatim fact-sheet (see src/core/factsheet.ts): exact tokens that survive OCR loss"）；
• 历史折叠路径里，applyGptHistoryCollapse在 intro + 图像之后追加histFactSheet（src/core/openai.ts）；
• Responses 路径的applyResponsesHistoryCollapse按profile.history.factSheetScope决定是整段合并 sheet（combined）还是逐 segment 生成 sheet（src/core/openai.ts），sheet 以input_text形式紧贴input_image发送——这就是本实验5x8_image_plus_factsheetarm 复刻的契约。

Grok 的模型 profile 也体现了本实验的结论（src/core/gpt-model-profiles.ts）：factSheetFormat: 'full'、history 用NATIVE_14PX_HISTORY、stripCols: 84、maxHeightPx: 512、视觉计费为mpix体制（2026-07-09 实测 grok-4.5 约 1000 token/MP），且isGrokModel属于FAMILY_ID_GUARDS——未声明的 grok id 不会隐式回落到其他供应商的计费公式。

六、Verdict：为什么 Grok 保持 opt-in，且内置 profile 比 5×8+sheet 更保守

原文档的四条结论是这篇文章的产品决策核心，逐条展开：

1. Grok 只做 opt-in，不进默认集合。它不在DEFAULT_MODEL_BASES中，验收门槛与 Opus 一致：在精确召回上不够格，就不能作为 pxpipe 的静默默认值。仓库 README 中默认PXPIPE_MODELS=claude-fable-5,claude-opus-5-5,gemini，Grok 需显式加入，例如PXPIPE_MODELS=claude-fable-5,grok-4.5，或在 dashboard 上点击 Grok chip（README.md）。
2. factsheet 在本 fixture 中救回了四个 token 形状，但 n=1 不能证明对真实会话的提取覆盖率。这是对"该机制可靠吗"的最诚实表述：它可以作为防线，但单次测量不足以宣称覆盖所有 token 形状。
3. 内置 opt-in profile 因此采用独立测量的有效 9×12/84 列 arm（4/4、零编造），并把 factsheet 作为纵深防御——比"5×8 + factsheet"更保守，即：宁可牺牲节省率（30% vs 70%），也要在纯图像层面先达到精确门槛，sheet 只作第二道保险。
4. 5×8 密度下的样式旋钮（grid、colorCycle）不能替代更大的单元格或 factsheet来实现精确召回。

后续演进也值得说明：同一 harness 家族的更大规模质量套件（QUALITY_SUITE.md、QUALITY_RESULTS.md，2026-07-23）在 Codex Responses 端点上、以resolveGptProfile('grok-4.5')解析的live 生产 profile（JetBrains Mono 14px / 84 列 / maxH 512，factsheet on，IDS on arithmetic）测出：novel arithmetic 100/100、gist recall 97/98、state tracking 17/18、never-stated guards 0/16 编造，但密集 12 位 hex 仍 0/15——所以 Grok 依旧 opt-in，hex 与 native-size 精确阶梯仍未达 Fable 门槛。这与本实验结果共同构成"Grok 需要在精确场景保持 opt-in"的完整证据链。

七、如何复现：dry-run 与 live run

7.1 本实验的重新运行

pnpm run build GROK_DENSITY_LIVE=1 node eval/grok-density/factsheet-vs-image.mjs

• 机器可读收据写入eval/grok-density/factsheet-vs-image-results.json，stdout 输出人读表格与 verdict；
• 可选覆盖：GROK_DENSITY_MODEL=grok-4.5、GROK_DENSITY_TIMEOUT_MS=180000；
• live 模式需要OPENAI_BASE_URL与OPENAI_API_KEY指向提供该 Grok 模型的 OpenAI 兼容 Responses 端点；脚本会拒绝 pxpipe 本地端口，确保测的是原始图像读取而非二次压缩（见 factsheet-vs-image.mjs）。

7.2 更大规模的密度扫描

# Dry-run：只渲染 + token 核算，不调模型 node eval/grok-density/run.mjs # Live：完整六任务电池（hex/camel/path/port/gist/guard） GROK_DENSITY_LIVE=1 node eval/grok-density/run.mjs GROK_DENSITY_MODEL=grok-4.5 GROK_DENSITY_LIVE=1 node eval/grok-density/run.mjs

输出为eval/grok-density/results.json；变体覆盖 5×8（生产密度）、7×10、9×12，列数随单元格增大而减少，保证条带 ≤ 768 px 宽。

八、局限与正确解读方式

• n=1 单次 live run：结果证明"factshet 在该 fixture 上救回四个形状"，但不构成对真实会话的覆盖率证明——原文档与 harness 注释都明确承认这一点；
• 测量的是图像读取，不是压缩：live 模式绕过 pxpipe，因此数字反映的是模型对"生产渲染器产出的图像 + 生产契约"的原始读取能力，任何经 pxpipe 的二次变换都不计入；
• 成本数字是当时的模型计费下的核算：savings 由visionTokensForModel（Grok 为 mpix 1000 token/MP）与文本估算共同决定，换模型或换计费后应重新测量；
• 不要直接照搬本文数值当作新模型结论：同一 density 对不同视觉模型差异巨大（Grok 5×8 纯图像 0/4，而同 fixture 下 Opus 纯图像在 9×12/84 列可达 4/4），这正是 pxpipe 坚持"每模型独立测量、合格才进默认"的原因。

九、结语

这次实验给出了一条可复用的产品化路径：当高密度图像在某个模型上精确召回失败时，与其整体降密度，不如先测"图像 + verbatim fact-sheet"契约能否补齐精确层——本案例中它以 6% 的节省率代价（76%→70%）把精确召回从 0/4 拉到 4/4。但当证据仅有 n=1 时，稳妥的产品决策是像 pxpipe 那样：内置 profile 用独立测量确认过的更低密度（9×12/84 列），并把 factsheet 作为纵深防御，同时把新模型留在 opt-in 名单里，等待更大样本的验收数据。对使用 pxpipe 的开发者，本文的实操价值在于：理解PXPIPE_MODELS=...,grok-4.5的 opt-in 语义、知道 dashboard Grok chip 背后的验收门槛，以及遇到精确召回问题时，可借助eval/grok-density/下的 harness 对任意 OpenAI 兼容 Responses 模型复现同一套测量。