ถอดรหัส "Session" AI: ทำไมเราถึง "ย้าย" บทสนทนาไม่ได้เหมือนเดิม?

ถอดรหัส "Session" AI: ทำไมเราถึง "ย้าย" บทสนทนาไม่ได้เหมือนเดิม?เคยไหมที่คุยกับ AI แล้วรู้สึกว่าข้อมูลที่ได้มาเหมือนจะ "ติดแหง็ก" อยู่กับผู้ให้บริการนั้นๆ โดยเฉพาะเมื่อเราต้องการนำบทสนทนาไปใช้ต่อกับ AI ตัวอื่น หรือแม้แต่จะเก็บรักษาไว้เอง? บทความนี้จะพาไปสำรวจปรากฏการณ์ที่เรียกว่า "Session Lock-in" ในโลกของ AI และทำความเข้าใจว่าทำไม "Session" ที่เราเคยคิดว่าจับต้องได้ กลับกลายเป็นสิ่งที่เรา "ย้าย" ไปไหนไม่ได้เหมือนเดิมสัญญาเดิมของ API: ง่ายแค่ส่ง Input ได้ Outputในยุคแรกเริ่มของ Inference API สัญญาที่ให้กับผู้ใช้งานนั้นเรียบง่าย: ป้อนข้อมูล (Input) เข้าไป แล้วรับผลลัพธ์ (Output) ออกมา หากคุณเก็บทั้งสองส่วนไว้ คุณก็จะมี "บทสนทนา" ทั้งหมด สามารถตรวจสอบ, เก็บถาวร, เล่นซ้ำ หรือแม้แต่นำไปให้โมเดลอื่นใช้งานต่อได้แม้ในความเป็นจริงจะมีปัจจัยอื่น ๆ เช่น Prompt Caches ที่อยู่บนเซิร์ฟเวอร์ของผู้ให้บริการ, ความแตกต่างของการ Tokenization ในแต่ละโมเดล, หรือการสุ่ม Sampling ที่ไม่สามารถทำซ้ำได้ (ซึ่งก็ตั้งใจให้เป็นเช่นนั้น) แต่ "บันทึกเชิงความหมาย" ของบทสนทนาในรูปแบบของ Transcript (ข้อความ) ก็ยังถือเป็นของผู้ใช้ ผู้ใช้สามารถตรวจสอบได้ว่ามีคำสั่งอะไรบ้าง, ข้อความอะไร, การเรียกใช้ Tool อะไร และผลลัพธ์จาก Tool เป็นอย่างไร หากนำไปให้โมเดลอื่นที่ความสามารถใกล้เคียงกัน ก็อาจจะสามารถสานต่อบทสนทนาได้อย่างเข้าใจเมื่อ API เริ่ม "ไม่เหมือนเดิม": สู่ยุคของ "Provider-Bound State"แต่ปัจจุบัน Inference API หลายแห่งกำลังเคลื่อนตัวออกห่างจากคุณสมบัตินี้ โดยการส่งคืนข้อมูลที่ผสมผสานระหว่างข้อความและ "สถานะที่ผูกติดกับผู้ให้บริการ" (Provider-bound state) ซึ่งถูกออกแบบมาให้ไม่สามารถนำไปใช้ที่อื่นได้โดยเจตนา คุณสมบัติเหล่านี้รวมถึง:Reasoning Tokens ที่ถูกคิดค่าบริการ: แต่กลับคืนมาในรูปของ "ข้อมูลเข้ารหัสทึบ" (Opaque, encrypted blobs) พร้อมสรุปที่อาจไม่สมบูรณ์การค้นหาบนเว็บ (Web Searches): ที่โมเดลสามารถมองเห็นข้อมูลต้นทางได้ แต่ลูกค้า (ผู้ใช้) กลับไม่เคยเห็นContext ที่ถูกบีบอัด: ซึ่งมีเพียงผู้ให้บริการเดิมเท่านั้นที่สามารถถอดรหัสได้คำสั่งและข้อความของ Sub-agent: ที่ถูกซ่อนไว้ในรูปแบบของ "Payload ที่เข้ารหัส" (Encrypted payloads) ทำให้แอปพลิเคชันไม่สามารถมองเห็นได้การอ้างอิง File, Vector-store, Container, และ Cache: ที่ไม่สามารถเข้าถึงได้นอกเหนือจากระบบของผู้ให้บริการเดิมสถานะการตอบกลับและบทสนทนา: ที่ถูกกำหนดด้วย ID ที่จัดเก็บอยู่บนเซิร์ฟเวอร์ของผู้ให้บริการทั้งหมดแต่ละคุณสมบัติเหล่านี้มักมาพร้อมกับ "เหตุผลพื้นฐาน" ที่ผู้ให้บริการอ้างว่าดีต่อผู้ใช้ แต่เมื่อรวมกันแล้ว กลับเปลี่ยนแปลง "ความเป็นเจ้าของ" ของ Session AI อย่างสิ้นเชิง Transcript ที่อยู่บนเครื่องของคุณ อาจไม่ใช่ Session ของคุณอีกต่อไป แต่เป็นเพียง "ส่วนหนึ่ง" ของ Session ที่สถานะการทำงานทั้งหมดเป็นของผู้ให้บริการ ไม่ใช่คุณการทดสอบ "ความเป็นเจ้าของ Session" แบบปฏิบัติได้จริงเมื่อเราพูดถึง "Portable Session" เราไม่ได้หมายความว่าการสลับไปใช้โมเดลอื่นจะต้องได้ผลลัพธ์ถัดไปเหมือนกันเป๊ะ ๆ เพราะแต่ละโมเดลมีความสามารถ, บุคลิก, Context Window, และวิธีการทำงานกับ Tool ที่แตกต่างกัน และโดยธรรมชาติแล้วกระบวนการต่าง ๆ ก็มีความไม่แน่นอนอยู่แล้วแต่ "Portability" ในที่นี้หมายถึง:"Archive ของบทสนทนาต้องมีข้อมูลที่เพียงพอและเข้าใจได้ เพื่อให้โมเดลอื่นสามารถสานต่อการทำงานได้ โดยไม่จำเป็นต้องให้ผู้ให้บริการเดิมมาถอดรหัสข้อมูล, จำผลการค้นหา, หรือสร้างสรุปขึ้นมาใหม่"สิ่งนี้ทำให้เราสามารถตั้ง "5 การทดสอบ" ที่มีประโยชน์ เพื่อตรวจสอบความเป็นเจ้าของ Session:การตรวจสอบ (Inspection): ผู้ใช้สามารถมองเห็นสิ่งที่โมเดลเห็น, สิ่งที่ Tool ทำ, และสิ่งที่ Agent สื่อสารกันได้หรือไม่?การส่งออก (Export): Session สามารถ "พกพา" ไปได้หรือไม่, โดยยกเว้นเพียงสิ่งที่เป็น Artifact ทั่วไปที่สามารถดาวน์โหลดได้?การเล่นซ้ำ (Replay): การนำ Session ไปให้ระบบอื่น สามารถสร้าง Context ที่มีความหมายเทียบเท่าได้หรือไม่?การตรวจสอบ (Audit): มนุษย์สามารถอธิบายได้หรือไม่ว่าทำไมระบบจึงดำเนินการเช่นนั้นหลังจากเหตุการณ์นั้น ๆ?การลบ (Deletion): ผู้ใช้สามารถระบุและลบสำเนาทุกอย่างบนเซิร์ฟเวอร์ที่ Session นั้นพึ่งพาอยู่ได้หรือไม่?การมีเพียง Response ID ไม่ใช่ Transcript, ข้อมูลที่เข้ารหัสไม่ใช่สิ่งที่ผู้ใช้ควบคุมได้, และรายการอ้างอิงก็ไม่ใช่หลักฐานทั้งหมดที่โมเดลใช้ในการค้นหาการเข้ารหัส: เพื่อใครกันแน่?การตั้งชื่อและการตลาดเกี่ยวกับคุณสมบัติต่าง ๆ อาจทำให้เข้าใจผิดได้ เช่น encrypted_content ฟังดูเหมือนเป็นฟีเจอร์ด้านความเป็นส่วนตัวที่ผู้ใช้ควบคุม แต่โดยทั่วไปแล้วมันคือ "แคปซูล" ที่ไคลเอนต์อ่านไม่ได้ และมีเพียงผู้ให้บริการเท่านั้นที่เปิดได้ ผู้ให้บริการเป็นผู้เลือก Key, ถอดรหัสเนื้อหาสำหรับโมเดลของตนเอง, และกำหนดว่าจะนำข้อมูลไปใช้ซ้ำที่ไหนได้บ้างคำที่เหมาะสมกว่าอาจเรียกว่า "Provider-Sealed State" (สถานะที่ปิดผนึกโดยผู้ให้บริการ)Provider sealing สามารถให้ประโยชน์ด้านความเป็นส่วนตัวได้จริง เช่น OpenAI สามารถส่งคืน Reasoning ที่เข้ารหัสไปยังไคลเอนต์โดยใช้ store: false แล้วถอดรหัสในหน่วยความจำในการร้องขอครั้งถัดไป โดยไม่ต้องเก็บสถานะระหว่างกลางไว้บนเซิร์ฟเวอร์ ซึ่งดีกว่าการบังคับให้เก็บประวัติการสนทนาบนเซิร์ฟเวอร์ แต่ประเด็นสำคัญคือ "แท้จริงแล้วไม่มีอะไรที่จำเป็นต้องเข้ารหัสตั้งแต่แรก!"การเข้ารหัสลักษณะนี้ไม่ได้ซ่อนข้อมูลจากผู้ให้บริการ แต่เป็นการซ่อนจาก "คุณ"การเก็บประวัติการสนทนา: เปลี่ยน Transcript ให้กลายเป็นแค่ "ตัวชี้"API ของ OpenAI เก็บ Response ไว้เป็นค่าเริ่มต้น โดยเอกสารระบุว่า Response Objects จะถูกเก็บไว้อย่างน้อย 30 วัน แต่ก็มีตัวเลือก store: false ซึ่งควรใช้ เพราะจะทำให้ทำงานคล้ายกับ Completions มากขึ้น โดยข้อมูลจะไม่ถูกเก็บไว้บนเซิร์ฟเวอร์ของ OpenAIAPI รุ่นใหม่ของ Gemini ก็มีทางเลือกคล้ายกัน โดย store: true เป็นค่าเริ่มต้น บนแผนบริการแบบชำระเงิน การโต้ตอบจะถูกเก็บไว้ 55 วัน และบนแผนบริการฟรี 1 วันแน่นอนว่า การเก็บสถานะบนเซิร์ฟเวอร์นั้นน่าดึงดูด: แอปพลิเคชันส่งข้อมูลน้อยลง, ผู้ให้บริการสามารถเก็บ Reasoning และสถานะ Tool ที่ซ่อนไว้ได้, และการจัดการ Cache ก็ง่ายขึ้น แต่หากแอปพลิเคชันในเครื่องบันทึกเพียงข้อความของผู้ใช้และข้อความสุดท้าย first.id ก็จะกลายเป็นเพียง "Foreign Key" ที่ชี้ไปยังฐานข้อมูลที่แอปพลิเคชันนั้นควบคุมไม่ได้ไม่มี Reasoning ให้คุณเห็นผู้ให้บริการ AI รายใหญ่ต่างอ้างว่ามีเหตุผลอันชอบธรรมที่จะไม่เปิดเผย "Chain of Thought" หรือกระบวนการคิดดิบ ๆ ทำให้เรามักไม่เห็น Tokens เหล่านี้ในโมเดลที่ไม่ได้เปิดเผย Source CodeReasoning ดิบ ๆ จะไม่สามารถมองเห็นได้ผ่าน API ด้วยการเก็บ Response ไว้ Reasoning ก่อนหน้าสามารถกู้คืนได้ผ่าน previousresponseid หากใช้ store: false API จะคืนค่า encryptedcontent ซึ่งไคลเอนต์ต้องเก็บรักษาและนำไปเล่นซ้ำ การเก็บ Reasoning ไว้ยังคงทึบแสงแม้จะมีการใช้ reasoning.context: "allturns" เพื่อให้ตัวอย่างถัดไปสามารถใช้ประโยชน์จากมันได้Anthropic คืนค่า "Full thinking" ที่เข้ารหัสในช่อง signature ส่วนข้อความที่อ่านได้ (เมื่อเปิดใช้งาน) เป็นเพียงสรุปที่สร้างโดยโมเดลอื่น ไม่ใช่ Chain of Thought ดิบ ๆ และ Thinking Blocks จะต้องถูกส่งกลับไปโดยไม่เปลี่ยนแปลงเมื่อมีการใช้ Tool แต่เอกสารของ Anthropic ยังระบุอีกว่า Thinking Blocks นั้นผูกติดกับโมเดลที่สร้างมันขึ้นมา และควรถูกลบออกเมื่อเปลี่ยนไปใช้โมเดลอื่น ดังนั้น ร่องรอย Reasoning เหล่านี้จึงไม่พยายามที่จะ "พกพา" ไปใช้ภายใน Anthropic เองเรื่องราวเดียวกันนี้เกิดขึ้นกับโมเดลที่ปิด Source Code ทั้งหมดกลไกการเข้ารหัสเหล่านี้ช่วยให้เกิดความต่อเนื่องภายในระบบนิเวศของผู้ให้บริการ แต่ไม่ได้สร้าง Transcript ที่สามารถ "พกพา" ไปยังโมเดลของผู้ให้บริการรายอื่นได้ Archive ของ Session อาจมี Blobs ที่เข้ารหัสอยู่ แต่โมเดลอื่นไม่สามารถใช้ "ความหมาย" ของมันได้การค้นหาบนเว็บที่ถูกโฮสต์: ช่องโหว่ใน Transcript ที่ผู้ใช้มองไม่เห็นการค้นหาบนเว็บที่ดำเนินการโดยเซิร์ฟเวอร์ (Server-side web search) เป็นหนึ่งในตัวอย่างที่ชัดเจนที่สุดของ Transcript ที่มี "รูโหว่" ที่ซ่อนจากผู้ใช้ เครื่องมือค้นหาฝั่งไคลเอนต์ (Client-side search tool) ทำงานเหมือน Tool อื่น ๆ: ผู้ใช้สามารถตรวจสอบการจัดอันดับและเนื้อหา, ดึงหน้าเว็บซ้ำ, เก็บสำเนาของ Cache, หรือให้หลักฐานเดียวกันกับโมเดลอื่นได้แต่เมื่อเป็นการค้นหาที่โฮสต์ (Hosted search) ผู้ให้บริการจะดำเนินการ Loop ของ Tool แบบส่วนตัว OpenAI, Google, และ Anthropic แสดงการกระทำจากการค้นหา, การอ้างอิง, และอาจมีรายการ URL ต้นทาง แต่ "ไม่ใช่" บริบทข้อความทั้งหมดที่ใช้ในการสร้างคำตอบ URL ไม่ใช่การเล่นซ้ำที่เสถียร เนื้อหาอาจเปลี่ยนแปลง หรือถูกลดทอนให้สั้นลงก่อนที่โมเดลจะเห็นคำตอบสุดท้ายอาจจะดี แต่ปัญหาจะปรากฏใน Turn ถัดไป: เมื่อคุณต้องการให้โมเดลใหม่ "เปรียบเทียบข้อมูลจากแหล่งที่สามกับแหล่งแรก, ตรวจสอบตัวเลขที่ยังเป็นที่ถกเถียง, และดำเนินการวิจัยต่อโดยใช้โมเดลอื่น" โมเดลใหม่จะได้รับเพียงคำตอบและ URL ไม่ได้รับผลการจัดอันดับ, เนื้อหาที่ดึงมา, ข้อมูลที่ถูกกรองออก, หรือหลักฐานที่โมเดลแรกใช้ ผู้ให้บริการเดิมยังคงเป็นส่วนหนึ่งของ Session แม้ว่าคำขอถัดไปจะส่งไปยังที่อื่นก็ตาม แม้คุณจะมีรายการอ้างอิงและลองดึงข้อมูลซ้ำ คุณก็ไม่สามารถสร้างข้อมูลที่ "เหมือนเป๊ะ" ได้Hosted search ควรมีโหมดการส่งออกแบบ "Full-fidelity" ที่มีทั้ง Query, Metadata ของผลลัพธ์, เนื้อหาที่ดึงมา, Timestamp, และเนื้อหาที่เก็บรักษาไว้ การอ้างอิงแบบกระชับสามารถคงไว้เป็น User Interface ได้ แต่ไม่ควรเป็นเพียงบันทึกเดียวการบีบอัด Context: ความทึบแสงที่เพิ่มขึ้นSession ของ Agent ที่ยาวนานมักต้องการการบีบอัด การสรุปที่ผู้ใช้มองเห็นและควบคุมได้นั้นอาจมีการสูญเสียข้อมูล แต่ก็อย่างน้อยก็สามารถตรวจสอบและถ่ายโอนได้ ผู้ใช้สามารถทบทวน, แก้ไข, หรือขอให้โมเดลอื่นสร้างการสรุปขึ้นมาใหม่แต่การบีบอัดแบบ Server-side ของ OpenAI กลับส่งคืน "รายการบีบอัดที่เข้ารหัส" (Encrypted compaction item) เอกสารอธิบายว่าเป็น "ข้อมูลทึบแสงและไม่ได้มีไว้สำหรับการตีความโดยมนุษย์" Endpoint /responses/compact แบบ Standalone จะคืนค่า "Canonical next context window" ที่ไคลเอนต์ได้รับคำสั่งให้ส่งต่อไปตามนั้นในเชิงแนวคิด การเปลี่ยนผ่านจะเป็นเช่นนี้: OpenAI สามารถทำงานต่อจากความหมายที่ถูกบีบอัดได้ แต่ผู้ให้บริการรายอื่นจะเห็นเพียง "สตริงที่อ่านไม่ออก" บวกกับส่วนท้ายล่าสุด (ซึ่งเราไม่เคยส่งข้อมูลประเภทนี้ไปยังผู้ให้บริการรายอื่น)นี่ไม่ใช่สิ่งจำเป็นทางเทคนิคเสมอไป การบีบอัดแบบ Server-side ของ Anthropic คืนค่า "Compaction block" ที่มีฟิลด์ readable content ซึ่งช่วยให้ไคลเอนต์สามารถส่งคำแนะนำการสรุปแบบกำหนดเองได้ และผลสรุปที่ได้ก็สามารถตรวจสอบและส่งต่อไปยังโมเดลอื่นได้ การบีบอัดฝั่งไคลเอนต์ก็เป็นไปได้กับผู้ให้บริการทุกรายArtifact ที่ปิดผนึกของ OpenAI อาจเก็บรักษา "สถานะเฉพาะของโมเดล" ได้มากกว่าการสรุปธรรมดา และอาจทำงานได้ดีกว่าบนโมเดลเดิม ซึ่งเป็น Optimization ที่สมเหตุสมผล แต่ควรมาพร้อมกับการสรุปที่อ่านได้ ไม่ใช่การแทนที่ แต่ก็นั่นแหละ ประโยชน์เพิ่มเติมคือการ "ล็อก" คุณเข้ากับระบบนิเวศของผู้ให้บริการรายเดียวSub-agents: มาพร้อมคำสั่งที่ซ่อนเร้นระบบ Multi-agent ยิ่งทำให้ปัญหารุนแรงขึ้น เพราะไม่มี Transcript เดียวอีกต่อไป แต่เป็น "โครงสร้างแบบต้นไม้" ของ Session และกระแสข้อความระหว่าง Agenthttps://earendil.com/posts/session-portability/