ปิดข้อมูลส่วนบุคคลก่อนส่งให้ LLM: redaction กับ tokenization ใช้แทนกันไม่ได้

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

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

เลือกวิธีตามข้อมูลที่งานต้องใช้ต่อ

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

คู่มือ Google Sensitive Data Protection อธิบายการลบ การปิดบัง การแทนค่าที่ตรวจพบด้วยโทเค็น และการแปลงด้วยการเข้ารหัสสำหรับข้อความที่ส่งผ่าน content.deidentify ตัวเลือกเหล่านี้กำหนดวิธีจัดการข้อมูลหลังตรวจพบแล้ว จึงต้องเลือกทั้งสิ่งที่จะตรวจและสิ่งที่จะทำกับข้อมูลแต่ละชนิด

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

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

รักษาบริบทของข้อความโดยไม่เก็บตัวตนจริง

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

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

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

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

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

กำหนดขอบเขตโทเค็นและสิทธิ์คืนค่า

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

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

คู่มือ Presidio Anonymizer แยกตัวดำเนินการ replace, redact, mask, hash และ encrypt พร้อมระบุว่าการถอดกลับใช้กับการแปลงที่ย้อนกลับได้ และการทำ hash ให้ค่าเดิมจับคู่กันข้ามการเรียกใช้ต้องจัดการ salt ให้คงเดิมตามขอบเขตที่ต้องการ การแทนทุกชื่อด้วยป้ายชนิดข้อมูลเดียวกันจึงเก็บได้เพียงข้อเท็จจริงว่าตรงนั้นเคยเป็นชื่อ ไม่ได้เก็บความสัมพันธ์ว่าเป็นคนเดียวกัน

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

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

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

ทดสอบการตรวจจับกับข้อความไทยที่ระบบจะเจอ

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

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

เมื่อรูปแบบที่มีอยู่ไม่ครอบคลุมข้อมูลเฉพาะของงาน คู่มือ custom infoType ของ Google ระบุว่าสามารถเพิ่มตัวตรวจจับด้วยรายการคำหรือรูปแบบ regex ได้ การเพิ่มกฎควรอ้างอิงกรณีที่พบในชุดทดสอบ ไม่ใช่สมมติว่ารูปแบบตัวเลขเดียวครอบคลุมทุกข้อความไทย เพราะข้อมูลอาจถูกพิมพ์ คัดลอก หรือจัดรูปแบบต่างกันก่อนเข้าระบบ

1. กำหนดคำตอบที่คาดหวังให้แต่ละตัวอย่าง ระบุว่าช่วงใดเป็นชื่อ อีเมล หมายเลข หรือรายละเอียดอ่อนไหว และช่วงใดควรอยู่ต่อเพื่อรักษาความหมายของเรื่อง ถ้างานต้องเชื่อมคนเดิม ให้ระบุด้วยว่าข้อความใดควรได้โทเค็นเดียวกัน
2. รันการตรวจจับและแปลงก่อนประกอบพรอมป์ต์ แล้วเทียบข้อความขาออกกับคำตอบที่ทำเครื่องหมายไว้ ข้อมูลที่ควรถูกปิดแต่ยังปรากฏคือ false negative ส่วนข้อความที่ถูกปิดทั้งที่จำเป็นต่อคำตอบคือ false positive ต้องดูทั้งสองแบบ เพราะการปิดได้มากขึ้นแต่ทำลายข้อมูลสำคัญก็อาจทำให้งานใช้ผลไม่ได้
3. ตรวจค่าแทนที่ ไม่ใช่ตรวจเพียงรายงานว่าพบข้อมูล ชื่ออาจหายจากเนื้อความแต่ยังอยู่ในหัวเรื่อง ข้อความอ้างอิง หรือส่วนที่ต่อท้ายจากระบบอื่น โทเค็นของคนเดียวกันอาจเปลี่ยนระหว่างข้อความ หรือคนละคนอาจถูกแทนด้วยป้ายเดียวกันจนความสัมพันธ์ผิด
4. ส่งเฉพาะข้อความที่ผ่านการแปลงแล้วเข้า LLM สำหรับงานตัวอย่าง แล้วดูว่าคำตอบยังแยกผู้เกี่ยวข้อง ลำดับเหตุการณ์ และข้อเท็จจริงที่จำเป็นได้หรือไม่ หากบริบทหาย ให้เพิ่มคำบอกบทบาทหรือโทเค็นตามหน้าที่ของงาน แทนการนำชื่อหรือหมายเลขจริงกลับเข้าไป
5. ทำชุดทดสอบซ้ำเมื่อรูปแบบเอกสาร ช่องทางรับข้อความ ตัวตรวจจับ หรือกฎแปลงเปลี่ยน กรณีที่เคยผ่านอาจกลับมาพลาดได้เมื่อมีช่องข้อมูลใหม่หรือข้อความจากแหล่งใหม่เข้ามารวมในพรอมป์ต์

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

วางจุดแปลงข้อมูลก่อนพรอมป์ต์ถูกประกอบ

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

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

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

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