เทคนิคตรวจจับโทเค็นที่ Under-trained ในโมเดลภาษาขนาดใหญ่โดยอัตโนมัติ

• LLM แยกขั้นตอน การสร้าง tokenizer ออกจากการฝึกโมเดล ทำให้โทเค็นบางตัวอย่าง _SolidGoldMagikarp อาจก่อให้เกิดพฤติกรรมที่ไม่คาดคิดได้
• แก่นของปัญหาคือ under-trained tokens ที่มีอยู่ในคลังคำศัพท์ของ tokenizer แต่แทบไม่ปรากฏหรือไม่ปรากฏเลยระหว่างการฝึก ซึ่งมักถูกเรียกว่า “glitch tokens”
• งานวิจัยเสนอวิธีค้นหาโทเค็นเหล่านี้โดยอัตโนมัติ ด้วยการผสาน การวิเคราะห์ tokenizer, ตัวชี้วัดจากค่าน้ำหนัก embedding ของโมเดล และเทคนิค prompting
• โทเค็นเหล่านี้ทำให้ ความจุคลังคำศัพท์ ของ tokenizer ขนาดคงที่สูญเปล่า และอาจส่งผลต่อความยาวอินพุต·เอาต์พุต ต้นทุน inference อาการ hallucination หรือเอาต์พุตที่เสียหาย
• ในสภาพแวดล้อมที่ใช้เครื่องมือและ agent ซึ่งค้นหา·ประมวลผลข้อมูลภายนอก การตรวจจับและทำความสะอาด under-trained token เชื่อมโยงโดยตรงกับ ความปลอดภัย และความทนทานของโมเดลที่นำไปใช้งาน

---

ความไม่สอดคล้องกันระหว่าง tokenizer กับการฝึกโมเดล

• องค์ประกอบส่วนใหญ่ของ LLM ถูกฝึกแบบ unsupervised จากข้อมูลขนาดใหญ่ แต่ tokenizer มักถูกฝึกแยกต่างหากด้วยอัลกอริทึมคนละแบบและชุดข้อมูลที่เล็กกว่า
• GPT-2 ได้วางรากฐานจำนวนมากให้กับการทำ language modeling ด้วย Transformer ในปัจจุบัน และเฟรมเวิร์กการ tokenize ที่อิงกับ byte-pair encoding(BPE) ก็ถูกนำไปใช้อย่างแพร่หลาย
• การ tokenize แบบ BPE จะแปลงข้อความอินพุตเป็นลำดับของโทเค็นระดับ subword และรวมโทเค็นที่อยู่ติดกันทีละคู่ซ้ำ ๆ ตามกฎการ merge ที่กำหนดไว้
• กฎการ merge ถูกเรียนรู้ด้วยอัลกอริทึมแบบ greedy จากชุดข้อมูลที่เล็กกว่า ซึ่งควรมีความเป็นตัวแทนสอดคล้องกับข้อมูลฝึกของ LLM

โครงสร้างที่ทำให้เกิด glitch token

• เมื่อ tokenizer และการฝึกโมเดลถูกแยกออกจากกัน อาจเกิดสถานะที่โทเค็นบางตัว แทบไม่ปรากฏหรือไม่ปรากฏเลย ระหว่างการฝึกโมเดล
• หากโทเค็นเหล่านี้อยู่ในอินพุต อาจก่อให้เกิดพฤติกรรมที่ไม่คาดคิด เช่น hallucination หรือเอาต์พุตที่เสียหาย
• งานวิจัยแยกเรียกโทเค็นเหล่านี้ว่า under-trained tokens หรือ untrained tokens
  • ใช้คำว่า untrained เฉพาะเมื่อมีสัญญาณชัดเจนว่าโทเค็นนั้นไม่ปรากฏในข้อมูลฝึกของโมเดล
  • โดยทั่วไปยังมักถูกเรียกว่า “glitch tokens” ด้วย
• กรณีตัวอย่างที่เป็นที่กล่าวถึงคือโทเค็น _SolidGoldMagikarp

ข้อจำกัดของวิธี tokenize เดิมและทางเลือก

• งานวิจัยล่าสุดบางส่วนศึกษาวิธีเลิกใช้ tokenization แล้วเปลี่ยนไปใช้อินพุตแบบ raw byte แต่ตัวเลือกนี้มักมี ต้นทุนด้านความเร็ว inference สูง
• ต้นทุนด้านความเร็วอาจชดเชยได้ด้วยสถาปัตยกรรมพิเศษในเลเยอร์แรก·สุดท้าย หรือการคำนวณแบบแปรผันในเลเยอร์กลาง
• แนวทางเหล่านี้ยังไม่ได้ถูกนำไปใช้อย่างแพร่หลาย และโมเดลสมัยใหม่ส่วนใหญ่ยังคงพึ่งพา subword tokenization
• ทางเลือกหลักของ BPE คือวิธี Unigram แต่แม้จะมีงานวิจัยที่ระบุว่าดีกว่า BPE โดยทั่วไปก็ยังไม่ได้ถูกใช้อย่างแพร่หลายมากนัก

ปัญหาเชิงปฏิบัติของ under-trained token

• under-trained token ครอบครอง ความจุคลังคำศัพท์ ใน tokenizer ขนาดคงที่ ซึ่งโทเค็นที่ปรากฏบ่อยกว่าสามารถนำไปใช้ได้
  • สิ่งนี้อาจทำให้พลาดโอกาสลดความยาวอินพุต·เอาต์พุตเฉลี่ยและต้นทุน inference
• หากโทเค็นเหล่านี้ถูกใส่ลงในข้อมูลอินพุตโดยตั้งใจหรือโดยบังเอิญ อาจทำให้โมเดลสร้างเอาต์พุตที่ไม่ต้องการและทำให้แอปพลิเคชัน downstream พังได้
• เมื่อ การใช้เครื่องมือ ของ LLM และ agent ที่ค้นหา·ประมวลผลข้อมูลภายนอกเพิ่มขึ้น ความทนทานต่ออินพุตที่ไม่คาดคิดหรืออินพุตที่ประสงค์ร้ายจึงสำคัญยิ่งขึ้น
• หากโมเดลถูกผลักออกนอกการกระจายของข้อมูลที่ฝึกมา โทเค็นเหล่านี้ก็อาจถูกนำไปใช้เพื่อหลบเลี่ยง guardrail ได้

แนวทางตรวจจับอัตโนมัติและเครื่องมือสาธารณะ

• แม้ก่อนหน้านี้จะมีงานที่พยายามหาโทเค็นเหล่านี้ด้วยการวิเคราะห์โมเดลและ tokenizer แต่ยังขาด วิธีอัตโนมัติที่น่าเชื่อถือ ซึ่งทำงานได้สม่ำเสมอกับโมเดลหลากหลายชนิด
• งานวิจัยผสานสามวิธีเพื่อระบุโทเค็นที่เป็นปัญหา
  • การวิเคราะห์ tokenizer
  • ตัวชี้วัดจากค่าน้ำหนัก embedding ของโมเดล
  • เทคนิค prompting
• วิธีเหล่านี้ถูกนำไปใช้กับ โมเดล open-weight ยอดนิยมและเพิ่งเปิดเผยหลายตัว และยังสำรวจคร่าว ๆ ถึงวิธีขยายไปยังโมเดลแบบปิด
• มีการเผยแพร่เครื่องมือวิเคราะห์ทั่วไปที่เข้ากันได้กับโมเดลบน Hugging Face รวมถึงผลลัพธ์ละเอียดรายโมเดลด้วย
  • cohere-ai/magikarp

[GN⁺]

ความคิดเห็นจาก Hacker News

• วิดีโอเรื่อง glitch token ของ Computerphile เมื่อ 1 ปีก่อนดูดีมาก: https://www.youtube.com/watch?v=WO2X3oZEJOA

  • ไม่รู้ทำไมวิดีโอนี้ดูน่าสนใจกว่า preprint ของ paper เสียอีก

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

  • ผมคิดว่า model distillation ทำแบบนี้อยู่ SparseGPT เป็นตัวอย่างใหญ่ และถ้าจำไม่ผิดมันลบ parameter ออกไปได้ 50% โดยแทบไม่เสีย accuracy
    ผมเคยเห็น paper ล่าสุดบางฉบับที่อ้างอิง SparseGPT แล้วทำ sparsity ได้ถึงประมาณ 70–80% ซึ่งค่อนข้างน่าประทับใจ
  • การ “ลบ weight ที่แทบไม่มีข้อมูลไหลผ่าน” ไม่ใช่แนวคิดของ sparse neural network หรอกหรือ?
  • regular model สามารถบีบอัดหรือรวมเข้าด้วยกันได้อยู่แล้ว

• ไม่น่าเชื่อเลยว่าโมเดลของบริษัทแคนาดาจะมี token ที่ฝึกมาไม่พอ เกี่ยวกับฮอกกี้อยู่ด้วย แม้ว่าจะเป็นภาษาเยอรมันก็ตาม
  ล้อเล่นเท่านี้ก่อน เนื้อหานี้เจ๋งมาก และผมตั้งตารอให้เราเข้าใจมากขึ้นว่า tokenization ส่งผลต่อโมเดลอย่างไร โดยเฉพาะการค้นพบว่าโมเดล open source ยุคแรกจำนวนไม่น้อยมีปัญหากับ carriage return ซึ่งน่าสนใจ เพราะขึ้นอยู่กับแหล่งข้อมูลแล้ว carriage return อาจโผล่มาได้ไม่ได้น้อยเลย

• มีวิธีวินิจฉัยการฝึกที่อิงทฤษฎีเมทริกซ์สุ่ม โดยใช้ spectral density ของ correlation matrix ของ weight
  นำ spectral density ของแต่ละเลเยอร์ไป fit กับ truncated power law และถ้าเลขชี้กำลัง alpha ของ power law มากกว่า 2 เล็กน้อย ก็ถือว่าฝึกมาอย่างเหมาะสม
  https://jmlr.org/beta/papers/v22/20-410.html

• ทางแก้ไม่ใช่แค่ฝึก tokenizer ด้วย corpus เดียวกับ LLM หรือ? ไม่ค่อยเข้าใจว่าทำไม การใช้ tokenizer ซ้ำ ถึงแพร่หลายขนาดนี้ มีใครรู้ไหม?

  • นอกจากสิ่งที่คนอื่นพูดไปแล้ว ต่อให้ฝึก tokenizer ด้วย dataset เดียวกับข้อมูลฝึกได้เป๊ะ ๆ ปัญหาแบบนี้ก็ไม่ได้หายไปทั้งหมด
    ในวิธี BPE token บางตัวอาจถูกรวมกับ token อื่นจนทำให้เกิด token ที่หายากมากได้ สมมติว่ามี token X และ Y และแทบทุกครั้งหลัง X จะเป็น Y กระบวนการ BPE จะสร้าง token ใหม่ XY แต่ไม่ได้ลบ token X เดิมออก ทำให้ X อยู่ในสภาพฝึกมาไม่พอ
    ถ้าจะแก้เรื่องนี้ น่าจะต้องใช้อัลกอริทึมการ merge ที่ซับซ้อนกว่า greedy merge
  • ผมนึกเหตุผลที่นำ tokenizer กลับมาใช้ซ้ำได้สองอย่าง
    อย่างแรก คือกรณีที่ต้องการฝึกต่อจาก pretraining ของโมเดล ไม่ได้เริ่มจากศูนย์ อย่างไรก็ตาม บางคนอาจไม่รู้ว่าสามารถนำ weight ของโมเดลมาใช้ซ้ำได้ค่อนข้างง่าย แม้จะฝึกด้วย tokenizer ใหม่ก็ตาม ผมเขียนบทความเกี่ยวกับวิธีนั้นไว้: https://umarbutler.com/how-to-reuse-model-weights-when-train...
    อย่างที่สอง คือความสะดวกสำหรับผู้ใช้ปลายทาง การ tokenize corpus ขนาดใหญ่มากและแบ่งเป็น chunk อาจใช้เวลานาน และถ้าประมวลผลด้วย GPT2 tokenizer ครั้งเดียว แล้วใช้ข้อมูลเดียวกันฝึกหลายโมเดลได้ ก็ไม่ต้อง tokenize ใหม่ทั้งหมด ซึ่งเป็นเรื่องดี
  • ดูจากบทคัดย่อ เทคนิคแบบนี้น่าจะมีประโยชน์เมื่อเข้าถึง corpus ไม่ได้ เช่น กรณีที่ดาวน์โหลด weight แบบ open source ได้ แต่ corpus ไม่เปิดเผย
    ถ้าไม่ใช่แบบนั้น ผมคิดว่าก็คำนวณ token histogram จากตัวอย่างสถิติของ corpus ก็พอไม่ใช่หรือ
  • โดยปกติจะเริ่มจากการพยายามใช้ corpus เดียวกันสำหรับ tokenizer และ LLM แต่หลังจากฝึก tokenizer แล้ว ระหว่างทดสอบ LLM ก็พบว่าบางส่วนของ corpus เป็นขยะไร้ประโยชน์
    ไม่ได้มีเจตนาร้ายต่อ SolidGoldMagikarp ที่ทุ่มเทใน counting subreddit แต่ส่วนแบบนั้นจะถูกตัดออกจากการฝึกภายหลัง ทว่า ณ จุดนั้น tokenizer กลายเป็น ส่วนหนึ่งของ API ไปแล้ว ถ้าเปลี่ยนเป็นเวอร์ชันใหม่ก็จะทำให้สิ่งอื่นพัง สุดท้าย token ที่ไม่จำเป็นจึงยังค้างอยู่ใน vocabulary
  • เป็นไปได้ก็จริง แต่ถ้า corpus ใหญ่มากก็ทำได้ยากในทางปฏิบัติ

• ชื่อ paper ยอดเยี่ยมจริง ๆ

  • ชื่อเต็มคือ “Fishing for Magikarp: Automatically Detecting Under-trained Tokens in Large Language Models”