["Google"]["Go", "ogle"]["G", "o", "o", "g", "l", "e"]สิ่งนี้ก่อให้เกิดปัญหาสองประการที่ซับซ้อนยิ่งขึ้น:
ประการแรก ชั้นฝังตัว (Embedding Layer) ไม่ได้เข้ารหัสข้อมูลระดับตัวอักษรไว้อย่างสมบูรณ์ งานวิจัยแสดงให้เห็นว่าชั้นฝังตัวของ LLM จะเก็บข้อมูลตัวอักษรที่แข็งแกร่ง เฉพาะกับตัวอักษรตัวแรกของแต่ละโทเค็นเท่านั้น นอกเหนือจากนั้น รายละเอียดระดับตัวอักษรจะลดลงอย่างรวดเร็ว เมื่อโมเดลจำเป็นต้องนับตัวอักษรภายในโทเค็น มันจะต้องสร้างลำดับตัวอักษรขึ้นมาใหม่จากตัวแทนที่ไม่เคยถูกออกแบบให้รักษาข้อมูลนั้นไว้ ชั้น Transformer ที่สูงขึ้นจะเข้ามาชดเชยบางส่วน – นักวิจัยได้สังเกตเห็นจุด "การพัฒนาแบบก้าวกระโดด" (breakthrough) ที่โมเดลสามารถสะกดโทเค็นได้อย่างถูกต้อง – แต่กระบวนการดังกล่าวนั้นไม่น่าเชื่อถือและเปราะบาง
ประการที่สอง ตัวสร้างโทเค็นระดับย่อยคำนั้น "แทบไม่รับรู้ถึงโครงสร้างภายในของโทเค็นเลย" การศึกษาในปี 2024 จาก Arxiv ได้บัญญัติศัพท์คำว่า "คำสาปแห่งการสร้างโทเค็น" (the curse of tokenization) เพื่ออธิบายจุดอ่อนนี้: ตัวสร้างโทเค็นมีความอ่อนไหวต่อข้อผิดพลาดในการพิมพ์และความยาวที่ไม่เท่ากันโดยเนื้อแท้ แถมยังมองไม่เห็นองค์ประกอบภายในของตัวโทเค็นเอง คำว่า "journalism" อาจเป็นเพียงโทเค็นเดียว – โมเดลไม่เคยเรียนรู้ที่จะแยกมันออกเป็น
j-o-u-r-n-a-l-i-s-m ในระดับตัวอักษร ดังนั้นเมื่อถูกถามให้สะกด มันจึงเดา
ผลลัพธ์คือสิ่งที่ผู้ใช้เห็นกับ AI Overview ของ Google: AI ที่สามารถโต้วาทีเรื่องปรัชญาและเขียนโค้ดได้อย่างมั่นใจ กลับยืนกรานว่าคำว่า "Google" มีตัว 'p' สองตัว และคำว่า "poop" มีตัว 'r' หนึ่งตัวพอดีเป๊ะ
หากปัญหาอยู่ที่การสร้างโทเค็น การแก้ไขที่ดูสมเหตุสมผลก็คือการใช้โมเดลระดับตัวอักษร (Character-level) หรือระดับไบต์ (Byte-level) เพื่อให้โมเดลมองเห็นทุกตัวอักษร แนวทางนั้นมีอยู่จริง – โมเดลอย่าง ByT5 ทำงานโดยตรงกับไบต์ดิบ – แต่มันไม่ได้รับการยอมรับอย่างแพร่หลายเพราะทำให้การรันโมเดลมีต้นทุน (Compute cost) แพงขึ้นอย่างมาก
การย้ายไปสู่การประมวลผลระดับตัวอักษรล้วนๆ จะทำให้ความยาวของลำดับข้อมูล (Sequence lengths) เพิ่มขึ้นประมาณ 3–5 เท่า ซึ่งเพิ่มต้นทุนด้านการคำนวณตามสัดส่วน และทำให้โมเดลเรียนรู้การพึ่งพาระยะไกลและความสัมพันธ์เชิงความหมายได้ยากขึ้นมาก ตัวสร้างโทเค็นระดับย่อยคำคือการประนีประนอมเพื่อประสิทธิภาพที่ทำให้ LLM ยุคใหม่เกิดขึ้นได้จริง: มันบีบอัดข้อความให้มีขนาดพจนานุกรมที่จัดการได้ ในขณะที่ยังรักษาความหมายไว้เพียงพอสำหรับการสร้างภาษาที่ลื่นไหล
นักวิจัยเห็นพ้องต้องกันในวงกว้างว่า ตัวสร้างโทเค็นที่ "สมบูรณ์แบบ" น่าจะไม่มีทางมีอยู่จริง ตัวสร้างโทเค็น "มักจะสร้างการเข้ารหัสที่ไม่ซ้ำใคร" และสร้าง "ความไม่สอดคล้องกันในการนำเสนอ" ซึ่งเป็นเรื่องเชิงสถาปัตยกรรมระดับลึก – ไม่ใช่บั๊กธรรมดาที่จะแพตช์ได้
ข้อแลกเปลี่ยนระหว่างความแม่นยำระดับตัวอักษรและความลื่นไหลเชิงความหมายนั้นดูเหมือนจะเป็นข้อจำกัดพื้นฐานของสถาปัตยกรรม Transformer
ความล้มเหลวในการสะกดคำได้เผยให้เห็นข้อจำกัดเชิงโครงสร้างหลายประการที่บังคับใช้ได้เกินกว่าแค่ AI Overview ของ Google
LLM เป็นเครื่องมือจับคู่รูปแบบ (Pattern matcher) ไม่ใช่เครื่องมือจัดการสัญลักษณ์ (Symbol manipulator) การนับตัวอักษรเป็นงานอัลกอริทึมง่ายๆ สำหรับคอมพิวเตอร์ที่รันโค้ดดั้งเดิม แต่ LLM ไม่ได้ทำงานตามอัลกอริทึม – มันทำนายโทเค็นถัดไปที่มีความเป็นไปได้สูงสุดโดยอาศัยรูปแบบทางสถิติในข้อมูลฝึกอบรม เมื่อถูกถามถึงจำนวนตัวอักษร โมเดลกำลังสร้างคำตอบที่ฟังดูน่าเป็นไปได้จากความสัมพันธ์ที่เรียนรู้มา ไม่ใช่การดำเนินการนับแต่อย่างใด
ความมั่นใจไม่มีความสัมพันธ์ใดๆ กับความถูกต้อง AI เสนอคำตอบว่า "สองตัว" ด้วยหลักไวยากรณ์ที่สมบูรณ์แบบ แต่มันผิดอย่างสิ้นเชิง นี่คือจุดเด่นของอาการประสาทหลอนของ LLM (Hallucination): ผลลัพธ์ที่ฟังดูมั่นใจและน่าเชื่อถือ แต่ปราศจากกลไกการตรวจสอบที่ฝังอยู่ภายใน Google เองก็ยอมรับในปี 2024 ว่าในขณะที่ AI Overviews นั้น "ถูกสร้างมาเพื่อแสดงเฉพาะข้อมูลที่ได้รับการสนับสนุนจากผลการค้นหาทางเว็บอันดับต้นๆ เท่านั้น" พวกมันก็ยังสามารถตีความคำถามหรือความแตกต่างของภาษาได้อย่างผิดเพี้ยน
จุดบอดนี้เป็นเรื่องของสถาปัตยกรรม ไม่ใช่เรื่องบังเอิญ LLM กระแสหลักทุกตัวที่ใช้การสร้างโทเค็นระดับย่อยคำ – รวมถึงโมเดลจาก OpenAI, Anthropic และ Meta – ต่างก็แสดงจุดอ่อนที่คล้ายกันในงานระดับตัวอักษร เช่น การสะกดคำย้อนกลับ, การนับตัวอักษร หรือการจัดการแอนนาแกรม การขยายขนาดโมเดลให้ใหญ่ขึ้นช่วยได้บ้างในระดับหนึ่ง แต่ความลำเอียงนี้ก็ยังคงอยู่
ความล้มเหลวเหล่านี้อาจดูน่าอับอาย – AI ที่สะกดชื่อบริษัทของตัวเองไม่ได้ – แต่วงการอุตสาหกรรมไม่ได้มองว่านี่เป็นวิกฤต เพราะคุณค่ามหาศาลของ LLM อยู่ที่อื่น
การสร้างข้อความที่ลื่นไหล, การสรุปใจความ, การให้เหตุผล, การแปลภาษา, การสร้างโค้ด – ความสามารถทั้งหมดนี้มาจากการที่โมเดลทำงานในระดับ เชิงความหมาย (Semantic) ซึ่งการมองข้อความเป็นโทเค็นแบบนามธรรมนั้นเป็นคุณสมบัติ ไม่ใช่ข้อบกพร่อง ความแม่นยำระดับตัวอักษรไม่ใช่สิ่งที่สถาปัตยกรรมเหล่านี้ออกแบบมาเพื่อให้เหมาะสมที่สุดตั้งแต่แรก
วิธีแก้ปัญหาในทางปฏิบัติคือการส่งต่อคำถามเกี่ยวกับการสะกดและการนับไปยังซอฟต์แวร์ที่ใช้กฎแบบดั้งเดิม (Rule-based software) แทนที่จะขอให้ LLM จัดการ ระบบ AI Overview ที่ใช้งานอยู่หลายแห่งพยายามตรวจจับและเลี่ยงคำถามประเภทนี้อยู่แล้ว แม้ว่าข้อผิดพลาดที่เห็นได้ชัดในเดือนพฤษภาคม 2026 จะแสดงให้เห็นว่าตัวระบบตรวจจับเองก็ยังไม่สมบูรณ์แบบ มีการศึกษาอีกชิ้นที่พบว่า AI Overview ของ Google ตอบคำถามการสะกดคำย้อนหลังผิดพลาดสูงถึง 52% ของเวลาทั้งหมด – และมีเพียง 10% ของคำที่มีสามพยางค์ขึ้นไปเท่านั้นที่ถูกสะกดย้อนหลังอย่างถูกต้อง
Google กำลังดำเนินการแก้ไขปัญหาเฉพาะเรื่องการนับที่เผยแพร่สู่สาธารณะ แต่สำหรับใครก็ตามที่เข้าใจข้อแลกเปลี่ยนของการสร้างโทเค็น บทเรียนที่แท้จริงไม่ใช่ว่า Google ปล่อยผลิตภัณฑ์ที่มีข้อบกพร่อง แต่มันคือการที่สถาปัตยกรรมที่ขับเคลื่อนการปฏิวัติ AI นั้นมีจุดบอดขั้นพื้นฐาน – และไม่มีใครพบวิธีแก้ไขมันได้โดยไม่ต้องเสียสละสิ่งที่ทำให้ LLM มีคุณค่าตั้งแต่แรก
Comments
0 comments