แนะนำ OpenAI Privacy Filter

 (openai.com)
6 คะแนน โดย GN⁺ 3 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นโมเดล open-weight สำหรับ ตรวจจับและปิดบังข้อมูลระบุตัวบุคคล ในข้อความที่ไม่มีโครงสร้าง และสามารถรันแบบโลคัลเพื่อให้ข้อมูลก่อนการกรองไม่ออกจากอุปกรณ์
  • ออกแบบให้ผสาน การจัดประเภทโทเคนแบบสองทิศทาง กับ span decoding เพื่อทำการติดป้ายกำกับอินพุตทั้งหมดในครั้งเดียว และกู้คืน PII span ได้อย่างรวดเร็วในบริบทที่ยาวสูงสุด 128,000 โทเคน
  • ต่างจากวิธีแบบอิงกฎที่พึ่งรูปแบบของเบอร์โทรหรืออีเมล โดยอาศัย การรับรู้ภาษาและบริบท เพื่อแยกแยะข้อมูลสาธารณะออกจากข้อมูลที่ควรถูกมาสก์ได้ดีกว่า
  • ฝึกด้วยทั้งข้อมูลสาธารณะและข้อมูลสังเคราะห์ ทำคะแนน F1 96% บน PII-Masking-300k และในเวอร์ชันที่ปรับแก้แล้วได้ F1 97.43% อีกทั้งยังทำ domain adaptation จาก 54% ขึ้นเป็น 96% ได้ด้วยข้อมูลเพียงเล็กน้อย
  • ไม่ใช่เครื่องมือทำให้ไม่ระบุตัวตนหรือสิ่งทดแทนการรับรองด้านคอมพลายแอนซ์ และใน งานที่มีความอ่อนไหวสูง การตรวจทานโดยมนุษย์ การประเมินเฉพาะโดเมน และการ fine-tune เพิ่มเติมยังคงสำคัญ

ภาพรวมผลิตภัณฑ์และรูปแบบการเผยแพร่

  • เป็นโมเดล open-weight ที่เชี่ยวชาญด้าน การตรวจจับและปิดบังข้อมูลระบุตัวบุคคล สามารถค้นหา PII ในข้อความแล้วทำการมาสก์หรือลบได้
  • รองรับการ รันแบบโลคัล ทำให้ข้อมูลก่อนการกรองไม่ออกจากอุปกรณ์ และลดความเสี่ยงจากการเปิดเผยเมื่อเทียบกับการส่งไปทำ de-identification บนเซิร์ฟเวอร์
  • ออกแบบมาให้ประมวลผลอินพุตยาว ๆ ได้รวดเร็ว และสามารถตัดสินได้ในครั้งเดียวว่าควรปิดบังหรือไม่
  • นักพัฒนาสามารถนำไปรันในสภาพแวดล้อมของตนเอง และ fine-tune ให้เข้ากับกรณีใช้งานของตน เพื่อเสริมการปกป้องความเป็นส่วนตัวให้แข็งแรงขึ้นใน pipeline ของการฝึก, indexing, logging และการตรวจทาน
  • เปิดเผยบน Hugging Face และ GitHub ภายใต้ สัญญาอนุญาต Apache 2.0 โดยคำนึงถึงทั้งการทดลอง การปรับแต่ง และการนำไปใช้งานเชิงพาณิชย์

ความแตกต่างจากแนวทางเดิม

  • เครื่องมือสำหรับตรวจจับ PII แบบดั้งเดิมมักอาศัย กฎแบบตายตัว กับรูปแบบอย่างเช่นหมายเลขโทรศัพท์หรือที่อยู่อีเมล
  • วิธีแบบนี้อาจทำงานได้ดีในขอบเขตแคบ ๆ แต่พลาดข้อมูลส่วนบุคคลที่ซับซ้อนกว่าได้ง่าย และยังอ่อนเรื่องการจัดการบริบท
  • Privacy Filter ใช้ การรับรู้ภาษาและบริบท ที่ลึกกว่าเพื่อค้นหา PII ได้ครอบคลุมขึ้นในข้อความที่ไม่มีโครงสร้าง
  • ถูกออกแบบมาให้แยกได้ดีขึ้นระหว่างข้อมูลที่ควรเก็บไว้เพราะเป็นข้อมูลสาธารณะ กับข้อมูลที่เชื่อมโยงถึงบุคคลและควรถูกมาสก์หรือลบ
  • พัฒนาขึ้นเพื่อยกระดับมาตรฐานความเป็นส่วนตัวให้เหนือกว่าระดับเดิม และยังใช้เวอร์ชันที่ fine-tune แล้วใน workflow ภายในสำหรับการรักษาความเป็นส่วนตัวด้วย

โครงสร้างโมเดลและขอบเขตการตรวจจับ

  • ใช้สถาปัตยกรรมที่ผสาน โมเดลจัดประเภทโทเคนแบบสองทิศทาง เข้ากับ span decoding
  • เริ่มจากเช็กพอยต์ที่ pretrain แบบ autoregressive แล้วจึงปรับให้เป็นตัวจัดประเภทโทเคนบนระบบป้ายกำกับด้านความเป็นส่วนตัวที่กำหนดไว้ตายตัว
  • แทนที่จะสร้างข้อความทีละโทเคน ระบบจะติดป้ายกำกับลำดับอินพุตทั้งหมดในครั้งเดียว แล้วใช้ กระบวนการ Viterbi แบบมีข้อจำกัด เพื่อกู้คืน span ที่สอดคล้องกัน
  • โครงสร้างนี้ทำให้สามารถติดป้ายกำกับทุกโทเคนได้ด้วย single forward pass ที่มีคุณสมบัติ เร็วและมีประสิทธิภาพสูง
  • สามารถใช้บริบทรอบข้างเพื่อตัดสิน PII span ได้ และโมเดลที่เผยแพร่รองรับบริบทสูงสุด 128,000 โทเคน
  • สามารถปรับจุดสมดุลระหว่าง recall และ precision ให้เหมาะกับสภาพแวดล้อมการใช้งานได้
  • โมเดลที่เปิดเผยมีพารามิเตอร์ทั้งหมด 1.5B พารามิเตอร์ และมี active parameters 50M
  • หมวดการทำนายมี 8 ประเภท ได้แก่ private_person, private_address, private_email, private_phone, private_url, private_date, account_number, secret
  • account_number ใช้สำหรับปิดบังเลขบัญชีหลายประเภท รวมถึงหมายเลขบัตรเครดิตและเลขบัญชีธนาคาร ส่วน secret ครอบคลุมรายการอย่างรหัสผ่านและ API key
  • ป้ายกำกับถูกถอดรหัสเป็น BIOES span tag เพื่อสร้างขอบเขตการมาสก์ที่สะอาดและสม่ำเสมอยิ่งขึ้น

กระบวนการฝึกและผลการประเมิน

  • สร้าง privacy taxonomy ขึ้นมาก่อน เพื่อกำหนดประเภทของ span ที่โมเดลต้องตรวจจับ
    • ครอบคลุมตัวระบุตัวบุคคล ข้อมูลติดต่อ ที่อยู่ วันที่ไม่เปิดเผยต่อสาธารณะ หมายเลขบัญชีหลายประเภทที่รวมข้อมูลเครดิตและธนาคาร ตลอดจน secret อย่าง API key และรหัสผ่าน
  • หลังจากแทนที่ language modeling head ของโมเดลภาษาที่ pretrain ไว้ด้วย token-classification head แล้ว จึงฝึกต่อด้วยเป้าหมายการจัดประเภทแบบมีผู้สอน
  • ฝึกด้วยการผสมข้อมูลสาธารณะและข้อมูลสังเคราะห์ เพื่อให้จับได้ทั้งข้อความสมจริงและรูปแบบความเป็นส่วนตัวที่ซับซ้อน
    • ส่วนที่ป้ายกำกับในข้อมูลสาธารณะยังไม่สมบูรณ์ ถูกเพิ่มความครอบคลุมด้วยการใส่คำอธิบายประกอบที่มีโมเดลช่วยและการตรวจทาน
    • ตัวอย่างสังเคราะห์ถูกใช้เพื่อเพิ่มความหลากหลายในด้านรูปแบบ บริบท และชนิดย่อยของข้อมูลความเป็นส่วนตัว
  • ตอน inference การทำนายระดับโทเคนจะถูกแปลงเป็น span ที่สอดคล้องกันด้วย การถอดรหัสลำดับแบบมีข้อจำกัด
  • มีทั้งการประเมินบน benchmark มาตรฐาน และการประเมินเพิ่มเติมแบบสังเคราะห์/ลักษณะแชตสำหรับกรณีที่ยากและอ่อนไหวต่อบริบทมากกว่า
  • บน PII-Masking-300k ทำคะแนน F1 96%, precision 94.04%, recall 98.04%
  • ในเวอร์ชันที่ปรับแก้โดยสะท้อนปัญหาคำอธิบายประกอบของชุดข้อมูลที่พบระหว่างการตรวจทาน ทำคะแนน F1 97.43%, precision 96.79%, recall 98.08%
  • แม้มีข้อมูลเพียงเล็กน้อยก็ยังทำ domain adaptation ได้รวดเร็ว และบน benchmark การปรับตัวข้ามโดเมนที่ประเมินไว้ คะแนน F1 เพิ่มจาก 54% เป็น 96%
  • Model Card ยังมี stress test สำหรับการตรวจจับ secret ใน codebase และตัวอย่างแบบหลายภาษา แบบ adversarial และแบบพึ่งพาบริบทด้วย

ข้อจำกัดและข้อควรระวังในการใช้งาน

  • ไม่ใช่ เครื่องมือทำให้ไม่ระบุตัวตน ไม่ใช่การรับรองด้านคอมพลายแอนซ์ และไม่ใช่สิ่งทดแทนการทบทวนนโยบายในสภาพแวดล้อมที่มีความเสี่ยงสูง
  • เป็นองค์ประกอบหนึ่งของระบบโดยรวมที่ออกแบบโดยให้ความสำคัญกับความเป็นส่วนตัว
  • ลักษณะการทำงานได้รับอิทธิพลจาก label taxonomy และเส้นแบ่งการตัดสินที่ใช้ในการฝึก
  • แต่ละองค์กรอาจมีนโยบายที่ต้องการในการตรวจจับและมาสก์แตกต่างกัน จึงอาจต้องมีการประเมินในโดเมนจริงหรือ fine-tune เพิ่มเติม
  • ประสิทธิภาพอาจแตกต่างกันไปในภาษา ระบบตัวเขียน กฎการตั้งชื่อ และโดเมนที่ต่างจากการกระจายข้อมูลที่ใช้ฝึก
  • อาจพลาดตัวระบุที่พบไม่บ่อยหรือการอ้างอิงถึงบุคคลที่กำกวม และอาจปิดบังมากเกินไปหรือน้อยเกินไป โดยเฉพาะเมื่อบริบทมีจำกัด เช่น ลำดับข้อความสั้น ๆ
  • ใน งานด้านกฎหมาย การแพทย์ การเงิน และพื้นที่ที่มีความอ่อนไหวสูง การตรวจทานโดยมนุษย์ การประเมินเฉพาะโดเมน และการ fine-tune ยังมีความสำคัญ

เจตนาในการเปิดเผยและทิศทางต่อไป

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 일 전
ความเห็นจาก Hacker News
  • ฟีเจอร์แบบนี้เคยลองทำมาแล้วตั้งแต่ หลายปีก่อน และผลที่ได้ก็ชัดอยู่ไม่กี่อย่าง
    ถ้าจะให้ การลบข้อมูลส่วนบุคคล (PII) ยังรักษา UX ได้ ก็จำเป็นต้องแปลงกลับฝั่งไคลเอนต์ เช่น ถ้าชื่อคือ John แล้วถูกปิดเป็น [NAME] จากนั้นโมเดลตอบว่า Hi [NAME] ก็ต้องคืนกลับเป็น Hi John ก่อนจะแสดงให้ผู้ใช้เห็น
    สุดท้ายจึงต้องมี กลไกแทนค่ากลับ อยู่ในชั้นที่ผู้ใช้โต้ตอบด้วย
    อีกอย่างคือข้อมูล PII ที่ถูกปิดไว้แล้วแทบจะใช้ประโยชน์ไม่ได้ในหลายกรณี โมเดลต้องมีข้อมูลจริงอยู่บ้างถึงจะทำงานได้ แต่รายการที่ถูกจัดเป็น PII มีเยอะมาก จนสำหรับแชตธรรมดาอาจไม่เป็นไร แต่ถ้าผู้ใช้ต้องโต้ตอบกับ LLM แบบซับซ้อน ความยากจะเพิ่มขึ้นมาก อาจถึงขั้นทำอะไรไม่ได้เลยหรือเกิด hallucination ก็ได้
    เพราะแบบนี้ แม้จะมีการรองรับในระดับแพลตฟอร์ม แต่ในทางปฏิบัติกลับไม่ค่อยถูกใช้งานเพราะข้อจำกัดเหล่านี้
    วิธีที่พอเป็นจริงได้คือเอาออกเฉพาะ PII บางส่วนที่มีความเสี่ยงด้านความปลอดภัยสูง และใช้ โมเดลที่เชื่อถือได้ ซึ่งทิ้ง PII ให้เร็วที่สุดเท่าที่ทำได้ แต่ถ้าจะทำแบบนั้น สถาปัตยกรรมระบบก็ต้องเปลี่ยนไปพอสมควร
  • กำลังสร้าง https://github.com/KevinXuxuxu/anon_proxy อยู่ เป็นเครื่องมือคล้าย พร็อกซีทำข้อมูลนิรนาม ที่วางไว้หน้า LLM provider
    ใช้ทั้งการตรวจจับด้วยโมเดลและ regex PII detection ร่วมกัน แล้วจัดการแทนค่าและคืนค่าแบบสองทางทั้งใน API request และ response ถ้าโฮสต์โมเดลตรวจจับไว้แบบโลคัล PII ก็จะไม่ออกไปนอกสภาพแวดล้อมภายใน
    มันมีประโยชน์มากโดยเฉพาะเวลาใช้งานกับ เอกสารอ่อนไหว อย่างกฎหมาย ภาษี หรือการย้ายถิ่นฐาน
    • ข้อดีของวิธีนี้คือสามารถต่อเข้ากับ โมเดลไหนก็ได้
      แต่บริบททั้งหมดของบทสนทนาก็ยังคงถูกมองเห็นได้โดยโมเดลและผู้ให้บริการอยู่ดี
      เพราะงั้นผมเลยชอบแนวทางแบบ Moxie's Confer https://confer.to/ มากกว่า ที่ เข้ารหัสทั้งระบบ เพื่อให้ไม่มีใครนอกจากผู้ใช้ปลายทางเห็นข้อความแบบ plaintext ได้
    • อยากรู้ว่าจัดการ การคืนค่าฝั่ง response ยังไง
      ถ้าเอกสารถูกปิดข้อมูลไว้ตั้งแต่ฝั่ง input ผลลัพธ์จาก LLM ก็น่าจะยังเป็นข้อมูลที่ถูกปิดอยู่ แล้วหลังจากนั้นจะทำต่อยังไงยังนึกภาพไม่ออก
  • รีลีสนี้มี จุดที่น่าสนใจทางเทคนิค อยู่พอสมควร
    Privacy Filter เป็นโมเดล token-classification แบบสองทิศทาง ที่เพิ่ม span decoding เข้าไป โดยเริ่มจาก autoregressive pretraining checkpoint แล้วปรับให้เป็นตัวจำแนกโทเคนบน privacy label taxonomy แบบคงที่
    แทนที่จะสร้างข้อความทีละโทเคน มันจะติดป้ายกำกับให้ input sequence ทั้งชุดในครั้งเดียว แล้วถอดรหัส span ที่สอดคล้องกันด้วยกระบวนการ constrained Viterbi
    โมเดลที่เปิดเผยออกมามีทั้งหมด 1.5B พารามิเตอร์ และมี active parameters 50M
    อีกทั้งยังระบุด้วยว่าได้เปลี่ยน LM head ของโมเดลภาษาที่ pretrain มาแล้วให้เป็น token-classification head และนำไปฝึกต่อด้วย supervised classification objective
    • ถ้าอย่างนั้นก็ดูเหมือนจะใช้สิ่งนี้ค้นหาตำแหน่งข้อมูลอ่อนไหวใน ข้อความที่ไม่มีโครงสร้าง ได้เหมือนกัน โดยไม่ต้องพึ่งเครื่องมือตรวจจับ PII แบบอื่น
      แค่ส่งต้นฉบับผ่านฟิลเตอร์เพื่อเอา span ออกมา แล้วแมป span นั้นกลับไปยังต้นฉบับ ก็จะได้ข้อมูลตำแหน่ง PII ครบเลย
  • ผมทำ https://tools.nicklothian.com/webner/index.html ไว้ ซึ่งใช้ BERT-based NER ในเบราว์เซอร์เพื่อปิด PII บางส่วน แม้จะไม่ฉลาดเท่า OpenAI
    สำหรับงานที่ผมลอง มันทำงานได้ค่อนข้างดี
    โมเดลของ OpenAI ดูเล็กพอสมควร เลยกำลังคิดว่าจะเอามาต่อเข้ากับเครื่องมือของผมด้วยดีไหม
    • เพิ่งลองกับเอกสารเมื่อกี้ แล้วดูเหมือนจะใช้งานยากมากเพราะมี false positive เยอะ
      ใส่เอกสาร markdown ประมาณ 100 บรรทัดลงไป matter ซึ่งเป็นส่วนหนึ่งของ frontmatter ถูกมองเป็นองค์กร ส่วน end ที่เป็นส่วนหนึ่งของ frontend ก็ถูกมองเป็นองค์กรเหมือนกัน และ MCP ก็ถูกจัดเป็นองค์กรด้วย
      ยังมีผลลัพธ์แบบ Following the discussion in , blahblah ที่ผิดไวยากรณ์อย่างชัดเจนอีกเยอะ
      ให้ความรู้สึกเหมือนย้อนกลับไปยุค NLP เมื่อ 10 ปีก่อน และก็ทำให้นึกอีกครั้งว่า spaCy เป็นโปรเจกต์ที่ดีมากในวงการนั้น
  • ควรพูดให้ชัดว่าโมเดลประเภทนี้แทบทั้งหมด ไร้เดียงสาและพื้นฐานมาก
    ถ้าเป็นข้อความเดี่ยวเรียบง่ายและเป็นกลางอย่าง Hi, this is Bob. โดยมากก็คงพอใช้ได้ แต่พอข้อมูลเริ่มสะสม ผมยังไม่เคยเห็นเครื่องมือ redaction PII ที่คำนึงถึง ความเสี่ยงการเปิดเผยตัวตน ได้ครบถ้วนทั้งหมด
    และเมื่อบริษัทต่าง ๆ ใช้ของพวกนี้แล้วเชื่อว่าข้อมูลถูกทำให้ไม่ระบุตัวตนแล้ว ปัญหาจะยิ่งใหญ่ขึ้น เพราะนั่น ไม่ใช่การทำให้ไม่ระบุตัวตน
    ถึงอย่างนั้น ถ้าไม่ได้เอาข้อมูลไปเปิดเผยหรือแชร์ทันที แต่ใช้ใน ขั้นตอนประมวลผลกลางทาง อย่าง moderation, human eval หรือ model training การกรองแบบนี้ก็อาจมีประโยชน์มาก
  • ค่อนข้างเสียดายที่ตัวอย่างส่วนใหญ่เป็นสิ่งที่จับได้ง่ายด้วย regex อยู่แล้ว แต่ก็ดีใจที่มีการปล่อยเป็นโมเดลโลคัลแบบเปิด
    • สำหรับลูกค้าของผม ผมกันไม่ให้อีเมลส่วนตัวหรือเบอร์โทรศัพท์ขึ้นเว็บไซต์ด้วย regular expression อยู่แล้ว
      ถึงอย่างนั้น การรันโมเดลแบบนี้เพิ่มเพื่อความสบายใจก็ดูโอเค
      เซิร์ฟเวอร์ไม่มี GPU แต่ถ้าต่ำกว่า 2k โทเคนต่อครั้ง ก็น่าจะเป็นโมเดลเบาที่รับมือได้แม้ด้วย CPU-only inference
  • พอกดลิงก์แล้วโดนรีไดเรกต์ไปยังเวอร์ชัน แปลด้วยเครื่อง ของเว็บ OpenAI ซึ่งความหมายพังหมดเลย
    เขาแปล redacted เป็นคำโปแลนด์ redagować แต่คำนั้นไม่ได้หมายถึงการทำข้อมูลนิรนาม มันใกล้กับความหมายว่าแก้ไขหรือเรียบเรียงข้อความมากกว่า
  • อยากรู้ว่ามันจะเป็นยังไงเมื่อเทียบกับ Presidio ที่ผสม regex กับโมเดล: https://microsoft.github.io/presidio/
    • ผมว่าน่าจะเอาโมเดลนี้ ใส่เข้าไปใน Presidio เพื่อใช้งานได้เหมือนกัน
  • คิดว่า https://peyeeye.ai แก้ทุกปัญหา ที่ทุกคนในเธรดนี้พูดถึงได้แบบตรงตัว
    • บริษัทที่เอาข้อมูลคนอื่นไปกวาดมาใช้โดยไม่ได้รับอนุญาต มาทำ เครื่องมือความเป็นส่วนตัว นี่มันประชดประชันเกินไปจริง ๆ
  • ดีใจที่มีการเปิดเผยครั้งนี้
    ต่อให้ไม่ได้อยู่ในอุตสาหกรรมที่มีการกำกับดูแลเข้มงวด ก็ยังมีเหตุผลมากมายที่ควรมี โมเดลและแนวปฏิบัติ แบบนี้ไว้ และในทางทฤษฎี บางส่วนก็อาจจำเป็นเพราะ EU AI Act ด้วย
    ผมใส่ redaction และ rehydration ไว้ใน https://grepture.com อยู่แล้วด้วย NER model เฉพาะทาง เพราะงั้นก็กำลังคิดจะเพิ่มตัวนี้เข้าไปใน pipeline เช่นกัน
    ถ้าเลือกวางไว้ใน hot path ได้ และทำให้แตะ request ก่อนและหลังส่งถึง LLM ได้จริง มันก็น่าจะมีประโยชน์มากในงานด้าน compliance หรือสถานการณ์ที่รับ input จากผู้ใช้โดยตรง