Journal ความแน่ใจของความจำ

ความแน่ใจคือสิ่งที่ทำให้มันเป็นความจำ

ความจำของระบบ AI ไม่ใช่ข้อเท็จจริงถาวร แต่คือความน่าจะจริงที่จางลงตามเวลา — หลักการข้อเดียวนี้ครอบทั้ง 'ระบบจำถูกไหม' และ 'ระบบลืมจริงไหม' · อธิบายผ่านงานวิจัยใหม่ของ Google Research เรื่องการตรวจสอบ machine unlearning และจบที่คำถามเชิงสถาปัตยกรรมที่ทุกทีม AI ต้องตอบ: ความรู้ในระบบของคุณอยู่ที่ไหน และต้นทุนของการพิสูจน์ว่ามันถูกลบ อยู่ที่เท่าไหร่

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

แต่ลองดูเหตุการณ์นี้: ระบบ AI ตัวหนึ่งจำว่า “ร้านปิดวันจันทร์” เพราะเจ้าของร้านเคยบอกไว้ สามเดือนต่อมาเจ้าของเปลี่ยนวันหยุดเป็นวันอังคาร — และลืมบอกระบบ

ความจำชิ้นนั้นกลายเป็นเท็จ โดยไม่มี byte ไหนในระบบเปลี่ยนเลย

ไม่มี error ไม่มี log ไม่มีสัญญาณเตือนใด ๆ ระบบยังคงตอบลูกค้าด้วยความมั่นใจเท่าเดิมทุกประการ — บนข้อมูลที่ไม่จริงแล้ว

ความจำคือคำกล่าวอ้าง ไม่ใช่ข้อเท็จจริง

เหตุการณ์ข้างบนไม่ใช่บั๊ก และไม่มีทางแก้ให้หายขาด เพราะมันคือธรรมชาติของความจำทุกชนิด

ความจำทุกชิ้นคือคำกล่าวอ้างเกี่ยวกับโลก ณ ตอนที่จด คำกล่าวอ้างตรงกับโลก แต่โลกขยับต่อของมันเองโดยไม่แจ้งเตือนใคร — ร้านย้ายที่ ราคาเปลี่ยน คนเปลี่ยนใจ — ความจำกับความจริงจึงค่อย ๆ ห่างออกจากกัน และช่องว่างนั้นมองไม่เห็นจากข้างในระบบ

ทางเดียวที่จะรู้ว่าห่างไปแค่ไหน คือกลับไปสังเกตโลกใหม่ ซึ่งก็มีข้อจำกัดของมันเอง: การสังเกตบางแบบเปลี่ยนสิ่งที่วัด — ถามลูกค้าซ้ำ ๆ ว่า “ยังชอบกาแฟร้อนอยู่ไหม” ก็เปลี่ยนพฤติกรรมของลูกค้าคนที่เราพยายามวัดอยู่นั่นเอง

ข้อสรุปจึงเหลือทางเดียว:

ความแน่ใจคือสิ่งที่ทำให้มันเป็นความจำ — ความจำที่เข้าใจถูก คือความน่าจะจริงที่จางลงตามเวลานับจากตอนเห็น ไม่ใช่ข้อเท็จจริงถาวร · ระบบไม่มีวันถือ “ความจริง” ได้ ถือได้แค่ค่าประมาณของความแน่ใจ

เกมวางแผนการรบเข้าใจเรื่องนี้มานานแล้ว — fog of war แบ่งแผนที่เป็นสามสถานะ: ดำ (ไม่เคยเห็น), เทา (เคยเห็น แต่นานแล้ว อาจเปลี่ยนไปแล้ว), สี (กำลังเห็นอยู่ เชื่อได้) ความจำเกือบทั้งหมดของทุกระบบ ที่จริงคือ “เทา”

แต่ระบบ AI ส่วนใหญ่ในวันนี้แสดงความจำทุกชิ้นเป็น “สี” — ของเก่าสามเดือนถูกเสิร์ฟด้วยน้ำเสียงมั่นใจเท่าของที่เพิ่งยืนยันเมื่อเช้า นี่คือบั๊กเชิงความซื่อสัตย์ที่ฝังอยู่ในระบบจำนวนมาก โดยไม่มีใครตั้งใจใส่มันเข้าไป

หลักการเดียวกัน ครอบเรื่อง “การลืม” ด้วย

ถ้าความจำคือคำกล่าวอ้าง การลืมก็คือคำกล่าวอ้างอีกชนิด: “ระบบไม่มีความรู้ชิ้นนี้แล้ว” — และมันตรวจตรง ๆ ไม่ได้เหมือนกัน

เรื่องนี้กำลังกลายเป็นปัญหาใหญ่ระดับอุตสาหกรรม เพราะกฎหมายความเป็นส่วนตัว (GDPR, PDPA) ให้สิทธิ์เจ้าของข้อมูลขอให้ลบ และ “ลบ” รวมถึงความรู้ที่โมเดล AI เคยเรียนจากข้อมูลนั้นด้วย วงการเรียกงานนี้ว่า machine unlearning — ล้อกับ machine learning แต่กลับด้าน

เดือนมิถุนายน 2026 Google Research เผยแพร่ งานวิจัยเรื่องการตรวจสอบ machine unlearning (นำเสนอที่ AISTATS 2026) — เครื่องมือสถิติที่ตรวจว่าโมเดลซึ่งถูกสั่งให้ลืมข้อมูล ลืมจริงหรือเปล่า ที่ต้องตรวจจากภายนอกเพราะไม่มีทางอื่น: ความรู้ของโมเดลละลายอยู่ใน weights นับพันล้านตัว ชี้ไม่ได้ว่าชิ้นไหนคือข้อมูลของใคร วิธีของเขาคือเทียบเชิงพฤติกรรม — โมเดลที่สั่งลืมแล้ว ทำตัวเหมือนโมเดลที่ train ใหม่โดยไม่เคยเห็นข้อมูลนั้นเลย (= ลืมจริง) หรือเหมือนโมเดลเดิมที่ยังจำอยู่ (= แค่แกล้งลืม)

ผลการทดลองสองข้อของงานนี้ คือหลักการข้างบนปรากฏตัวในห้องแล็บ:

เทคนิคลืมยอดนิยมหลายตัว แค่แกล้งลืม — ในการทดลอง (ทีมงานออกตัวว่าใช้ implementation อย่างง่าย) เทคนิคอย่าง fine-tuning และ pruning ให้ผลภายนอกเหมือนลืมแล้ว แต่ความรู้ยังซึมอยู่ข้างในและตรวจเจอได้ · บทเรียน: คำสั่งทำงานจบ ≠ ผลลัพธ์เกิดจริง — “รันคำสั่งลืมเสร็จ” กับ “การลืมเกิดขึ้นจริง” เป็นคนละเหตุการณ์ ต้องวัดแยกกันเสมอ

เครื่องวัดรุ่นก่อนหน้าก็ผิดเอง เพราะตั้งเกณฑ์ผิด — การทดสอบแบบเดิมคาดหวังให้โมเดลที่ลืมจริง “แยกไม่ออก” จากโมเดลที่ train ใหม่ แล้ว flag โมเดลที่ลืมถูกต้องว่าสอบตก เพราะแม้ train สองรอบจากข้อมูลเดียวกันเป๊ะ ผลยังต่างกันเล็กน้อยตามธรรมชาติ · บทเรียน: เกณฑ์ที่ใช้งานได้จริงคือ “ใกล้พอ” ไม่ใช่ “เหมือนเป๊ะ” — ความสมบูรณ์แบบไม่ใช่มาตรวัดของระบบที่ทำงานกับโลกจริง

และจุดที่ Google เน้นที่สุดไม่ใช่ความแม่น แต่คือต้นทุน: เครื่องมือรุ่นก่อนต้องใช้ตัวอย่างทดสอบหลักล้าน ตัวใหม่ใช้หลักพัน — ถูกลงราวพันเท่า อ่านระหว่างบรรทัดได้ว่า การพิสูจน์สถานะความจำของ AI กำลังกลายเป็นต้นทุนมาตรฐานที่ทุกระบบต้องจ่าย และวันนี้มันยังแพงจนต้องมีงานวิจัยมาช่วยลดราคา

ราคาของการตรวจ ถูกกำหนดตั้งแต่ตอนออกแบบ

ถ้าการตรวจสถานะความจำมีราคา คำถามถัดมาคือ ราคานั้นถูกกำหนดตอนไหน — คำตอบ: ตั้งแต่ตอนเลือกว่าความรู้จะอยู่ที่ไหน ภาพเทียบที่ผมใช้คือ แกง กับ ตู้เอกสาร

ความรู้ใน weights = แกงที่เคี่ยวแล้ว ทุกอย่างละลายรวมเป็นเนื้อเดียว สั่งให้ “ถอนกระเทียมออกจากแกง” ทำไม่ได้ตรง ๆ ได้แต่พยายามกลบรส แล้วจ้างนักชิมมาตรวจว่ารสยังติดอยู่ไหม — เครื่องตรวจของ Google คือนักชิมราคาแพง ที่กำลังถูกทำให้ถูกลง

ความรู้ใน data ที่มีทะเบียน = ตู้เอกสาร ความรู้เป็นชิ้น แยกจากกัน และชิ้นที่ถูกแปรรูปต่อ (จากข้อมูลดิบไปเป็น pattern หรือ summary) มีป้ายบอกที่มา — ศัพท์ทางระบบเรียกว่า provenance — การลบคือดึงแฟ้มออกแล้วไล่ตามป้ายไปถอนของที่กลั่นจากมัน ส่วนการตรวจว่าลบครบ เหลือแค่ query เดียว: มีความรู้ชิ้นไหนที่ป้ายชี้ไปหาของที่ลบแล้ว แต่ตัวเองยังอยู่ไหม

ทางแยกนี้ไม่ใช่เรื่องไกลตัว — มันคือการตัดสินใจที่ทีม AI ทุกทีมเจออยู่แล้วในรูป fine-tune หรือ RAG: ความรู้ที่ fine-tune เข้าไปคือการเทลงหม้อแกง ความรู้ที่อยู่ใน retrieval layer คือแฟ้มในตู้ ที่ผ่านมาเราชั่งสองทางนี้ด้วย accuracy, latency และค่า train — งานของ Google เพิ่มตัวแปรใหม่เข้ามาในสมการ: ต้นทุนของการพิสูจน์ว่าลบแล้ว ซึ่งสองทางนี้ต่างกันเป็นพันเท่า

สามคำถามสำหรับทบทวนระบบของตัวเอง:

  1. ความรู้ที่มาจากข้อมูลลูกค้า อยู่ที่ไหนบ้าง — ใน weights ที่ fine-tune ไว้? ใน vector store? ใน cache? ชิ้นที่อยู่ใน weights คือชิ้นที่การลบจะแพงที่สุด
  2. ความรู้ที่ถูกแปรรูปต่อ ตามกลับไปหาต้นทางได้ไหม — embedding, summary, pattern ที่กลั่นจากข้อมูลดิบ มีป้ายบอกไหมว่ามาจากข้อมูลชิ้นไหน ถ้าไม่มี ชิ้นนั้นคือกระเทียมในแกง ต่อให้ตัวระบบเป็นตู้เอกสารก็ตาม
  3. ถ้าพรุ่งนี้มีคำขอลบข้อมูลเข้ามา ใช้เวลาเท่าไหร่กว่าจะ “พิสูจน์” ได้ว่าลบครบ — ไม่ใช่ “ลบเสร็จ” แต่ “พิสูจน์ได้” ถ้าคำตอบคือไม่รู้จะพิสูจน์ยังไง นั่นคือหนี้ทางสถาปัตยกรรมที่กฎหมายจะมาทวงเอง

ข้อเตือนสำหรับฝั่งตู้เอกสาร เพื่อไม่ให้อ่านแล้วสบายใจเกินจริง: หนึ่ง — “สั่งลบ ≠ ลบครบ” ใช้กับทุกสถาปัตยกรรม ไม่มีใครได้รับการยกเว้นจากการตรวจ ความต่างคือต้นทุนของการตรวจ ไม่ใช่การไม่ต้องตรวจ และสอง — ทะเบียนมีค่าใช้จ่ายในการถือ ระบบส่วนใหญ่จึงมีนโยบายตัดแต่งประวัติทิ้งตามอายุ ซึ่งตึงกับเรื่องนี้โดยตรง: ถ้าตัดสายโยงทิ้งก่อนจัดการเรื่องลบให้จบ ความสามารถ “ลบแบบพิสูจน์ได้” ก็หายไปด้วย

มองจากที่สูง: คำถามเดียวกันทั้ง stack

ถอยออกมามองภาพรวม จะเห็นว่าเรื่องที่ดูแยกกันสามเรื่อง คือหลักการเดียวกันคนละชั้น:

  • ชั้นผลิตภัณฑ์ — ระบบควรบอกผู้ใช้ได้ว่าความจำชิ้นไหนสด ชิ้นไหนค้าง (fog of war ของความจำ)
  • ชั้นสถาปัตยกรรม — ที่อยู่ของความรู้กำหนดต้นทุนการลบและการพิสูจน์ (แกง หรือ ตู้เอกสาร)
  • ชั้นอุตสาหกรรม — กฎหมายบังคับให้การลืมพิสูจน์ได้ และงานวิจัยกำลังแข่งกันลดราคาเครื่องพิสูจน์

ทั้งสามชั้นตอบคำถามเดียวกัน: ระบบแน่ใจแค่ไหนกับสิ่งที่ตัวเองถืออยู่ — และพิสูจน์ความแน่ใจนั้นด้วยราคาเท่าไหร่

สถานะความจำของระบบ AI ตรวจตรง ๆ ไม่ได้ ทั้งทิศ “ยังจริงไหม” และทิศ “ลืมจริงไหม” — นี่ไม่ใช่ข้อบกพร่องของเทคโนโลยีตัวไหน แต่เป็นธรรมชาติของการเก็บตัวแทนของโลกที่ขยับเองได้ เมื่อหนีไม่พ้น ทางเลือกที่เหลือจึงมีเรื่องเดียว: จะจ่ายค่าตรวจตอนไหน — จ่ายทีหลังด้วยเครื่องมือ audit ราคาแพง หรือจ่ายล่วงหน้าตอนออกแบบ ด้วยการเลือกให้ความรู้เป็นชิ้น มีทะเบียน และตรวจได้ในราคา query เดียว

ประโยคเดียวที่อยากให้ติดกลับไป:

ความแน่ใจคือสิ่งที่ทำให้มันเป็นความจำ — และระบบที่ซื่อสัตย์ คือระบบที่ตอบได้ว่าตัวเองแน่ใจแค่ไหน ทั้งกับสิ่งที่จำ และสิ่งที่ลืม


หลักในบันทึกนี้มาจากการสร้างระบบความจำของ nectarserve และตกผลึกอยู่ใน Continuum — foundation ของระบบ (ความจำเลือนตามเวลา จับได้แค่ความแน่ใจ · คำสั่งจบ ≠ ผลเกิดจริง · ใกล้พอ ไม่ใช่เหมือนเป๊ะ) · ทิศ “การลืมต้องพิสูจน์ได้” ที่เปิดขึ้นระหว่างเขียนบันทึกนี้ กำลังตกผลึกเป็นรอยต่อใหม่ในเอกสารเดียวกัน