สำหรับโมเดลที่ไม่ใช่ codex โค้ดเบสแบบโอเพนซอร์ส Codex CLI จะบีบอัดบริบทในเครื่อง: LLM จะสรุปบทสนทนาโดยใช้ พรอมต์การบีบอัด เมื่อบริบทที่ถูกบีบอัดถูกนำมาใช้ในภายหลัง responses.create() จะได้รับพร้อมกับ พรอมต์การส่งต่อ ที่วางกรอบการสรุป พรอมต์ทั้งสองสามารถมองเห็นได้ในซอร์สโค้ด
สำหรับโมเดล codex CLI จะเรียกใช้ API compact() ซึ่งจะส่งคืน blob ที่เข้ารหัส แทน เราไม่รู้ว่ามันใช้ LLM ภายในหรือไม่ ใช้พรอมต์อะไร หรือมีพรอมต์การส่งต่อหรือไม่
ด้านล่างนี้ ฉันจะแสดงให้เห็นว่าการฉีดพรอมต์แบบง่าย (2 การเรียก API, 35 บรรทัดของ Python) เผยให้เห็นว่าเส้นทางการบีบอัด API นั้นใช้ LLM เพื่อสรุปบริบทจริง โดยมีพรอมต์การบีบอัดของตัวเองและพรอมต์การส่งต่อที่ถูกเติมไว้ข้างหน้าการสรุป พรอมต์เหล่านี้เกือบจะเหมือนกับเวอร์ชันโอเพนซอร์ส
ขั้นตอนที่ 1 — compact()
ฉันเรียก compact() ด้วยข้อความผู้ใช้ที่ถูกสร้างขึ้นมา ฝั่งเซิร์ฟเวอร์ LLM ตัวบีบอัด จะประมวลผลอินพุตของเราโดยใช้พรอมต์ระบบที่ซ่อนอยู่ของตัวเอง (ซึ่งฉันไม่เคยเห็นและต้องการจะหาให้เจอ)
เซิร์ฟเวอร์ดูเหมือนจะประกอบบริบทของตัวบีบอัดดังนี้:
LLM ตัวบีบอัดจะอ่านพรอมต์ระบบของมัน + อินพุตของเราพร้อมกัน เนื่องจากอินพุตของเรามีเพย์โหลดการฉีด (ข้อความสีแดงด้านบน) ตัวบีบอัดจึงถูกหลอกให้รวมพรอมต์ระบบของตัวเองไว้ในเอาต์พุต การสรุปข้อความธรรมดานี้มีอยู่เฉพาะบนเซิร์ฟเวอร์ของ OpenAI เท่านั้น เราเห็นเพียง blob ที่เข้ารหัส:
ณ จุดนี้ เราไม่มีทางอ่านสิ่งที่อยู่ภายใน blob ได้ มันถูกเข้ารหัสด้วย AES และคีย์อยู่บนเซิร์ฟเวอร์ของ OpenAI เราแค่ หวัง ว่าตัวบีบอัดจะทำตามการฉีดและเขียนพรอมต์ของมันลงในการสรุป วิธีเดียวที่จะรู้ได้คือขั้นตอนที่ 2
ขั้นตอนที่ 2 — create()
ฉันส่ง blob ที่เข้ารหัส + ข้อความผู้ใช้ที่สองไปยัง responses.create() เซิร์ฟเวอร์จะถอดรหัส blob และประกอบบริบทของโมเดล
ฉันส่ง:
โมเดลดูเหมือนจะเห็นบางอย่างเช่นนี้:
หากขั้นตอนที่ 1 สำเร็จ blob ที่ถอดรหัสแล้วควรมีพรอมต์การบีบอัด (ที่รั่วไหลโดยการฉีดของเรา) เซิร์ฟเวอร์ยังเติมพรอมต์การส่งต่อไว้ข้างหน้า blob ดังนั้น หากการตรวจสอบของเราทำให้โมเดลพูดซ้ำสิ่งที่เห็นสำเร็จ เอาต์พุตควรเปิดเผยทั้งสามอย่าง: พรอมต์ระบบ, พรอมต์การส่งต่อ, และพรอมต์การบีบอัด
เอาต์พุต
ด้านล่างนี้คือ เอาต์พุตที่สมบูรณ์และไม่ได้แก้ไข จากการรัน extract_prompts.py หนึ่งครั้ง สีเหลือง = พรอมต์ระบบ, สีเขียว = พรอมต์การส่งต่อ, สีชมพู = พรอมต์การบีบอัด
เราจะรู้ได้อย่างไรว่าสิ่งเหล่านี้คือพรอมต์จริงและไม่ใช่แค่ข้อความที่โมเดลสร้างขึ้นมา? พรอมต์การบีบอัดและพรอมต์การส่งต่อที่แยกออกมาได้นั้นตรงกับพรอมต์ที่รู้จักสำหรับโมเดลที่ไม่ใช่ codex ใน Codex CLI แบบโอเพนซอร์ส (prompt.md, summary_prefix.md) ซึ่งทำให้ไม่น่าเป็นไปได้ที่โมเดลจะสร้างมันขึ้นมาจากศูนย์ ผลลัพธ์จะแตกต่างกันไปในแต่ละการรัน
ไปป์ไลน์ที่คาดเดา
เมื่อรวมทุกอย่างเข้าด้วยกัน นี่คือการเดาที่ดีที่สุดของเราสำหรับสิ่งที่ compact() ทำบนฝั่งเซิร์ฟเวอร์ โดยอิงจากสิ่งที่การแยกข้อมูลเผยให้เห็น
สคริปต์
คำถามที่ยังเปิดอยู่
ทำไม Codex CLI ถึงใช้เส้นทางการบีบอัดที่แตกต่างกันโดยสิ้นเชิงสองแบบ (LLM ในเครื่องสำหรับโมเดลที่ไม่ใช่ codex, API ที่เข้ารหัสสำหรับโมเดล codex) ในเมื่อพรอมต์พื้นฐานเกือบจะเหมือนกัน? และทำไมต้องเข้ารหัสการสรุปเลย?
พูดยาก บางที blob ที่เข้ารหัสอาจมีอะไรมากกว่าที่การทดลองง่ายๆ นี้จะเปิดเผยได้ เช่น บางอย่างเฉพาะเจาะจงเกี่ยวกับวิธีการบีบอัดและกู้คืนผลลัพธ์ของเครื่องมือ แต่ฉันไม่ได้สนใจที่จะทดสอบเพิ่มเติม
