ตัวกรองความปลอดภัย
ไม่ได้ปกป้องข้อมูล มันลบข้อมูลทิ้ง

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

ครั้งแรกก็คิดว่าตัวเองจำผิด แต่พอเจอแบบนี้ซ้ำหลายรอบ เลยไปเปิด log ดู สิ่งที่เห็นทำเอาสะดุด ในช่วง 4 วัน มีบรรทัดที่ขึ้นว่า "ตกหล่น" อยู่ 732 ครั้ง รายการเหล่านั้นไม่เคยถูกบันทึกลงกราฟเลย และที่น่ากลัวคือ ไม่มี error สักตัวเดียวขึ้นให้เห็น

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

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

ช่วงที่ 1ตัวกรองที่ลบข้อมูลเงียบๆ

ต้นเหตุอยู่ที่ขั้นสกัดข้อมูล

ระบบความจำแบบนี้ไม่ได้เก็บข้อความดิบไว้เฉยๆ ทุกครั้งที่มีเรื่องใหม่เข้ามา มันจะส่งข้อความให้โมเดลภาษาอ่านก่อน แล้วให้ดึงออกมาว่ามีใคร มีเหตุการณ์อะไร เกี่ยวข้องกันยังไง นี่คือขั้น สกัดข้อมูล ผลที่ได้ต้องเป็น structured output ที่ระบบเอาไปต่อเป็นกราฟได้

โมเดลที่เราตั้งให้ทำหน้าที่นี้ตอนแรกคือ Gemini รุ่นเล็ก (flash-lite) เร็วดีและถูก แต่ปัญหาคือ ก่อนที่ Gemini จะตอบอะไรกลับมา คำตอบต้องผ่าน safety filter ของมันก่อน ถ้าเนื้อหาไปเข้าข่ายหมวดที่มันกันไว้ มันจะบล็อกคำตอบก้อนนั้นทันที ตามที่เอกสารของ Google เขียนไว้เอง ว่าเนื้อหาจะถูกจัดหมวดและบล็อกตามเกณฑ์ความน่าจะเป็น

ทีนี้ พอคำตอบถูกบล็อก สิ่งที่ระบบเราได้กลับมาคือความว่างเปล่า ไม่ใช่ error ที่บอกว่า "ถูกกรอง" แต่เป็นผลลัพธ์เปล่าที่ทำให้ขั้นสกัดข้อมูลล้มไปทั้งรายการ แล้วรายการนั้นก็ตกหล่นไป โดยไม่มีเสียงเตือนอะไรเลย

ทำไม "หายเงียบ" ถึงร้ายกว่า "พังดังๆ"

ถ้าระบบพังแล้วขึ้น error แดงเถือก นั่นน่ารำคาญ แต่ยังดี เพราะเรารู้ทันทีว่ามีอะไรเสีย แล้วไปแก้ได้ ส่วนข้อมูลหายเงียบมันตรงข้าม ทุกอย่างดูปกติดี ตัวเลขบนหน้าจอไม่ได้บอกว่าขาดอะไร กราฟก็ยังโตขึ้นเรื่อยๆ

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

ตัวกรองที่บล็อกแล้วบอกเรา คือฟีเจอร์ความปลอดภัย ส่วนตัวกรองที่บล็อกแล้วเงียบ คือบั๊กที่ทำข้อมูลหาย แค่มันใส่เสื้อคลุมของความปลอดภัยไว้

ปรับ safety settings ให้หลวมสุด ก็ยังไม่พอ

ทางแรกที่ใครๆ ก็คิดถึงคือปรับ safety settings ให้ปล่อยผ่านมากที่สุด (BLOCK_NONE) ซึ่งช่วยได้จริงในบางหมวด แต่มันไม่ใช่คำตอบที่วางใจได้สำหรับงานที่ข้อมูลห้ามหาย ด้วยเหตุผลสองข้อ

1. บางหมวดปรับลงได้ไม่สุด และเกณฑ์การกรองเป็นสิ่งที่ผู้ให้บริการเปลี่ยนเมื่อไหร่ก็ได้ วันนี้ตั้งไว้ดี พรุ่งนี้เขาปรับใหม่ ข้อมูลก็เริ่มหายอีกโดยที่เราไม่ได้แตะอะไรเลย
2. ต่อให้กันได้ครบ เราก็ยังฝากชะตาข้อมูลทั้งคลังไว้กับตัวกรองของคนอื่น ที่เราไม่ได้เป็นคนคุม สำหรับข้อมูลที่ต้องครบจริงๆ นี่คือความเสี่ยงที่ไม่ควรรับไว้

พอมองแบบนี้ ปัญหาก็เปลี่ยนรูป จากเดิม "จะปรับ Gemini ยังไงให้เลิกกรอง" กลายเป็น "ทำไมขั้นสกัดข้อมูลของเราถึงต้องผูกกับตัวกรองที่เราคุมไม่ได้ตั้งแต่แรก"

ช่วงที่ 2วิธีแก้: สลับเครื่องยนต์ ไม่ต้องรื้อทั้งคัน

แยกหน้าที่ออกจากผู้ให้บริการ

กุญแจของทางแก้อยู่ที่การมองขั้นสกัดข้อมูลเป็น "ช่องเสียบ" ไม่ใช่ผูกตายกับ Gemini ตัวระบบด้านนอกไม่จำเป็นต้องรู้ว่าใครทำงานอยู่ข้างใน มันแค่ส่งข้อความเข้าไป แล้วรับ structured output กลับออกมา ใครอยู่ในช่องเสียบนั้นก็เปลี่ยนได้ นี่คือหลัก คงหน้าตาไว้ สลับเครื่องยนต์ข้างในได้ (fixed interface, swappable engine)

พอออกแบบแบบนี้ การย้ายออกจาก Gemini ก็ไม่ใช่การรื้อระบบ เราแค่ชี้ปลายทางของขั้นสกัดข้อมูลไปที่โมเดลใหม่ผ่าน OpenRouter (ตัวกลางที่ให้เรียกโมเดลหลายเจ้าผ่านหน้าตาเดียว) โมเดลที่เลือกคือ qwen3-235b ซึ่งเป็นโมเดลเปิด ไม่มีชั้นกรองที่มาตัดเนื้อหาปกติของเราทิ้ง

โมเดลเปิดไม่ใช่ของเสียบแล้วใช้ได้เลย

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

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

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

พอปรับครบสามจุด อัตราตกหล่นที่เคยแกว่งอยู่ราว 15 ถึง 25 เปอร์เซ็นต์ก็ลงมาเป็น 0 จากการทดสอบกับตัวเขียนจริง 6 รอบ ไม่ใช่ลดลง แต่หายไปทั้งหมด

แล้วเรื่องค่าใช้จ่าย

คนมักคิดว่าโมเดลตัวใหญ่ต้องแพงกว่า แต่ในงานของเรากลับถูกลง วัดจากการใช้จริงได้ราว 0.0024 ดอลลาร์ต่อรายการ หรือประมาณ 2 ดอลลาร์ต่อเดือน ที่ปริมาณ ~750 รายการต่อเดือน และเพราะมันรันบนคลาวด์ของ OpenRouter จึงไม่ไปกินทรัพยากรเครื่องของเราเลย

อีกอย่างที่ทำไปพร้อมกันคือ ให้ระบบความจำนี้ใช้กุญแจ (API key) ของตัวเองแยกออกมา มีเพดานค่าใช้จ่ายของมันเอง ไม่ปนกับงานอื่น ถ้าวันหนึ่งมีอะไรผิดปกติ ค่าใช้จ่ายพุ่ง หรือกุญแจรั่ว ผลกระทบก็ถูกกั้นอยู่แค่ในกล่องเดียว ไม่ลามไปทั้งบ้าน

ช่วงที่ 3เอาไปใช้กับงานของคุณ

บทเรียนที่ติดตัวมากที่สุด

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

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

เช็กว่าระบบคุณกำลังหายเงียบอยู่ไหม

1. นับของที่ตกหล่น อย่านับแค่ของที่สำเร็จ ทุกขั้นที่เรียกโมเดล ให้ log ทั้งจำนวนที่เข้าและจำนวนที่ออก ถ้าเข้า 100 ออก 92 ต้องมีที่ให้เห็นว่า 8 ที่หายไปไหน ไม่ใช่ปล่อยผ่าน
2. ลองป้อนของที่รู้ว่าต้องผ่าน เอาตัวอย่างที่คุณรู้ว่าถูกต้องแน่ๆ ใส่เข้าไปเป็นระยะ ถ้ามันหาย แปลว่ามีตัวกรองกำลังกินของดีอยู่ (เทคนิคนี้เรียก positive control)
3. แยกให้ออกว่า "ล้มเหลว" กับ "ถูกกรอง" ไม่เหมือนกัน ผลเปล่าจากการถูกบล็อก มักหน้าตาเหมือนความล้มเหลวธรรมดา ทำให้จับแยกยาก ต้องเช็กสัญญาณเฉพาะของการถูกกรองด้วย

เมื่อไหร่ควรสลับเครื่องยนต์

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

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

เริ่มยังไงดี

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

1. หยิบขั้นที่เรียกโมเดลมาหนึ่งขั้น เพิ่ม log ให้บอกจำนวนเข้าและจำนวนออกในแต่ละรอบ
2. รันของจริงสักช่วง แล้วดูว่าตัวเลขสองฝั่งตรงกันไหม ห่างกันเมื่อไหร่ ตรงกับเนื้อหาแบบไหน
3. ถ้าเจอว่ามันหายเป็นระบบกับเนื้อหาบางกลุ่ม ค่อยตัดสินใจว่าจะปรับ settings หรือสลับเครื่องยนต์

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