ลดค่าใช้จ่าย Fable 60%: แปลงโค้ดเป็นภาพแล้วให้โมเดลทำ OCR

 (github.com/teamchong)
4 คะแนน โดย GN⁺ 5 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • pxpipe ระบุว่าสามารถลดค่าใช้จ่ายรวมแบบ end-to-end ตามราคาเต็มปัจจุบันของ Fable ได้ราว 59~70% โดยแปลงคอนเท็กซ์ขนาดใหญ่ของคำขอ Claude Code เป็นภาพ PNG ในพร็อกซีภายในเครื่องเพื่อลด input token
  • หลักการสำคัญคือค่าใช้จ่ายของ image token ถูกกำหนดจาก ขนาดพิกเซล ไม่ใช่ปริมาณข้อความด้านใน และข้อความหนาแน่นอย่างโค้ด, JSON, หรือผลลัพธ์จากเครื่องมือ จะบรรจุได้ราว 3.1 ตัวอักษรต่อ image token เทียบกับประมาณ 1 ตัวอักษรต่อ text token ในทราฟฟิก Claude Code จริง
  • สิ่งที่ถูกบีบอัดได้แก่ tool_result ขนาดใหญ่, ประวัติที่พับเก่าแล้ว, system prompt แบบคงที่ และเอกสารเครื่องมือ ขณะที่เทิร์นล่าสุด, ข้อความผู้ใช้, เอาต์พุตของโมเดล, prose ที่เบาบาง และโมเดลที่อยู่นอก allowlist จะถูกส่งผ่านเป็น ข้อความตามเดิม
  • วิธีนี้มีการสูญเสียข้อมูล ดังนั้นการทวนคืนสตริง hex 12 ตัวอักษรแบบเป๊ะ ๆ ให้ผลเป็น 13/15 บน Fable 5 และ 0/15 บน Opus และการพลาดอาจไม่แสดงเป็น error แต่เป็น คำตอบผิดที่ดูน่าเชื่อ จึงควรเก็บค่าที่ต้องแม่นระดับไบต์อย่าง ID, hash และ secret ไว้ในรูปข้อความ
  • โมเดลเป้าหมายเริ่มต้นคือ claude-fable-5,gpt-5.6 ส่วน Opus 4.7/4.8 และ GPT 5.5 เปิดใช้ได้แบบ opt-in เท่านั้นเพราะประสิทธิภาพการอ่านข้อความจากภาพลดลง และสามารถตรวจสอบการนำไปใช้จริงกับปริมาณที่ประหยัดได้รายคำขอใน ~/.pxpipe/events.jsonl

ค่าใช้จ่ายที่ pxpipe พยายามลด

  • pxpipe คือพร็อกซีภายในเครื่องที่เรนเดอร์คอนเท็กซ์ขนาดใหญ่เป็นภาพเพื่อลด input token ของ Claude Code
  • เป้าหมายคือบล็อกอินพุตขนาดใหญ่ในตัวคำขอ เช่น system prompt, เอกสารเครื่องมือ, ประวัติย้อนหลัง และผลลัพธ์จากเครื่องมือขนาดใหญ่
  • เอาต์พุตของโมเดลจะไม่ถูกบีบอัด และการสตรีมคำตอบยังทำงานตามปกติ
  • ค่า token ของภาพขึ้นกับ ขนาดพิกเซล ไม่ใช่จำนวนตัวอักษรในภาพ
    • ในทราฟฟิก Claude Code จริง เนื้อหาหนาแน่นบรรจุได้ประมาณ 3.1 ตัวอักษรต่อ image token
    • ส่วน text token วัดได้ประมาณ 1 ตัวอักษร
  • ตัวอย่างการเรนเดอร์หนึ่งรายการบรรจุ system prompt และเอกสารเครื่องมือราว 48k ตัวอักษรลงในภาพ 1573×1248 เพียงภาพเดียว โดยหากส่งเป็นข้อความจะใช้ประมาณ 25k token แต่ถ้าส่งเป็นภาพจะใช้เพียงประมาณ 2.7k image token

การรันและแดชบอร์ด

npx pxpipe-proxy                                  # proxy on 127.0.0.1:47821
ANTHROPIC_BASE_URL=http://127.0.0.1:47821 claude  # point Claude Code at it
  • พร็อกซีจะรันที่ 127.0.0.1:47821
  • มีแดชบอร์ดที่ http://127.0.0.1:47821/
    • จำนวน token ที่ประหยัดได้
    • เปรียบเทียบก่อน-หลังของการแปลงข้อความเป็นภาพ
    • kill switch
    • ชิปแสดงโมเดลแบบเรียลไทม์
  • เทิร์นล่าสุดจะคงเป็นข้อความ ส่วน system prompt, เอกสารเครื่องมือ และประวัติจำนวนมากที่เก่ากว่าจะถูกแปลงเป็นภาพ

ผลลัพธ์ที่แสดงในเดโม

  • Fable 5 เป็นค่าเริ่มต้น และใน README ถูกระบุเป็นโมเดลอ่านได้ 100/100
    • จากไฟล์ filler ที่ถูกแปลงเป็นภาพ 39 ไฟล์ สามารถนับ token ได้ถูกต้อง 10/10
    • ตรงกับผล grep ถึงระดับบรรทัด
    • แก้โจทย์เลข ledger แบบหลายขั้นตอนได้ถูกต้อง
    • ค่าใช้จ่ายของเซสชันระบุว่าเมื่อใช้ pxpipe อยู่ที่ $6.06 เทียบกับข้อความปกติที่ $42.21
    • ฝั่ง pxpipe ต้องมีการ nudging หนึ่งครั้งเพื่อให้ตรงตามรูปแบบเอาต์พุตแบบหนึ่งบรรทัดที่ร้องขอ
  • Opus 4.8 ถูกปิดไว้เป็นค่าเริ่มต้น
    • ข้อความ needle แบบ text อ่านได้ทั้งสองฝั่ง
    • phrase-count ที่ถูกแปลงเป็นภาพ Opus อ่านไม่ออก และ pxpipe แสดงความล้มเหลวโดยไม่แต่งตัวเลขขึ้นมา
    • เพราะอัตราอ่านผิดนี้เอง Opus จึงเป็นโมเดลที่ต้อง opt-in

ความแม่นยำและความสูญเสียข้อมูล

  • pxpipe เป็นการบีบอัดแบบ lossy compression
  • การทวนคืนสตริง hex 12 ตัวอักษรแบบเป๊ะ ๆ จากเนื้อหาในภาพที่หนาแน่น ให้ผลต่างกันมากตามโมเดล
    • Fable 5: 13/15
    • Opus: 0/15
  • การพลาดอาจไม่ออกมาในรูป error แต่เป็น การแต่งเติมผิดอย่างเงียบ ๆ
  • ค่าที่ต้องการความถูกต้องระดับไบต์ เช่น ID, hash, secret ควรคงเป็นข้อความ
  • ยังไม่มี verbatim-risk guard แบบเฉพาะทางในตัว
  • subagent ที่ใช้โมเดลนอก allowlist สามารถปล่อยผ่านเป็นข้อความได้
    • CLAUDE_CODE_SUBAGENT_MODEL=claude-sonnet-4-6
    • model: sonnet ใน frontmatter ของ agent

เบนช์มาร์กและค่าที่วัดได้

  • ใช้เบนช์มาร์กจากโจทย์ตัวเลขสุ่มใหม่เพื่อลดโอกาสที่โมเดลจะเคยจำโจทย์มาก่อน
ทดสอบ N ข้อความ ภาพ pxpipe โทเค็น
novel arithmetic, claude-fable-5 100 100% 100% −38%
novel arithmetic, claude-opus-4-8 100 100% 93% −38%
gist recall A/B, Fable 5 98/arm 98/98 98/98 -
state tracking, Fable 5 18/arm 18/18 18/18 -
never-stated facts confabulation, Fable 5 16/arm 0/16 0/16 -
verbatim 12-char hex recall, dense render, Opus 15 15/15 0/15 -
verbatim 12-char hex recall, dense render, Fable 5 15 - 13/15 -
  • ไพล็อต SWE-bench Lite ได้ผล 10/10 ทั้งสองฝั่ง และขนาดคำขอลดลง −65%
  • SWE-bench Pro ได้ ON 14/19, OFF 15/19 และขนาดคำขอลดลง −60%
    • การตัดสินตรงกันใน 18/19 กรณี
    • กรณีที่ผลแยกกัน 1 เคส ถูกแก้ได้อีกครั้ง 3/3 ในการรันซ้ำเพื่อทำซ้ำผล
    • README มองว่านี่เป็นความแปรปรวนระหว่างการรัน ไม่ใช่ปัญหาจากการบีบอัด
    • มีข้อควรระวังว่าขนาดตัวอย่างยังเล็ก
  • GSM8K ได้ 96% ในสภาพที่แปลงเป็นภาพ แต่ README ให้ความสำคัญกับการประเมินด้วยตัวเลขใหม่มากกว่า เพราะชุดนี้อาจปนอยู่ในข้อมูลฝึก

วิธีการทำงาน

tool_result string ──► wrap at 1928px-wide columns ──► pack ~92,000 chars/page ──► PNG[]
  • พร็อกซีดัก /v1/messages แล้วเขียนอินพุตขนาดใหญ่ที่เข้าเงื่อนไขใหม่เป็น image block
  • บล็อกที่แปลงแล้วจะถูกใส่กลับเข้าไปในรูปที่เป็นมิตรต่อแคช โดยเก็บ static prefix ไว้ ทำให้ prompt caching ยังทำงานต่อได้
  • ภาพขนาด 1928×1928 ใช้ vision token ประมาณ 4,761 token และบรรจุได้ราว 92,000 ตัวอักษร
  • ข้อความจะคุ้มกว่าก็ต่อเมื่อเกินประมาณ 19 ตัวอักษรต่อ token แต่ทราฟฟิก Claude Code วัดได้เพียงประมาณ 1.91 จาก N=391
  • ตัวประเมินรายคำขอจะตัดสินใจว่าจะทำเป็นภาพหรือไม่ โดย prose ที่เบาบางจะยังคงเป็นข้อความ
  • อีเวนต์จะถูกบันทึกลง ~/.pxpipe/events.jsonl

อะไรถูกบีบอัดและอะไรคงเดิม

  • อินพุตที่ถูกบีบอัดมีสามประเภท และทั้งหมดจะผ่าน profitability gate ก่อน
    • เนื้อหา tool_result ที่หนาแน่นในเชิง token ขนาดประมาณ 6k ตัวอักษรขึ้นไป
    • ประวัติที่พับเก่าแล้วซึ่งอยู่ถัดจาก live tail
    • ส่วน slab ของ system prompt และเอกสารเครื่องมือแบบคงที่
  • ยังมีรายการที่ระบุชัดว่าจะปล่อยผ่านตามเดิม
    • ข้อความผู้ใช้
    • เทิร์นล่าสุด
    • เอาต์พุตของโมเดล
    • prose ที่เบาบาง
    • บล็อกที่เล็กเกินกว่าจะคุ้ม
    • โมเดลที่อยู่นอก allowlist
  • ช่วงการรองรับเริ่มต้นคือ Fable 5 และ GPT 5.6
  • Opus 4.8 และ GPT 5.5 ต้องเปิดใช้เองอย่างชัดเจนผ่านแดชบอร์ดหรือ PXPIPE_MODELS เพราะอ่านเนื้อหาภาพได้ไม่ดี
  • PXPIPE_MODELS=off จะปิดการแปลงเป็นภาพ
  • ในเส้นทาง GPT นิยามเครื่องมือจะคงเป็น native JSON และจะไม่ใช้ตัวมาร์ก cache_control ของ Anthropic

วิธีคำนวณค่าใช้จ่าย

  • อัตราการประหยัดที่ใช้เป็นพาดหัวคำนวณจาก ยอดเรียกเก็บรวม ไม่ใช่เฉพาะ input slice
  • จากสแนปช็อตคำขอ 13,709 รายการ ค่าใช้จ่าย $100 ลดเหลือประมาณ $41 คิดเป็นการประหยัด 59%
  • จาก trace ของคำขอที่ถูกบีบอัด 8,904 รายการภายหลัง วัดได้ประมาณ 70%
  • หากดูเฉพาะคำขอที่ถูกบีบอัดอย่างเดียว ตัวเลขอยู่ราว 72~74% แต่ README ไม่ใช้ตัวเลขนี้เป็นพาดหัว
  • ทุก /v1/messages POST จะรัน count_tokens แบบ counterfactual ฟรีกับบอดีต้นฉบับที่ยังไม่บีบอัดแบบขนานกัน
  • ปริมาณการใช้งานที่ถูกเรียกเก็บจริงอ่านจาก usage block ในคำตอบของ Anthropic
  • ค่าต้นฉบับและค่าจริงจะถูกบันทึกในบรรทัดเดียวกันของ ~/.pxpipe/events.jsonl เพื่อหลีกเลี่ยงตัวแปรรบกวนจากจำนวนเทิร์นหรือความต่างระหว่างแต่ละรัน
  • การแปลงเป็นดอลลาร์ใช้สัดส่วนราคาเต็มของ Fable 5
    • input ×1.0
    • cache write ×1.25
    • cache read ×0.1
    • output ×5
  • ราคาแคชถูกใช้เหมือนกันทั้งสองฝั่ง ดังนั้นส่วนลดจากแคชจะไม่ถูกนับซ้ำเป็นการประหยัด

การใช้งานแบบไลบรารี

import { renderTextToPngs, transformAnthropicMessages } from "pxpipe";

const imgs = await renderTextToPngs(toolResultText);            // RenderedImage[]
const { body, applied, info } = await transformAnthropicMessages({
  body: requestBytes,
  model: "claude-fable-5",
});
  • ใช้งานเป็นไลบรารีได้โดยไม่ต้องผ่านพร็อกซี
  • options.keepSharp(block) ใช้ตรึงบางบล็อกให้คงเป็นข้อความ
  • options.emitRecoverable จะคืนค่าต้นฉบับของบล็อกที่ถูกแปลงเป็นภาพ
  • รันไทม์เป็น Pure JS และรองรับ Node กับ edge/Workers
  • @napi-rs/canvas ใช้เฉพาะตอน build เท่านั้น
  • API ทั้งหมดอยู่ที่ src/core/index.ts

ความล้มเหลวจริงและข้อจำกัด

  • ระหว่างการใช้งานจริงหลายสัปดาห์ มีหนึ่งครั้งที่ระบบจำชื่อคนจากประวัติแชตที่ถูกแปลงเป็นภาพผิดอย่างมั่นใจ
  • เซสชันการเขียนโค้ดมักอ่านไฟล์ซ้ำก่อนแก้ไข จึงพอทนกับ failure mode นี้ได้ แต่การทวนคืนจากแชตล้วนไม่มีการตรวจสอบแบบเดียวกัน
  • ใน legibility audit มีการวัดความสามารถในการทวนคืนสตริงที่ถูกต้องจากหน้าที่เรนเดอร์
    • การอ่าน identifier หนาแน่นแบบ blind read ทำได้สูงสุด 63%
    • miss ทั้งหมดคาดการณ์ได้จาก glyph-confusability matrix
    • มีการใช้วิธีลดผลกระทบด้วยการจำกัด page geometry ให้สอดคล้องกับ API resample cap
    • identifier ที่ต้องแม่นเป๊ะอย่าง SHA และตัวเลขจะถูกแนบเป็นข้อความด้วย
  • ยังมีข้อจำกัดที่ระบุไว้ชัดเจน
    • verbatim recall จากภาพเชื่อถือได้ยาก
    • คำขอขนาดใหญ่มีความหน่วงเพิ่มจากการเข้ารหัส PNG ก่อนส่ง
    • ASCII/Latin-1 ถูกทดสอบมาอย่างดี
    • CJK ใช้งานได้แต่จะถูกจัดการอย่างระมัดระวัง

การพัฒนาและโรดแมป

pnpm install && pnpm test
pnpm run build                # regenerates dist/
  • คำสั่งสำหรับการพัฒนาประกอบด้วยการติดตั้ง การทดสอบ และการ build
  • ไลเซนส์เป็น MIT
  • โรดแมปถูกนำเสนอในฐานะสมมติฐานเท่านั้น และหากไม่มีตัวเลขกับขนาดตัวอย่างกำกับ จะไม่นับเป็น claim
    • การเรนเดอร์ glyph ให้คมชัดขึ้น
    • ตรวจว่าการทำ bulk เป็นภาพจะเพิ่ม effective context ได้ราว 2 เท่าในหน้าต่าง 1M เดียวกันหรือไม่
    • ตรวจว่าการมี active context ที่เล็กลงจะเพิ่มความแม่นยำในงานระยะยาวหรือไม่

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 5 시간 전
ความคิดเห็นบน Hacker News

  • เท่าที่ดูจาก Gemini ผมเข้าใจว่าเวลาประมวลผล PDF จะทำ OCR ก่อน แล้วใส่ทั้งข้อความและรูปภาพเข้าโมเดลร่วมกัน โดยไม่คิดค่าข้อความเป็นโทเคน
    ถ้าแบ็กเอนด์ของ Claude ก็ทำแบบเดียวกัน แฮ็กนี้ก็ใกล้เคียงกับช่องโหว่ของวิธีคิดราคาโทเคน และถ้า Claude ทำงานเหมือน Gemini ก็มีโอกาสสูงที่จะถูกปิดในภายหลัง

    • ประเด็นนี้น่าสนใจมาก ตอนแรกผมคิดว่า “ยังไงภายในมันก็น่าจะถูกแปลงเป็นโทเคนข้อความสักตอนหนึ่ง ดังนั้นจากมุมของ Claude ต้นทุนรันจริงไม่น่าจะถูกลงได้”
      แต่ในคอมเมนต์ด้านล่างมีคนพูดว่า DeepSeek ปรับปรุงอัตราการบีบอัดได้มากด้วย โทเคนภาพ: https://news.ycombinator.com/item?id=48777848
      ผมไม่ได้เข้าใจรายละเอียดเชิงเทคนิคภายในทั้งหมด เลยยังไม่ค่อยเข้าใจว่าทางเดินผ่าน OCR จะนำไปสู่การลดการใช้พลังงานหรือค่าคำนวณโดยรวมได้อย่างไร
    • ไม่จำเป็นต้องเป็นแบบนั้น ดูบทความวิจัย DeepSeek-OCR: Contexts Optical Compression ได้: https://arxiv.org/abs/2510.18234
      วิธีหนึ่งในการใส่รูปภาพเข้า LLM คือแบ่งภาพเป็นไทล์ แล้วส่งไทล์เหล่านั้นผ่านเครือข่ายประสาท vision encoder เพื่อสร้าง โทเคนภาพ จากนั้นป้อนเข้า LLM เหมือนโทเคนข้อความ แน่นอนว่าต้องฝึกให้ vision encoder กับ LLM เข้าใจกัน วิธีแบบนี้เรียกว่าโมเดล OCR แบบ end-to-end
      เมื่อมีโมเดลที่ฝึกแบบนี้แล้ว ก็สามารถขยายหรือย่อภาพเอกสารเพื่อเปลี่ยนจำนวนโทเคนภาพที่ใช้แทนเอกสารข้อความเดียวกันได้ และยังปรับพารามิเตอร์อย่างขนาดแพตช์หรือความซับซ้อนของ vision encoder ได้ด้วย
      ผลลัพธ์ค่อนข้างดี และในการทดสอบบางส่วนลดโทเคนอินพุตได้ 90% แต่ยังคงประสิทธิภาพเอาต์พุตไว้ได้ 97%
    • Claude Science มีเครื่องมือสำหรับดึงข้อมูลจาก PDF แต่ไม่แน่ใจว่ามันทำ OCR จริงหรือไม่

  • ปีที่แล้วผมลองทำแบบเดียวกันกับโมเดลของ OpenAI ตอนนั้นมันช่วยลดโทเคนพรอมป์ได้จริง แต่ต้องใช้ โทเคนคำตอบ มากขึ้นมาก สุดท้ายเลยแพงกว่าและช้ากว่า
    https://pagewatch.ai/blog/post/llm-text-as-image-tokens/

  • โอ๊ย แสบตา เหมือน README ที่เขียนแบบ vibe coding เลย

    • คำอธิบายที่ LLM บีบอัดมาอ่านแล้วทรมานมาก บอกยากว่าเพราะอะไรกันแน่ แต่เห็นปุ๊บก็รู้ทันที และต้องใช้ความพยายามทำความเข้าใจมากขึ้นจริง ๆ เป็นสองเท่า
      ตัวอย่างเช่น:

      Honest caveat, visible in the clip: the pxpipe arm answered the count first and needed one follow-up nudge to also print the ledger balance in the requested one-line format; the plain arm followed the format on the first try. Legibility is solved on Fable — single-reply format compliance is the remaining rough edge.
      ถ้าอ่านซ้ำสี่รอบก็พอปะติดปะต่อได้คร่าว ๆ ว่าเกิดอะไรขึ้น แต่ส่วนใหญ่เป็นข้อมูลที่ไม่จำเป็นและทำให้สับสน
      ทุกโมเดลเขียนแบบนี้ในระดับหนึ่ง แต่ Claude ดูจะหนักเป็นพิเศษ ส่วน GPT 5.5 ให้ความรู้สึกกระชับกว่าและบีบอัดข้อมูลที่มีคุณค่ามากกว่า

    • เวลามีคนจะแชร์สิ่งที่ตัวเองทำ แล้วเห็น README แบบ vibe coding ผมถือว่าเป็นสัญญาณแรงมากว่าเจ้าตัวไม่ได้เข้าใจสิ่งที่สร้างขึ้นดีพอที่จะอธิบายอย่างมีน้ำหนัก
      การใช้ AI สร้างของที่มีประโยชน์จริง ๆ เป็นไปได้ โดยเฉพาะในสาขาที่คุณมีความเชี่ยวชาญอยู่แล้ว แต่ถ้าเป็นอย่างนั้นก็ควร 1) เปิดเผยว่าใช้ความช่วยเหลือจาก AI และ 2) อธิบายด้วยคำพูดของตัวเองว่าตกลงสร้างอะไรขึ้นมา ถ้าพูดถึงข้อจำกัดของการทำงานกับ AI ได้ด้วยก็ยิ่งดี
      แบบนั้นถึงจะเกิดความเชื่อใจว่า “ของที่คนนี้ทำน่าลองจับดู เขาเข้าใจสิ่งที่ตัวเองสร้างจริง ๆ”
      ของที่ออกมายุคนี้ 99% เป็นผลจากคนทำงานในพื้นที่ที่ตัวเองไม่เข้าใจเลย พอเห็น README แบบนั้นผมก็ปิดแท็บทันที

  • นี่ดูเหมือน แฮ็กด้านการตั้งราคา ที่เผาทรัพยากรทิ้ง ถ้าช่องโหว่ถูกปิด ราคา OCR ก็ควรต้องสูงขึ้นไม่ใช่หรือ?

    • ไม่ใช่ช่องโหว่เสียทีเดียว แต่ใกล้เคียงกับการที่การเข้ารหัสข้อมูลเป็น โทเคนเชิงแสง มีประสิทธิภาพมากกว่าข้อความมาก
    • ไม่จำเป็นเสมอไป วิธีนี้ไม่ได้ใช้ทรัพยากรมากกว่าจริง ๆ ด้วยซ้ำ อาจเป็นการกำจัดความไร้ประสิทธิภาพพื้นฐานมากกว่า
      ลองคิดดูก็สมเหตุสมผล คนเราก็อ่านโค้ดทีละคำก็จริง แต่โดยมากเรากวาดตาดูแล้วใช้การรู้จำแพตเทิร์นเพื่อจับคร่าว ๆ ว่ามันทำอะไร จะเพ่งไปยังส่วนเฉพาะก็ต่อเมื่อต้องตอบคำถามเฉพาะเจาะจง
      ผมมองว่ามนุษย์เองก็ทำ การปรับให้เหมาะสมแบบอ้อม ๆ คล้ายกันโดยธรรมชาติ

  • บทความที่เกี่ยวข้อง: https://blog.can.ac/2026/06/10/snapcompact/

  • วิธีนี้ต้องระวัง เหตุผลที่ต้นทุนลดลงอาจเป็นเพราะจริง ๆ แล้วมันสลับไปใช้โมเดลอื่นที่ประสิทธิภาพต่ำกว่า
    ภายนอกอาจดูเหมือน Fable แต่จริง ๆ อาจไม่ใช่ ถ้าเป็นแบบนั้นก็เท่ากับทำงานเพิ่มเปล่า ๆ และอาจดีกว่าถ้าย้อนโมเดลกลับไปเป็น opus 4.8

  • Oh-My-Pi(OMP.sh) ดูเหมือนจะใช้รูปภาพในการบีบอัดบริบท OMP สร้างอยู่บนเอเจนต์เขียนโค้ด Pi

  • มีไวต์เปเปอร์ของ DeepSeek เกี่ยวกับเทคนิคนี้ด้วย: https://www.seangoedecke.com/text-tokens-as-image-tokens

  • ก่อนหน้านี้ผมเคยเห็นทวีตของใครสักคน น่าจะเป็น Carmack, Geohot หรือ Karpathy คนใดคนหนึ่ง เนื้อหาประมาณว่า รูปภาพอาจเป็นตัวเลือกที่ดีกว่า ก็ได้
    ตั้งแต่นั้นมา เวลาจะบอกเอเจนต์ว่าตอนนี้เกิดอะไรขึ้น ผมก็ใช้รูปภาพร่วมกับพรอมป์ที่เป็นประโยคง่าย ๆ มาก และบางครั้งก็ไม่ใส่ข้อความในพรอมป์เลย
    ผลลัพธ์ดีมาก
    แต่สิ่งนี้ไม่ใช่สิ่งเดียวกับที่ Karpathy พูดอย่างเป๊ะ ๆ ถึงอย่างนั้นแนวคิดนั้นก็พาไปสู่เวิร์กโฟลว์ที่ดีกว่า

  • ขอโทษนะ แต่นี่ไร้สาระมาก มันใช้งานได้และฉลาดก็จริง แต่ชัดเจนว่าเป็นวิธีเลี่ยง ความล้มเหลวด้านการตั้งราคา
    เหมือนกรณีเงินรางวัลจับงูพิษที่ทำให้คนเริ่มเพาะงู นี่คือการใช้ประโยชน์จากความสูญเปล่าและยิ่งส่งเสริมมัน
    สุดท้ายผมคิดว่าความรับผิดชอบอยู่ที่ระบบราคาที่แย่ของ Anthropic ซึ่งทำให้เกิดการเก็งกำไรแบบนี้ได้ แต่จนกว่าจะถูกแก้ คนที่มาใช้ประโยชน์จากมันก็จะแห่กันเข้ามา และจะมีขยะดิจิทัลที่ไม่จำเป็นอย่างสิ้นเชิงทะลักออกมาเพิ่มอีก ซึ่งน่ารังเกียจ