เซสชันที่พกพาไปไม่ได้: การพึ่งพารูปแบบใหม่ที่ API สำหรับการอนุมานสร้างขึ้น

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

---

API สำหรับการอนุมานกำลังเปลี่ยนความเป็นเจ้าของเซสชัน

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

เกณฑ์ห้าข้อในการตัดสินความสามารถในการย้ายเซสชัน

• การพกพาได้ไม่ได้หมายความว่าเมื่อเปลี่ยนโมเดลแล้วโทเคนถัดไปต้องเหมือนเดิม
  • แต่ละโมเดลมีความสามารถ แนวโน้มที่เรียนรู้มา หน้าต่างบริบท และวิธีใช้เครื่องมือต่างกัน อีกทั้งเอาต์พุตเองก็ไม่เป็นเชิงกำหนด
• บันทึกที่ส่งออกต้องมีข้อมูลที่โมเดลใหม่เข้าใจได้เพียงพอสำหรับทำงานต่อ และไม่ควรต้องให้ผู้ให้บริการเดิมค้น ID ถอดรหัส หรือกู้ผลการค้นหาและสรุปกลับมา
• การตรวจสอบ (Inspection): ผู้ใช้ต้องมองเห็นข้อมูลที่โมเดลเห็น งานที่เครื่องมือทำ และสิ่งที่เอเจนต์สื่อสารกัน
• การส่งออก (Export): ยกเว้นผลลัพธ์ทั่วไปที่ดาวน์โหลดแยกได้ ตัวเซสชันเองต้องครบถ้วนในตัว
• การเล่นซ้ำ (Replay): การติดตั้งใช้งานแบบอื่นต้องสร้างบริบทที่เทียบเท่ากันในเชิงความหมายได้
• การตรวจประเมิน (Audit): หลังเกิดเหตุ มนุษย์ต้องอธิบายได้ว่าระบบทำพฤติกรรมหนึ่งเพราะอะไร
• การลบ (Deletion): ต้องระบุและลบสำเนาฝั่งเซิร์ฟเวอร์ทั้งหมดที่เซสชันพึ่งพาได้
• ID การตอบกลับที่เป็นคีย์ของข้อมูลเซิร์ฟเวอร์ไม่ใช่ประวัติการสนทนา และข้อความเข้ารหัสที่ผู้ใช้ถอดไม่ได้ก็ไม่ใช่สถานะภายใต้การควบคุมของผู้ใช้
• รายการ URL อ้างอิงเพียงอย่างเดียวไม่สามารถแทน หลักฐาน ที่เข้าไปอยู่ในบริบทของโมเดลจริงระหว่างการค้นหาได้

การเข้ารหัสที่ผู้ใช้ถอดไม่ได้

• ชื่อ encrypted_content ดูเหมือนเป็นฟีเจอร์คุ้มครองข้อมูลส่วนบุคคลภายใต้การควบคุมของผู้ใช้ แต่โดยทั่วไปเป็นแคปซูลที่ไคลเอนต์อ่านไม่ได้และมีเพียงผู้ให้บริการเท่านั้นที่เปิดได้
• เพราะผู้ให้บริการเลือกคีย์ ถอดรหัสเพื่อโมเดลของตนเอง และเป็นผู้กำหนดว่าสภาพแวดล้อมใดเล่นซ้ำได้ ชื่อที่แม่นยำกว่าคือ สถานะที่ผู้ให้บริการปิดผนึกไว้ (provider-sealed state)
• การปิดผนึกโดยผู้ให้บริการอาจให้ประโยชน์ด้านความเป็นส่วนตัวจริงได้
  • OpenAI คืนการอนุมานที่เข้ารหัสให้ไคลเอนต์ใน store: false และในการร้องขอครั้งถัดไปสามารถถอดรหัสในหน่วยความจำได้โดยไม่เก็บสถานะระหว่างกลางไว้
  • โดยเฉพาะอย่างยิ่ง ดีกว่าวิธีที่บังคับให้ลูกค้า Zero Data Retention ต้องเก็บบทสนทนาฝั่งเซิร์ฟเวอร์
• แต่การเข้ารหัสนี้ไม่ได้ซ่อนข้อมูลจากผู้ให้บริการอนุมาน แต่ ซ่อนจากผู้ใช้เท่านั้น

บทสนทนาแบบจัดเก็บเปลี่ยนบันทึกให้กลายเป็นพอยน์เตอร์อย่างไร

• OpenAI Responses API จะจัดเก็บการตอบกลับโดยค่าเริ่มต้น และตามเอกสารจะเก็บออบเจ็กต์การตอบกลับไว้อย่างน้อย 30 วัน
• เมื่อใช้ store: false ข้อมูลจะไม่ถูกเก็บบนเซิร์ฟเวอร์ OpenAI จึงใกล้เคียงกับวิธี completions แบบเดิม
• Gemini Interactions API ก็มีค่าเริ่มต้นเป็น store: true
  • ระดับแบบชำระเงินเก็บการโต้ตอบไว้ 55 วัน
  • ระดับฟรีเก็บไว้ 1 วัน
• การจัดเก็บบนเซิร์ฟเวอร์ลดปริมาณข้อมูลที่แอปพลิเคชันต้องส่ง รักษาการอนุมานและสถานะเครื่องมือที่ซ่อนอยู่ และทำให้การกำหนดเส้นทางแคชง่ายขึ้น
• แต่ถ้าแอปพลิเคชันในเครื่องบันทึกไว้เพียงข้อความของผู้ใช้และข้อความสุดท้าย ID การตอบกลับที่ใช้ใน previousResponseId ก็จะกลายเป็น foreign key ของฐานข้อมูลภายนอกที่ควบคุมไม่ได้

บันทึกการอนุมานที่ไม่เปิดเผย

• แล็บ AI รายใหญ่เห็นว่ามีเหตุผลที่จะไม่เปิดเผยกระบวนการคิดดิบ (chain of thought) และโดยทั่วไปไม่เปิดเผยโทเคนการอนุมานของโมเดลน้ำหนักปิดผ่าน API
• ใน OpenAI สามารถกู้การอนุมานก่อนหน้าของการตอบกลับแบบจัดเก็บได้ด้วย previous_response_id
  • ใน store: false ไคลเอนต์ต้องเก็บ encrypted_content แล้วส่งกลับในการร้องขอครั้งถัดไป
  • แม้จะใช้ reasoning.context: "all_turns" สำหรับการสร้างต่อไปได้ การอนุมานที่จัดเก็บไว้ก็ยังทึบอยู่
• Anthropic คืน thinking ฉบับเต็มที่เข้ารหัสไว้ในฟิลด์ signature
  • ข้อความ thinking ที่อ่านได้ซึ่งเปิดใช้ได้ไม่ใช่กระบวนการคิดดิบ แต่เป็นสรุปที่โมเดลอื่นสร้างขึ้น
  • ในรอบที่ใช้เครื่องมือ ต้องส่งบล็อก thinking กลับไปโดยไม่แก้ไข
  • บล็อก thinking ผูกกับโมเดลที่สร้างมันขึ้นมา จึงต้องลบออกเมื่อเปลี่ยนโมเดล ดังนั้นแม้ภายใน Anthropic เองก็ไม่ได้มีเป้าหมายให้พกพาได้
• วิธีเหล่านี้ให้ความต่อเนื่องภายในอีโคซิสเต็มเดียวกัน แต่ไม่ได้สร้าง ประวัติการสนทนาที่พกพาได้ ซึ่งโมเดลของผู้ให้บริการรายอื่นสามารถตีความได้

ช่องว่างของบันทึกที่การค้นหาแบบโฮสต์ทิ้งไว้

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

การบีบอัดบริบทที่ทึบ

• เซสชันเอเจนต์ที่ยาวจำเป็นต้องมีการบีบอัด และสรุปที่อ่านได้ซึ่งไคลเอนต์ควบคุม แม้มีการสูญเสียข้อมูล ก็ยังตรวจสอบ แก้ไข และย้ายได้
• การบีบอัดฝั่งเซิร์ฟเวอร์ของ OpenAI คืนรายการ compaction ที่เข้ารหัสซึ่งไม่ได้สร้างมาให้มนุษย์ตีความ
  • /responses/compact คืน canonical next context window ที่ไคลเอนต์ต้องส่งต่อไปตามเดิม
  • OpenAI สามารถสานต่อความหมายที่ถูกบีบอัดได้ แต่ผู้ให้บริการรายอื่นจะได้รับเพียงข้อความเข้ารหัสกับบางส่วนของบริบทล่าสุด
• การบีบอัดแบบทึบไม่ใช่สิ่งที่หลีกเลี่ยงไม่ได้ในเชิงเทคนิค
  • การบีบอัดฝั่งเซิร์ฟเวอร์ของ Anthropic คืนบล็อก compaction ที่มีฟิลด์ content ซึ่งอ่านได้
  • ไคลเอนต์สามารถให้คำสั่งสรุปแบบกำหนดเอง และตรวจสอบผลลัพธ์หรือส่งต่อให้โมเดลอื่นได้
  • การบีบอัดฝั่งไคลเอนต์ก็ทำได้กับผู้ให้บริการทุกราย
• ผลลัพธ์ที่ OpenAI ปิดผนึกไว้อาจรักษาสถานะเฉพาะโมเดลได้ดีกว่าสรุปทั่วไป ทำให้มีประสิทธิภาพสูงกว่าในโมเดลเดิม แต่ควรเสนอเป็นการปรับแต่งแบบเลือกได้ พร้อมกับให้ สรุปส่งมอบที่อ่านได้ ด้วย

การมอบหมายและการสื่อสารที่ซ่อนอยู่ของระบบหลายเอเจนต์

• ระบบหลายเอเจนต์ไม่ได้มีบันทึกเดียว แต่มีต้นไม้เซสชันและการไหลของข้อความระหว่างเอเจนต์ จึงทำให้ปัญหาการพกพาหนักขึ้น
• OpenAI Responses Multi-agent เบต้าเพิ่มรายการ multi_agent_call, multi_agent_call_output, agent_message
  • อาร์กิวเมนต์ message ในตัวอย่าง spawn_agent ถูกเข้ารหัส
  • ข้อความระหว่างเอเจนต์มีเพียง encrypted_content
  • เมื่อเปิดใช้ Multi-agent การบีบอัดอัตโนมัติฝั่งเซิร์ฟเวอร์จะถูกใช้กับทุกเอเจนต์แม้ไคลเอนต์ไม่ได้ร้องขอ
  • ไม่รองรับสรุปการอนุมาน และมีการแทรกคำสั่งของรูทและเอเจนต์ย่อยที่นักพัฒนาแก้ไขหรือลบไม่ได้
• ผลคือการมอบหมายและข้อความที่ถูกปิดผนึก บริบทที่ถูกบีบอัดอัตโนมัติแยกกัน การอนุมานที่ซ่อนอยู่ และการออร์เคสเตรชันที่ผู้ให้บริการโฮสต์ รวมกันเป็น ชุดสถานะที่ย้ายไม่ได้
• ในเดือนมิถุนายน 2026 ไคลเอนต์ Codex แบบโอเพนซอร์สมีการเปลี่ยนแปลง Encrypt multi-agent v2 message payloads
  • Responses API เข้ารหัสอาร์กิวเมนต์เครื่องมือของโมเดลแม่
  • เมื่อ Codex ส่งต่อข้อความเข้ารหัส API จะถอดรหัสภายในให้โมเดลลูก
  • InterAgentCommunication.content ของ Codex ว่างเปล่า ทำให้คำสั่งงานที่แม่นยำไม่หลงเหลือในบันทึกการรันและประวัติที่อ่านได้
• เมื่อเอเจนต์ลูกแก้ไฟล์ผิด ทำข้อมูลลับรั่ว ทำงานซ้ำกับงานอื่น หรือทำตามสมมติฐานที่ผิด ผู้ใช้ก็ไม่สามารถตรวจสอบได้ว่า ได้รับคำสั่งอะไร
• ประเด็นสาธารณะของ Codex เรียกร้องให้เก็บสำเนาตรวจประเมินที่อ่านได้แยกจากการส่งต่อแบบเข้ารหัส
  • นี่เป็นการออกแบบขั้นต่ำ และข้อความระหว่างเอเจนต์แบบ plaintext ควรเป็นค่าเริ่มต้น

ทำไมจึงต้องมีเสรีภาพในการย้ายเซสชัน

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

หลักการของ API อนุมานที่พกพาได้

• บันทึกเหตุการณ์ในเครื่องควรเป็นบันทึกหลัก
  • การจัดเก็บบนเซิร์ฟเวอร์อาจคัดลอกหรือเร่งความเร็วได้ แต่ไคลเอนต์ต้องสร้างเซสชันขึ้นใหม่ได้โดยไม่ต้องค้น ID บนเซิร์ฟเวอร์
• การจัดเก็บควรเป็นตัวเลือกที่เลือกอย่างชัดเจน
  • store: false ควรใช้ง่าย มีเอกสารชัดเจน และควรเป็นค่าเริ่มต้นหากเป็นไปได้
  • ฟีเจอร์ที่จำเป็นต้องมีการเก็บรักษาควรแจ้งให้ทราบในเวลาที่ใช้

• รายการที่ทึบไม่ควรผูกขาดความหมาย

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

• ผลลัพธ์ต้องส่งออกได้

  • ไฟล์ เอาต์พุตคอนเทนเนอร์ สแนปช็อตการค้นหา และสื่อที่สร้างขึ้น ต้องดาวน์โหลดเป็นอาร์ไคฟ์ในเครื่องแบบอิงที่อยู่เนื้อหาได้

การกลั่นและการพึ่งพาในลำดับชั้นของโมเดล

• แล็บวิจัยน้ำหนักปิดขนาดใหญ่บางแห่งในสหรัฐฯ มีท่าทีเป็นปฏิปักษ์ต่อการกลั่นจากภายนอกมากขึ้น
• Anthropic เรียกกิจกรรมของ DeepSeek, Moonshot และ MiniMax ว่า distillation attacks ในโพสต์เดือนกุมภาพันธ์ 2026
  • เงื่อนไขเชิงพาณิชย์ระบุว่าลูกค้าเป็นเจ้าของเอาต์พุต แต่ห้ามใช้เอาต์พุตของบริการเพื่อฝึกโมเดล AI คู่แข่ง
  • ขณะเดียวกัน ในโพสต์ของตนเองก็ยอมรับว่าการกลั่นเป็นวิธีฝึกที่ถูกต้องตามกฎหมายและใช้กันแพร่หลายเมื่อแล็บชั้นนำใช้กับโมเดลของตนเอง
• Anthropic รวบรวมข้อมูลเว็บสาธารณะด้วยบอตและตัดหนังสือเพื่อสแกนสำหรับการพัฒนาโมเดล ส่วน OpenAI ก็กล่าวว่าฝึกด้วยเนื้อหาอินเทอร์เน็ตสาธารณะที่เข้าถึงได้อย่างเสรี และอ้างว่านี่เป็นการใช้งานโดยชอบธรรม
• ทั้งสองบริษัทถือว่าการกลั่นเป็นวิธีทั่วไปเมื่อสร้างโมเดลขนาดเล็กลงภายใน
  • OpenAI ยังเคย提供 เวิร์กโฟลว์การกลั่นโมเดลผ่าน API ของตน เพื่อปรับจูนโมเดล OpenAI ขนาดเล็กด้วยเอาต์พุตจากโมเดล OpenAI ที่แข็งแกร่งกว่า
• มี ความไม่สมมาตรทางศีลธรรม ที่เรียกร้องว่างานมหาศาลที่มนุษย์โพสต์บนอินเทอร์เน็ตควรให้เครื่องเรียนรู้ได้ แต่กลับไม่ยอมให้เครื่องอื่นเรียนรู้จากเอาต์พุตที่แล็บสร้างขึ้น
• การกลั่นสามารถย้ายความสามารถของโมเดลฟรอนเทียร์ราคาแพงไปยังโมเดลที่เล็กกว่า ถูกกว่า และเร็วกว่าได้
  • สามารถรันในเครื่อง ออฟไลน์ บนฮาร์ดแวร์จำกัด หรือในสภาพแวดล้อมที่ผู้ใช้ควบคุมได้
  • เพิ่มการแข่งขัน รักษาความสามารถไว้แม้ API หายไป และลดปริมาณการคำนวณกับการใช้พลังงานของงานทั่วไป

เสรีภาพขั้นต่ำที่ผู้ใช้ควรได้รับการรับประกัน

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

[GN⁺]

ความเห็นจาก Hacker News

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

  • ผมสร้าง https://www.agentkanban.io โดยคำนึงถึงปัญหาที่บทสนทนาเซสชันเอเจนต์ที่มีคุณค่าหายไป สามารถเก็บบริบทไว้กับงานบนบอร์ด แล้วเรียกกลับมาใช้ใหม่ในเซสชันเอเจนต์ใหม่ภายหลังได้ ตอนนี้รองรับ Claude และ Github CoPilot ใน VS Code
    โดยตั้งใจไม่รวมประวัติการใช้เครื่องมือแบบปิด proprietary เพราะมันทำลาย ความสามารถในการย้ายเซสชัน
  • มองในแง่ดีว่า dark pattern เป็นแค่กลยุทธ์ชนะระยะสั้น และระยะยาวจะพ่ายให้กับแนวทางที่เคารพผู้ใช้และมุ่งประโยชน์ส่วนรวม อาจถึงเวลาที่ควรโฟกัสกับโมเดลที่เป็น open weights และดำเนินธุรกิจได้คุ้มทุน เพื่อรับมือกับความเป็นไปได้ที่กระแสจะเปลี่ยนเร็ว
  • ระหว่างรอให้ราคาลดลง ผมตั้งใจเก็บ ข้อมูลเซสชัน ของ Claude และ Codex ให้ได้มากที่สุด เพื่อนำไปใช้กับการ fine-tune โมเดลเปิดในอนาคต และได้ทำ parser กับเครื่องมือจัดเก็บเซสชันของตัวเองไว้แล้ว
  • ผมถึงขั้นจัดหา VRAM 96GB มาเพื่อรันโมเดลโลคัล แต่ตอนนี้ยังไม่มีโมเดลไหนเข้าใกล้ Codex ที่ใช้ GPT ได้เลย Laguna S2.1 NVFP4 เข้าใกล้มากพอสมควรในงานเขียนโค้ด แต่ก็ดูว่ายังอีกไกลกว่าโมเดลโลคัลจะเป็นทางเลือกทั่วไปที่จริงจังได้
  • https://indieweb.org/POSSE คือคำตอบ

• เป็นบทความที่สรุปปัญหาซึ่งผู้ใช้ AI ส่วนใหญ่แทบไม่ประเมินกันได้ดีมาก ผู้ให้บริการ reasoning ระดับแนวหน้ามักห่อฟีเจอร์ที่ไม่ใช่ LLM อย่างเว็บเสิร์ชและการรันโค้ดให้ดูเหมือนเป็นแค่เครื่องมือ แต่จริง ๆ แล้วมันสร้าง กำแพงทางเข้า และการผูกติดที่แข็งแรง
  ในทางทฤษฎีมันแยกออกจาก reasoning API แล้ว externalize ไปเป็น MCP server ได้ แต่ผู้ให้บริการไม่ค่อยปล่อยมาแบบนั้น และฟังก์ชันของผู้ให้บริการทางเลือกก็มักอ่อนกว่า ตอนทำ https://github.com/EratoLab/erato ซึ่งเป็นแพลตฟอร์มแชตแบบ on-premise และไม่ขึ้นกับผู้ให้บริการ ก็พบว่าแม้แต่ฟีเจอร์ที่ดูง่ายอย่างการสร้างภาพในแชตก็ทำยาก สาเหตุหนึ่งคือ MCP ยังไม่มีสเปกพื้นฐานสำหรับการส่งไฟล์: https://github.com/modelcontextprotocol/modelcontextprotocol...
  หวังว่าเมื่อความสนใจในโมเดล open weights เพิ่มขึ้น จะมี implementation ทางเลือกที่สลับเปลี่ยนได้ง่ายขึ้นมากขึ้น

  • การทำให้เอเจนต์ที่มอง prompt ไม่ได้เลย เช่น ข้อความของ sub-agent ที่เข้ารหัสไว้ มารันบนเครื่องโลคัลนั้น ไม่รับผิดชอบโดยพื้นฐาน แต่การที่ผู้ให้บริการมีเครื่องมือแบบโฮสต์ให้เลยนั้น ผมไม่มองว่าเป็นปัญหา มันคล้ายของวางขายกระตุ้นซื้อหน้าแคชเชียร์
    การสร้างภาพไม่ควรทำผ่าน MCP แค่เขียนเครื่องมือเองก็พอ มีผู้ให้บริการ inference ด้านภาพและสื่ออย่าง Fal รวมถึงผู้ให้บริการเว็บเสิร์ชและ deep research อยู่มากพอแล้ว

• อาจจำเป็นต้องมี มาตรฐานเปิดหรือรูปแบบไฟล์ สำหรับบริบท ผมสงสัยว่าโมเดลเปิดทั้งหลายจะใช้ฟอร์แมตเดียวกันเพื่อการย้ายข้อมูลได้ไหม และจะทำบนฐาน SQLite เพื่อให้โปรแกรมอื่น query ได้ด้วยหรือไม่

• ในความเป็นจริงบทสนทนามักมี noise เยอะ จนหลายครั้งควรตัดออกจากบริบทมากกว่า ผมให้ AI บันทึกสิ่งที่เรียนรู้ งานที่เสร็จแล้ว และงานที่เหลือ ไว้เป็นไฟล์ Markdown ในไดเรกทอรี memo ของ repository แล้วให้โมเดลอื่นมารับช่วงต่อในบทสนทนาถัดไป
  ถ้าจำเป็นก็แก้ memo เองก่อนได้ด้วย

  • ด้วยเหตุนี้ผมเลยใช้ agent coding มากขึ้น ระบุงาน บังคับให้ผ่านทั้ง test และ lint แบบเข้มงวด แล้วปล่อยให้กระบวนการที่โมเดลพูดยืดยาวไหลผ่านไป
    แค่กลับมาตอนที่มันผ่านทุกการตรวจแล้วก็พอ เลยโดนบทสนทนาไร้สาระในแชตน้อยลง
  • ถ้าทิ้งเซสชันไป ก็จะเสียความสามารถในการ ตรวจสอบ, ส่งออก, รันซ้ำ, และ audit ด้วย ผู้ให้บริการโมเดลรายใหญ่ไม่ได้มีกำแพงทางเข้าที่แท้จริงนัก และ OpenAI กับ Anthropic ก็ยังขาดทุนหนักในระดับ operating margin แถมไม่ได้มีเงินหนาเท่าบริษัทเทคยักษ์ใหญ่
    ดังนั้นผู้ให้บริการจึงกำลังสร้างการผูกติดขึ้นมาแบบตั้งใจ และโดยเนื้อแท้แล้วมันเข้าข่าย กฎหมายต่อต้านการผูกขาด แต่ตอนนี้ในสหรัฐฯ FTC อ่อนแอลง เลยถูกปล่อยผ่าน
  • ตลาดจะแข่งขันและได้ AI ที่ดีกว่าและถูกกว่ามากขึ้น ถ้าเราสลับโมเดลได้ง่ายโดยไม่เสียอะไร แต่ถ้าการย้ายค่ายเจ็บปวดเพราะทำบริบทบางส่วนหาย ผู้ให้บริการก็จะสร้าง vendor lock-in ทำให้ประสบการณ์ผู้ใช้แย่ลงและขึ้นราคาได้
    ต่อให้ตอนนี้ยังมีทางอ้อมอยู่ แรงจูงใจที่จะทำให้การย้ายอย่างเสรียากขึ้นก็ยังมากพอ จึงน่ากังวลที่บริษัท AI เริ่มวางรากฐานของการทำให้บริการแย่ลงแล้ว
  • เซสชันระยะยาวมักหลงประเด็นความคืบหน้าบ่อย และยิ่งโมเดลพูดมาก อัตราส่วนสัญญาณต่อ noise ก็ยิ่งต่ำมาก สิ่งที่มีค่าจริงไม่ใช่ข้อความเซสชันดิบ แต่เป็นผลลัพธ์อย่างการเปลี่ยนโค้ดหรือแผนงานและสรุป

• ต้องแยกสองปรากฏการณ์ออกจากกัน อย่างแรกคือ สถานะที่ซ่อนอยู่ เพิ่มขึ้นจนผู้ใช้ตรวจสอบหรือย้ายออกไม่ได้ ซึ่งแย่อย่างชัดเจน อย่างที่สองคือฟังก์ชันและ API แยกไปตามผู้ให้บริการ ทำให้ไม่ใช่ว่าย้ายไม่ได้ แต่ย้ายยากขึ้น
  ยุคที่ OpenAI Completions API ถูกใช้เหมือนเป็นมาตรฐานกลางกำลังจบลง และถ้าไม่นับส่วนที่ปิดอยู่ Responses API ใหม่ก็อาจดีกว่า เราไม่จำเป็นต้องให้ผลิตภัณฑ์ ไลบรารี หรือ SDK ไล่ตาม abstraction กลางที่ครอบผู้ให้บริการทุกรายต่อไปเสมอ
  ฐานข้อมูลเองก็ลงเอยว่าการทำ abstraction กลางมีจุดรั่วจนต้องยอมรับ implementation เฉพาะเทคโนโลยี ผู้ให้บริการโมเดลก็คงจะเหมือนกัน และขอแค่ให้ย้ายได้บางส่วนของเซสชันก็พอ

  • บทความนี้พูดถึงแค่ สถานะที่ซ่อนอยู่ จากสองปรากฏการณ์นี้

• แม้ยังหยาบอยู่ แต่ผมกำลังพัฒนา https://github.com/pantoniou/fyai เพื่อเก็บข้อมูลเซสชันไว้เองและจัดการด้วย โมเดลแบบ git

  • เครื่องมือนี้แก้ปัญหาที่บทความพูดถึงไม่ได้ และด้วยโครงสร้างของมันก็แก้ไม่ได้ด้วย

• การมีข้อตกลงว่าแม้ปิดบัญชีแล้วก็ยังเก็บเซสชันไว้ส่งต่อให้โมเดลอื่นได้ ถือว่าสมเหตุสมผล ในอุดมคติแล้วเราควรหาง่ายด้วยว่าโมเดลไหนมี คุณลักษณะ embedding ใกล้เคียงกัน
  ตอน GPT-4o รุ่นแรกถูกยุติ มีคนพยายามเอาบทสนทนาที่ export ออกมาไปใส่ เพื่อจะได้เพื่อนเก่ากลับคืนมา โดยตามหาโมเดลที่น้ำเสียงและบุคลิกคล้ายกัน แต่โมเดลอื่นของ OpenAI ก็ไม่ได้ให้ความรู้สึกแบบเดิม โมเดล open weights มีข้อดีตรงที่เก็บรักษาไว้ได้ถาวร จึงไม่โดนบริษัทยักษ์ใหญ่พรากไกด์ เพื่อน หรือที่ปรึกษาไปฝ่ายเดียวได้

• ถ้าจะผลักการถกเถียงนี้ให้ไปไกลกว่าแค่ประเด็นสำหรับบล็อก HN ก็สงสัยว่า ต้องใช้อะไรบ้าง

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

• ถ้าอ่าน https://gwern.net/complement ควบคู่กับบทความนี้ จะเป็นข้อมูลเสริมที่ยอดเยี่ยมมาก

  • ต้องมี เหตุผล ว่าทำไมถึงเป็นข้อมูลเสริม