oh-my-pi snapcompact 抽取式 QA 探針qa-text.md 提示詞設(shè)計(jì)與文本載體驗(yàn)證管線解析【免費(fèi)下載鏈接】oh-my-pi? Coding agent with the IDE wired in項(xiàng)目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi導(dǎo)讀本文深入解析 oh-my-pi 倉(cāng)庫(kù)中 qa-text.md 這一評(píng)測(cè)提示詞模板。它是 snapcompact面向視覺(jué)模型的位圖幀上下文壓縮研究框架中文本載體text carrier的統(tǒng)一問(wèn)答探針在 SQuAD v1.1 抽取式問(wèn)答評(píng)測(cè)里任何被壓縮為文本形式原始文本、Agent 摘要 compact、抽取式摘錄 extract的上下文塊都通過(guò)該模板被送入 LLM 完成抽取式作答。讀完本文你將掌握該提示詞的分段結(jié)構(gòu)、UNREADABLE棄權(quán)協(xié)議、編號(hào)列表解析與官方 EM/F1 評(píng)分鏈路以及它在 run.py、exp13_extractive.py、mono.py 中的實(shí)際調(diào)用方式與參數(shù)約束。一、qa-text.md 在評(píng)測(cè)體系中的定位snapcompact 的核心假設(shè)是與其讓 LLM 對(duì)丟棄的歷史做敘事性總結(jié)摘要會(huì)丟失可驗(yàn)證的原文事實(shí)不如把文本序列化后渲染成密集像素字體 PNG 幀讓視覺(jué)模型直接讀圖回答。為了公平對(duì)比文本直讀 / 文本摘要 / 抽取式摘錄 / 位圖幀等不同壓縮策略的問(wèn)答召回率研究目錄 research/ 內(nèi)構(gòu)建了一套基于 SQuAD v1.1 dev 集的評(píng)測(cè)管線定義了多組 conditiontext純文本固定 40,716 字符分塊TEXT_CHUNK見 run.py數(shù)值取 img-6x10 位圖幀的等效容量保證文本與摘要/圖像條件可比compact/handoffAgent 分別生成壓縮摘要 / 交接文檔后再問(wèn)答img-font-variant將文本渲染為像素字體位圖幀8x13、6x10、5x8、5x7、4x6tt 等字體 × color / zebra / bw 變體。其中text、compact、handoff三類文本型條件的問(wèn)答環(huán)節(jié)統(tǒng)一使用 qa-text.md 作為探針圖像型條件則使用 qa-image.md。這正是該模板一模板管全部文本載體的定位無(wú)論上下文是原始 chunk、Agent 摘要還是抽取式摘錄都以相同的回答契約進(jìn)行度量從而讓不同壓縮策略的召回差異只歸因于載體本身。二、提示詞全文與逐段解剖2.1 原文全文qa-text.md 全文如下由 read_file 獲取共 10 行Below is reference material. Questions follow in the next block. reference {context} /reference Answer the questions using ONLY the reference material above. - Give short extractive answers: a word or phrase copied from the text. - If the reference does not contain the information, reply exactly UNREADABLE for that question. - Output a numbered list, one answer per line, no commentary.2.2 分段功能拆解段落作用對(duì)應(yīng)評(píng)測(cè)邏輯Below is reference material. Questions follow in the next block.會(huì)話開場(chǎng)白向模型聲明后續(xù)將出現(xiàn)問(wèn)題與 session-frame.md 的先給段落、再提問(wèn)結(jié)構(gòu)對(duì)齊reference{context}/reference參考材料的裝載占位符{context}由代碼用.format(context...)填充在 run.py 中填充 chunk 原文或摘要文本在 exp13_extractive.py 中填充抽取式摘錄Answer the questions using ONLY the reference material above.封閉語(yǔ)料約束禁止依賴模型內(nèi)部知識(shí)作答保證答案必須能從載體中提取到這是后續(xù)gold_survival黃金答案存活率與UNREADABLE協(xié)議成立的前提Give short extractive answers: a word or phrase copied from the text.抽取式回答約束答案必須是原文的單詞或短語(yǔ)禁止改寫、擴(kuò)寫與 exp13-extract.md 中逐字復(fù)制verbatim的摘錄規(guī)則一脈相承度量的是信息可提取性而非語(yǔ)言生成能力If the reference does not contain the information, reply exactly UNREADABLE for that question.棄權(quán)協(xié)議信息不在參考材料中時(shí)必須精確輸出UNREADABLE而非編造評(píng)測(cè)端以u(píng)nreadable in a.lower()識(shí)別棄權(quán)squad.py、exp13_extractive.py并單獨(dú)統(tǒng)計(jì)abstained數(shù)Output a numbered list, one answer per line, no commentary.輸出格式契約嚴(yán)格一行一條、按題號(hào)編號(hào)、禁止注釋由 squad.py 的parse_numbered解析2.3 兩條硬約束的設(shè)計(jì)動(dòng)機(jī)從源碼結(jié)構(gòu)看該模板刻意收緊了回答自由度UNREADABLE精確詞約束在抽取式評(píng)測(cè)中模型若在信息缺失時(shí)猜測(cè)會(huì)以低 EM/F1 污染結(jié)果若給出長(zhǎng)篇解釋又會(huì)破壞編號(hào)解析。精確的單令牌棄權(quán)詞使評(píng)測(cè)能區(qū)分載體中確實(shí)沒(méi)有答案gold_survivalFalse與答案在載體中但模型沒(méi)找到gold_survivedTrue但答非所問(wèn)這兩種本質(zhì)不同的失敗模式。編號(hào)列表 無(wú)注釋約束一次 API 調(diào)用通常攜帶 30 個(gè)問(wèn)題--qpc默認(rèn) 30見 run.pyparse_numbered用正則\s*(\d)[.):]\s*(.*\S)?\s*$逐行抽取答案缺行補(bǔ)空串。任何多余注釋行都會(huì)導(dǎo)致該題答案解析為空、EM/F1 歸零因此模板強(qiáng)制無(wú)注釋。三、調(diào)用鏈qa-text.md 如何被送入模型3.1 主評(píng)測(cè)管線run.py 的 text 分支在 run.py 的run_chunk中當(dāng) condition 屬于文本型text/compact/handoff時(shí)carrier {type: text, text: load_prompt(qa-text.md).format(contextcontext)} # context 在 text 條件下就是 chunk 原文 # 在 compact/handoff 條件下則是session_frame(chunk) 摘要提示詞生成后的摘要文本 content ([preamble] if preamble else []) [carrier, {type: text, text: q_block}]即qa-text.md渲染后的context文本塊與問(wèn)題塊q_block1. question\n2. question...拼入同一 user 消息。若啟用 prompt 緩存--cache還會(huì)給 carrier 附加cache_control: {type: ephemeral}讓整塊參考材料被 prompt 緩存命中——這是成本核算中cache_w/cache_r的來(lái)源。3.2 抽取式壓縮基線exp13_extractive.py 的兩階段exp13_extractive.py 是文本摘要族的對(duì)照實(shí)驗(yàn)它先證明敘事性摘要對(duì)抽取式 QA 不友好Gemini 會(huì)以 UNREADABLE 棄權(quán)、F10因此改用逐字抽取作為壓縮階段。其每 chunk 的兩階段管線抽取階段session_frame(chunk_text) exp13-extract.md預(yù)算--budget默認(rèn) 8000 字符→ 得到抽取式摘錄緩存標(biāo)簽exp13-extract問(wèn)答階段qa-text.md.format(contextextraction) q_block→ 緩存標(biāo)簽exp13-qa見 exp13_extractive.py。摘錄字符數(shù)作為extraction_chars記錄在首條記錄上且抽取階段的 token 用量被計(jì)入單格成本——與summarize階段同等待遇。文檔注釋給出的預(yù)算參考約 2000 token ≈ 8000 字符對(duì)應(yīng)每 40,716 字符 chunk 的光學(xué)載體容量。3.3 其他使用點(diǎn)mono.py整流entire flow一次性問(wèn)答時(shí)以{text: ..., cache: True}形式攜帶qa-text.md上下文final.py同時(shí)存在對(duì)生成摘要問(wèn)答與對(duì)原始 chunk 文本問(wèn)答兩個(gè)分支二者都復(fù)用qa-text.md。四、回答的解析與評(píng)分從 UNREADABLE 到 EM/F14.1 編號(hào)解析squad.py 的parse_numbered(text, n)按行匹配題號(hào) 分隔符 答案對(duì)缺失題號(hào)補(bǔ)空串保證答案列表與問(wèn)題列表嚴(yán)格對(duì)齊。4.2 官方 SQuAD 歸一化與指標(biāo)評(píng)分完全復(fù)刻 SQuAD v1.1 官方邏輯_normalizesquad.py轉(zhuǎn)小寫 → 去標(biāo)點(diǎn) → 移除冠詞a/an/the→ 折疊空白exact_matchL88-L89歸一化后預(yù)測(cè)與任一 gold 完全相等得 1f1L92-L102基于 token 級(jí)精確率/召回率的調(diào)和平均取多個(gè) gold 中的最優(yōu)值。4.3 棄權(quán)統(tǒng)計(jì)每條記錄以abstained unreadable in a.lower()標(biāo)記棄權(quán)聚合時(shí)統(tǒng)計(jì)abstained總數(shù)。棄權(quán)題的 EM/F1 自然為 0因此棄權(quán)率與 F1 呈負(fù)相關(guān)——這正是 exp13_extractive.py 注釋強(qiáng)調(diào)敘事摘要導(dǎo)致棄權(quán)、F10的原因。五、exp13 專有指標(biāo)gold_survival黃金答案存活率exp13_extractive.py 定義了gold_survivesdef gold_survives(golds: list[str], extraction_norm: str) - bool: return any(_normalize(g) in extraction_norm for g in golds)即問(wèn)題的任一黃金答案文本歸一化后是否逐字存活于抽取式摘錄中。該指標(biāo)聚合為gold_survival本質(zhì)是壓縮方法的召回上限——與模型問(wèn)答能力解耦若 gold 已不在摘錄中任何模型都不可能答對(duì)若 gold 在但模型答錯(cuò)才歸咎于 QA 能力。這一列讓抽取式基線的評(píng)估結(jié)論可分離、可歸因也是 qa-text.md只用參考材料作答約束的直接產(chǎn)物。六、運(yùn)行參數(shù)與緩存策略6.1 exp13_extractive.py 的關(guān)鍵參數(shù)參數(shù)默認(rèn)值含義--modelsgpt-5.5,google/gemini-3.5-flash被測(cè)模型需預(yù)先注冊(cè)在MODELS字典含輸入/輸出單價(jià)--lengths50,150,250語(yǔ)料規(guī)模取 SQuAD 前 N 個(gè)段落用于觀察規(guī)模效應(yīng)--qpc30每 chunk 采樣問(wèn)題數(shù)--budget8000每 chunk 抽取摘錄的字符上限--max-tokens32768問(wèn)答調(diào)用輸出預(yù)算--extract-max-tokens16384抽取調(diào)用輸出預(yù)算budget slack--extract-effortlow僅抽取調(diào)用的推理強(qiáng)度。注釋特別說(shuō)明逐字復(fù)制無(wú)需深思默認(rèn)強(qiáng)度下 Gemini 會(huì)用約 16k 推理 token 去驗(yàn)證引文并導(dǎo)致截?cái)?.2 按負(fù)載哈希的磁盤緩存cached()exp13_extractive.py以(model, tag, payload)的 SHA-1 前 8 位為鍵緩存響應(yīng)截?cái)囗憫?yīng)stop max_tokens永不緩存也永不命中緩存從而保證中斷后的續(xù)跑免費(fèi)、增大預(yù)算后能自動(dòng)修復(fù)截?cái)唷＿\(yùn)行方式# 在 packages/snapcompact 目錄下 uv run exp13_extractive.py # 默認(rèn)網(wǎng)格 uv run exp13_extractive.py --budget 12000 # 調(diào)大抽取預(yù)算 uv run exp13_extractive.py --fresh # 忽略緩存強(qiáng)制重跑輸出為results/exp13-extractive/下的records.jsonl逐題記錄、summary.json聚合單元與matrix.csv模型 × 長(zhǎng)度矩陣并打印每格的f1±se / em / survival / abst / cost。七、與圖像載體驗(yàn)證的對(duì)照qa-image.md同為先給載體、再問(wèn)問(wèn)題、UNREADABLE 棄權(quán)、編號(hào)列表輸出的契約qa-image.md 的差異點(diǎn)在于它把reference{context}/reference文本塊替換為位圖幀說(shuō)明monospace pixel font, {cols} characters per row, {rows} rows, read left-to-right then top-to-bottom并要求Answer them using ONLY text you can read in the image。兩者共享完全相同的回答與評(píng)分協(xié)議這使得text / compact / handoff / img-*各條件的 EM/F1 可直接橫向?qū)Ρ日?snapcompact 選型Anthropic 用 11on16-bw、Google/OpenAI 用 8on22-bw見 snapcompact README 幀形狀表格的評(píng)測(cè)依據(jù)。八、延伸閱讀提示詞族譜session-frame.md先置參考材料、exp13-extract.md逐字抽取規(guī)則、qa-image.md圖像載體版本評(píng)測(cè)入口run.py主網(wǎng)格、exp13_extractive.py抽取式基線、mono.py整流模式數(shù)據(jù)與評(píng)分squad.pySQuAD 加載、問(wèn)題采樣、EM/F1、編號(hào)解析上層應(yīng)用snapcompact READMEserializeConversation→normalize→render/renderMany的壓縮流程及幀形狀選型。無(wú)法成文qa-text.md 僅 10 行、是一個(gè)待{context}填充的提示詞模板片段自身缺乏獨(dú)立成文所需的架構(gòu)與實(shí)操細(xì)節(jié)。/無(wú)法成文【免費(fèi)下載鏈接】oh-my-pi? Coding agent with the IDE wired in項(xiàng)目地址: https://gitcode.com/GitHub_Trending/oh/oh-my-pi創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考