oh-my-pi snapcompact 多帧位图问答提示词解析:让视觉 LLM 按顺序读取连续压缩帧

发布时间:2026/9/12 14:27:38
oh-my-pi snapcompact 多帧位图问答提示词解析:让视觉 LLM 按顺序读取连续压缩帧 oh-my-pi snapcompact 多帧位图问答提示词解析让视觉 LLM 按顺序读取连续压缩帧【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pisnapcompact 是 oh-my-pi 为视觉大模型设计的位图帧上下文压缩方案不要求 LLM 用文本摘要被丢弃的对话历史而是把历史序列化后渲染成密集像素字体的 PNG 帧让视觉模型像档案管理员一样直接读图恢复记忆。本文聚焦该方案研究阶段的核心提示词模板 qa-image-multi.md——它是面向多帧连续位图的问答指令定义了模型如何理解帧的几何参数、阅读顺序、摘录式回答纪律与 UNREADABLE 弃权协议。读完本文你将掌握该模板的完整语义、占位符的真实填充逻辑、底层 BDF 像素字体渲染原理以及它在长上下文检索评测与生产压缩流水线中的实际应用方式。提示词定位monolithic 长上下文检索探针的阅读说明书在 snapcompact 的研究目录 packages/snapcompact/research 中prompts 目录下保存了多套实验提示词其中qa-image-multi.md是唯一面向多张图像的版本。它的使用者是 mono.py——monolithic 长上下文探针运行器。mono.py 的注释说明了它的设计动机mono.pyfinal.py把每种条件切成约 10k token 的 QA 调用因此永远无法测试单请求内的真实长上下文检索。mono.py 则把 N 字符的 SQuAD 语料流例如 800k 字符 ≈ 200k 文本 token塞进一个请求——要么作为原始文本要么作为一摞密集字体图像——并在整个跨度上均匀采样问题报告整体 EM/F1 与按位置四分位划分的 F1即真实的lost in the middle现象分块评测无法观测到。当条件为图像类img-font-variant时语料流被按每帧容量切块逐块渲染成 PNG然后在请求里堆叠发送。此时qa-image-multi.md作为 preamble 排在所有图像之前负责告诉模型你将看到什么、按什么顺序读、如何回答。提示词全文与逐段语义拆解qa-image-multi.md全文共 6 行三段功能清晰。以下逐段拆解其真实含义并补充仓库源码中的实现细节。第一段载体几何与阅读顺序的声明The attached {k} images contain encyclopedia passages rendered as dense bitmaps: monospace pixel font, {cols} characters per row, {rows} rows per image. The text flows continuously across the images: read each image left-to-right, top-to-bottom, then continue with the next image in order (image 1 first, image {k} last). Original paragraph breaks were collapsed to spaces.这段做了三件事声明载体告知模型附件是{k}张密集位图每行{cols}个字符、每图{rows}行使用等宽像素字体。参数全部由运行器在渲染前计算并填充见下文调用点分析。声明连续性强调文本跨图像连续流动——这是多帧版本区别于单帧版本 qa-image.md 的核心。阅读顺序被严格定义为每张图从左到右、从上到下然后按图 1 → 图 k 的顺序继续。这等价于告诉模型帧边界只是物理分页不是语义分节。声明规范化规则原始段落换行被折叠为空格与渲染侧squad.py中 .join(p[context].split())的空格合并行为一致squad.py也与生产压缩侧normalize()折叠空白、把换行流压成单个全块字形full-block glyph的规则同源见 snapcompact.ts 与 snapcompact-summary.md。第二段答案来源与格式纪律Questions follow after the images. Answer them using ONLY text you can read in the images.Give short extractive answers: a word or phrase copied from the text.If you cannot read the relevant region well enough to answer, reply exactly UNREADABLE for that question.Output a numbered list, one answer per line, no commentary.这是整份提示词的评分契约与评测端 squad.py 的解析逻辑严格对齐严格摘录extractive答案必须是从文本复制的词或短语——因为官方 SQuAD EM/F1 要求预测与 gold answer 逐 token 匹配squad.py自由改写会直接损失得分。UNREADABLE 弃权协议读不清就精确回复UNREADABLE。这与 qa-text.md 中reference 不包含该信息时回复 UNREADABLE的约定一脉相承是评测中 abstained弃权指标的判定依据——run.py 与 mono.py 都用unreadable in a.lower()统计弃权率。弃权是诚实的失败宁可说读不清也不准编造这保证了 F1 数字的可信度。编号列表输出每行一个答案不加评论。解析端 squad.py 的parse_numbered用正则\s*(\d)[.):]\s*(.*\S)?\s*$逐行提取编号答案缺失项补空串。任何多余评论都会污染解析因此no commentary是硬约束。占位符的真实填充逻辑mono.py 调用链qa-image-multi.md的三个占位符{k}、{cols}、{rows}在 mono.py 的build_content中填充font, variant, columns img cfg FONTS[font] cols, rows, cap capacity(cfg, size, columns) # ... 按 cap 切块、逐块渲染 PNG、收集 pngs 列表 ... preamble load_prompt(qa-image-multi.md).format( klen(pngs), colscols, rowsrows )其中capacity()来自 bdf.pydef capacity(cfg: FontCfg, size: int 1568, columns: int 1) - tuple[int, int, int]: rows size // cfg.pitch // cfg.repeat gutter 2 * cfg.adv if columns 1 else 0 cols (size - (columns - 1) * gutter) // columns // cfg.adv return cols, rows, columns * cols * rows以默认size1568、字体6x10adv6, pitch10单栏为例rows 1568//10 156cols 1568//6 ≈ 261容量约 40,716 字符——这正是 run.py 中TEXT_CHUNK 40716的由来它保证纯文本条件与图像条件承载量可比。渲染出的消息块结构mono.py为blocks [ {text: preamble}, # qa-image-multi.md位于所有图像之前 *({image_path: p} for p in pngs), # 全部帧按顺序 {text: End of images., cache: True}, ]End of images. 标记配合cache: True既明确告知图像序列结束又利用前缀缓存让多批问题共享同一段上下文避免重复计费。此外当字体配置repeat 1冗余编码如8x8r时preamble 还会追加一段说明每行文本被渲染两次——第一次在纯背景上第二次在淡黄色高亮带上……难以辨认的字形可在两副本间交叉校验不要把副本当作额外文本mono.py。这是对多帧读取说明的自然扩展不仅帧间连续帧内的重复行也要按冗余码理解。提示词家族对比单帧、多栏与多帧qa-image-multi.md并非孤立存在它属于一套围绕位图读取设计的提示词家族提示词文件适用场景关键差异qa-image.md单图问答run.py 分块评测单张位图{cols}/{rows}占位无跨帧连续性说明qa-image-cols.md双栏报纸式排版doc 系列用{columns}个由竖向分隔线隔开的栏规定先最左栏自上而下再下一栏的栏间阅读顺序qa-image-multi.md多帧连续文本mono.py 长上下文探针{k}张图连续流动规定图 1 → 图 k的帧间顺序qa-text.md纯文本参照组reference标签包裹上下文无图像qa-remote-compact.md远程压缩OpenAI /responses/compact后的记忆恢复改为依据你从上文保留的记忆回答同样保留 UNREADABLE 与编号列表契约可以看到无论载体是文本还是图像、单帧还是多帧仅依据所给材料、摘录式短答、读不清即 UNREADABLE、编号列表输出四条纪律贯穿始终这是整个评测体系可比性的基础。底层支撑BDF/HEX 像素字体渲染提示词反复强调monospace pixel font等宽像素字体这是渲染器 bdf.py 的核心职责字体来源X.org misc 系列8x13、6x10、5x8、6x12 等 BDF 格式、unscii-88x8 方形网格HEX 格式、tom-thumb4x6 微型字体。parse_bdf解析FONT_ASCENT、BBX、BITMAP段parse_hex处理 Unifont 风格的一行一字节字形bdf.py。网格密度FontCfg的adv每字符 x 进给与pitch每行 y 进给决定了帧的信息密度native参数支持先按原生单元光栅化再 Lanczos 各向异性拉伸如6x6srepeat实现逐行冗余编码。墨水变体color按行循环 6 色相、zebra黑白行带交替、bw纯黑、sent按句子循环色相、dim/sent-dim停用词淡化等bdf.py与提示词家族中关于原段落换行折叠的描述呼应——因为折叠后的文本流在帧内是纯栅格模型必须依靠几何声明而非版式线索来恢复结构。生产侧的原生渲染器renderSnapcompactPng位于crates/pi-natives将同样的 BDF 字形以原生代码光栅化并编码为 PNG保证整条链路本地、确定、无 LLM 调用snapcompact.ts 头注释。评测框架与证据链从提示词到 F1 矩阵qa-image-multi.md服务的长上下文探针运行方式mono.pyuv run --with pillow python mono.py --model gpt-5.5 --chars 800000 \ --conditions text,img-6x10-sent,img-6x8s-sent,img-8x8u-sent--chars 800000语料流约 800k 字符≈200k 文本 token一次请求装入--questions 50、--qpb 5全跨度均匀采样 50 问每批 5 问上下文重发并前缀缓存结果按pos_rel问题所在段落相对流起点的位置0..1四分位统计 F1直接暴露lost in the middle衰减。配套的另外两个运行器构成完整证据链run.py分块 QA 召回评测--conditions支持text/compact/handoff/img-font-variant组合响应按 payload 哈希缓存中断可续跑final.py博客数据集网格50/150/250 段 × 多模型 × 多条件输出records.jsonl、matrix.csv、summary.json并用模型输入/输出单价换算美元成本squad.py官方 SQuAD v1.1 dev 归一化与 EM/F1 评分parse_numbered严格对应提示词约定的编号列表输出。从源码结构看这些数字最终驱动了生产 shape 的选择snapcompact.ts的注释记录了可读性基准结果例如 Anthropic 线选用11on16-bw8x13 字形、11px 字距Google/OpenAI 线选用8on22-bw22px 行距并针对各 provider 的图像计费公式Anthropic 28px patch 封顶 4,784 visual tokens、Gemini 固定 1,120 token 每图、OpenAI 32px patch ×1.2分别调整帧尺寸snapcompact.ts 的SHAPES与familyBilling。这些为本提示词验证过的读取协议在生产中沉淀为 snapcompact-summary.md 的HISTORY 阅读指南同样的 cols/rows 声明、同样的按顺序阅读、同样的黑色实心格 换行、空格串折叠为一个规范化说明只是从作答改为续写会话。实战参考复现与扩展要点若要基于本提示词开展自己的多帧位图问答实验可参考以下要点准备环境研究脚本以 Python 3.10 与 Pillow 运行脚本头部 PEP 723 声明建议uv run --with pillow python run.py方式执行API Key 从~/.env读取ANTHROPIC_API_KEY/OPENAI_API_KEY/OPENROUTER_API_KEY。几何参数先行任何图像条件都要先用bdf.capacity(font, size, columns)算出cols/rows/cap再填充提示词占位符切勿写死数值size默认 1568可经--size调整。保持输出纪律模型端必须遵守仅摘录、可弃权、编号列表、零评论四条约束否则 squad.py 的解析与评分会失真。帧间连续性测试mono.py 的多帧条件img-6x10-sent等正是验证模型能否跨帧跟踪连续文本的最小实验载体对比单帧分块 run.py 的结果可量化分页带来的检索损失。生产接入如需在真实压缩流水线中使用同类读取协议可参考 packages/snapcompact/README.md 的 APIrenderMany/frames/resolveShape与 snapcompact-summary.md 的指南写法。一句话总结qa-image-multi.md用 6 行声明把一摞连续位图 一组问题变成了可稳定评测的阅读理解任务——它是 snapcompact 从研究假设走向生产压缩的中间枢纽也是理解视觉模型如何阅读位图档案的最佳切入点。【免费下载链接】oh-my-pi⌥ Coding agent with the IDE wired in项目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

关于本文作者

来自尧图内容编辑团队

尧图内容编辑团队 内容团队

尧图内容编辑团队

本文由尧图网络内容编辑团队执笔。团队由资深项目经理、前端工程师与设计师组成,所有内容均来自亲手交付的真实项目,先讲清问题、再给出可落地的解法。尧图深耕北京网站建设十年,服务过京华建材集团、智造科技等各行业客户,把一线经验沉淀为可复用的行业观察。

  • 十年建站经验,覆盖建材、制造、服务、文创等
  • 项目经理把关选题与事实准确性
  • 工程师与设计师联合撰写专业细节
  • 统一编辑规范,保证文风与排版一致
  • 每月复盘转化数据,迭代选题方向

延伸阅读

相关资讯与近期热门内容

深度阅读推荐

建站决策前值得细读的三篇

网站改版的5个关键决策
2024-08-12

网站改版的5个关键决策

什么时候该改版、改到什么程度、如何避免流量掉光,京华建材集团改版复盘给出答案。

获取专属建站方案

看完文章,把您的行业与预算告诉我们,免费获取一份量身定制的官网建设方案与报价。

立即免费咨询