โมเดลภาษาขนาดใหญ่ (Large language models) เติบโตขึ้นผ่านสามมิติที่คุ้นเคย เราขยายขนาดการทำ pre-training โดยการป้อนข้อความให้มากขึ้น เราปรับปรุงพวกมันด้วย post-training เพื่อเพิ่มความแม่นยำในการปฏิบัติตามคำสั่ง และเราทุ่มทรัพยากรการคำนวณในช่วงทดสอบ (test-time compute) เพื่อให้ได้คำตอบที่เร็วขึ้น แต่ละวิธีเหล่านี้ช่วยผลักดันให้โมเดลสร้างงานเขียนที่ดียิ่งขึ้น เร็วขึ้น และมีความสอดคล้องกันมากขึ้น แต่ไม่มีวิธีใดเลยที่จัดการกับปัญหาที่ยากกว่าโดยตรง นั่นคือการรู้ว่างานเขียนนั้นถูกต้องจริงหรือไม่
ช่องว่างนั้นกำลังกลายเป็นเรื่องอันตราย โมเดลอาจสร้างสคริปต์ Python ที่มีการย่อหน้าและโครงสร้างตรรกะที่สมบูรณ์แบบ แต่กลับเกิดข้อผิดพลาดทันทีที่เริ่มทำงาน มันอาจอธิบายอาการทางการแพทย์ด้วยความมั่นใจและดูน่าเชื่อถือ แต่กลับวินิจฉัยผิดพลาด สำหรับแชทบอท สิ่งเหล่านี้คือบั๊กที่น่าอับอาย แต่สำหรับเอเจนต์อัตโนมัติ (autonomous agents) ที่ทำงานโดยไม่มีมนุษย์ควบคุม สิ่งเหล่านี้คือความล้มเหลวที่มีผลกระทบตามมาจริง การสร้างเนื้อหา (Generation) และความจริง (Truth) ไม่ใช่ทักษะเดียวกัน และการตระหนักถึงความแตกต่างนี้คือก้าวแรกสู่การสร้างระบบที่เราสามารถไว้วางใจได้
กับดักของการสร้างเนื้อหา (The Generation Trap)
เส้นทางการขยายขนาดมาตรฐานทั้งสามมุ่งเน้นไปที่ความลื่นไหลและการทำงานให้สำเร็จ ไม่ใช่ความถูกต้องทางความรู้ (epistemic accuracy) Pre-training สร้างรูปแบบทางสถิติที่กว้างขวางผ่านโทเคน (tokens) นับล้านล้านตัว Post-training ปรับจูนโมเดลให้สอดคล้องกับความพึงพอใจของมนุษย์ ซึ่งมักจะให้รางวัลกับความสุภาพและความมั่นใจมากกว่าความถูกต้องที่เข้มงวด ส่วน Test-time compute ช่วยให้โมเดลมีโทเคนในการคิดต่อหนึ่งคำขอมากขึ้น ช่วยปรับปรุงรูปแบบและโครงสร้างแบบทีละขั้นตอน แต่ก็ยังคงมองว่าผลลัพธ์สุดท้ายเป็นเพียงการพูดฝ่ายเดียว (monologue) มากกว่าจะเป็นคำตอบที่ผ่านการตรวจสอบแล้ว
ผลลัพธ์ที่ได้คือ "กับดักความลื่นไหล" (fluency trap) โค้ดดูสะอาดตา คำอธิบายฟังดูน่าเชื่อถือ ข้อเท็จจริงดูเหมือนจะถูกต้อง แต่ความเนี้ยบที่ผิวเผินนั้นกลับซ่อนข้อผิดพลาดที่อยู่เบื้องหลังไว้ นักพัฒนาที่คัดลอกโค้ดที่สร้างขึ้นไปใส่ในระบบการทำงานจริง (production pipeline) โดยไม่ตรวจสอบอย่างละเอียดมีความเสี่ยงที่จะทำให้ระบบหยุดทำงาน แพทย์ที่ใช้ผู้ช่วย AI อาจต้องเผชิญกับความรับผิดชอบทางกฎหมายที่ร้ายแรงหากโมเดลสับสนระหว่างปฏิกิริยาระหว่างยาที่คล้ายกันสองชนิด เราได้ฝึกฝนโมเดลมาเพื่อให้ "แสดงผล" (perform) ไม่ใช่เพื่อให้ "ตรวจสอบตัวเอง" (audit themselves)
การตรวจสอบในฐานะแกนการขยายขนาด (Verification as a Scaling Axis)
เฟรมเวิร์กที่เรียกว่า LLM-as-a-Verifier ได้เปลี่ยนมุมมองต่อปัญหานี้ไปอย่างสิ้นเชิง แทนที่จะมองว่าการตรวจสอบเป็นเพียงสิ่งที่คิดขึ้นภายหลังหรือเป็นขั้นตอนการตรวจสอบโดยมนุษย์แยกต่างหาก มันกลับมองว่าการประเมินตนเอง (self-evaluation) เป็นแกนการขยายขนาดที่สี่ ควบคู่ไปกับ pre-training, post-training และการเร่งความเร็วในการอนุมาน (inference acceleration)
แนวคิดคือการใช้ความสามารถในการใช้เหตุผลที่มีอยู่ของโมเดลเพื่อตัดสินผลลัพธ์ของตัวเอง หลังจากสร้างคำตอบที่เป็นไปได้แล้ว โมเดลตัวเดิมจะถอยออกมาเพื่อประเมินคำตอบนั้น สิ่งนี้สร้างวงจรปิด: สร้าง, ให้คะแนน, แก้ไข, และทำซ้ำ โมเดลไม่ได้ถูกฝึกใหม่ด้วยน้ำหนัก (weights) หรือชุดข้อมูลใหม่ แต่มันเพียงแค่ใช้ความฉลาดที่มีอยู่แล้วกับเทมเพลตคำสั่ง (prompt template) ที่ต่างออกไป นั่นคือการสวมบทบาทเป็น "นักวิจารณ์" แทนที่จะเป็น "ผู้เขียน"
การเปลี่ยนแปลงนี้มีความสำคัญเพราะมันแยก "ความสามารถ" ออกจาก "ความน่าเชื่อถือ" โมเดลที่มีขนาดเล็กกว่าแต่ตรวจสอบได้ดีสามารถทำงานได้เหนือกว่าโมเดลที่มีขนาดใหญ่กว่าแต่ตรวจสอบไม่ได้ คุณกำลังขยายขนาดของ "การตัดสินใจ" (judgment) ไม่ใช่แค่จำนวนพารามิเตอร์ และนั่นจะเปลี่ยนสิ่งที่ระบบสามารถทำได้อย่างปลอดภัย
พลังของการให้คะแนนเชิงความน่าจะเป็น (The Power of Probabilistic Scoring)
ความพยายามในการตรวจสอบส่วนใหญ่มักล้มเหลวเพราะต้องการคำตัดสินแบบสองทาง (binary verdict) ว่าคำตอบนี้ถูกต้องหรือไม่? ใช่ หรือ ไม่ คำสั่งที่หยาบเกินไปเช่นนี้ทำให้สูญเสียข้อมูล คำตอบหนึ่งอาจจะถูกต้องเกือบทั้งหมดแต่มีข้อผิดพลาดร้ายแรงเพียงจุดเดียว หรืออาจจะผิดเกือบทั้งหมดแต่มีข้อมูลเชิงลึกที่ช่วยกู้สถานการณ์ได้หนึ่งอย่าง คะแนนแบบ binary จะบีบอัดความละเอียดอ่อนทั้งหมดนั้นให้เหลือเพียงบิตเดียว
LLM-as-a-Verifier แทนที่สิ่งนี้ด้วยการให้คะแนนเชิงความน่าจะเป็น (probabilistic scoring) แทนที่จะเป็นแค่การยกนิ้วโป้งขึ้นหรือลง โมเดลจะคืนค่าเป็นตัวเลขต่อเนื่อง เช่น 0.92 ตัวเลขทศนิยมนั้นมีความหมาย มันบอกคุณว่าโมเดลเกือบจะมั่นใจว่าคำตอบนั้นถูกต้อง หรือมันเริ่มรู้สึกว่ามีบางอย่างผิดปกติที่ 0.34 มนุษย์ที่ควบคุมระบบสามารถกำหนดเกณฑ์ (thresholds) ได้ อะไรก็ตามที่ต่ำกว่า 0.60 อาจกระตุ้นให้เกิดการสร้างคำตอบใหม่โดยอัตโนมัติ ช่วงระหว่าง 0.60 ถึง 0.85 อาจถูกทำเครื่องหมายเพื่อให้มนุษย์ตรวจสอบ และหากสูงกว่า 0.90 ระบบจะทำงานโดยอัตโนมัติ
คะแนนแบบต่อเนื่องยังช่วยให้สามารถคำนวณทางคณิตศาสตร์จากความมั่นใจได้ คุณสามารถหาค่าเฉลี่ยจากการตรวจสอบหลายครั้ง ถ่วงน้ำหนักตามความหลากหลายของ prompt หรือเปรียบเทียบคะแนนระหว่างคำตอบที่เป็นไปได้ต่าง ๆ เพื่อเลือกคำตอบที่ดีที่สุด การตัดสินแบบ binary ไม่สามารถรองรับการตัดสินใจที่ละเอียดอ่อนเช่นนี้ได้
ข้อได้เปรียบในทางปฏิบัติสามประการ (Three Practical Advantages)
เฟรมเวิร์กนี้ได้รับความแข็งแกร่งมาจากคุณสมบัติเฉพาะสามประการ
ความละเอียด. คะแนน 0.82 สื่อสารบางอย่างที่คำว่า "ถูกต้อง" สื่อไม่ได้ มันบ่งบอกถึงความเกือบจะแน่นอนแต่ยังมีความสงสัยหลงเหลืออยู่ ในทางวิศวกรรมซอฟต์แวร์ นั่นอาจหมายถึงโค้ดสามารถคอมไพล์ได้และจัดการกรณีหลักได้ แต่อาจจะพลาดเงื่อนไขขอบเขต (edge condition) ในการให้เหตุผลทางการแพทย์ มันอาจบ่งชี้ถึงการวินิจฉัยที่มีความเป็นไปได้สูงแต่ยังคงต้องมีการทดสอบเพื่อยืนยัน คะแนนที่มีความละเอียดช่วยให้ระบบปลายน้ำ (downstream systems) สามารถปรับจูนการตอบสนองของตนเองได้ แทนที่จะปฏิบัติกับความสำเร็จทุกอย่างว่าเท่าเทียมกัน
การทำซ้ำ. เนื่องจากกระบวนการตรวจสอบ (verification) มีต้นทุนต่ำเมื่อเทียบกับการสร้าง (generation) คุณจึงสามารถรันซ้ำได้หลายครั้งโดยปรับเปลี่ยนพรอมต์ (prompt) เล็กน้อย หรือปรับค่า temperature หากการตรวจสอบที่เป็นอิสระต่อกันสามครั้งให้ผลลัพธ์เป็น 0.91, 0.89 และ 0.93 แสดงว่าคุณได้ข้อสรุปที่เป็นเอกฉันท์ หากผลลัพธ์กระจายตัวอย่างกว้าง เช่น 0.91, 0.42 และ 0.87 คุณจะรู้ว่าโมเดลยังไม่มีความแน่นอนและคำตอบนั้นยังต้องได้รับการปรับปรุง การลงคะแนนเสียงข้างมาก (majority voting) ระหว่างผู้ตัดสินแบบไบนารี (binary judges) นั้นหยาบเกินไป การหาค่าเฉลี่ยของคะแนนแบบต่อเนื่อง (continuous scores) จะช่วยเผยให้เห็นความคลุมเครือ
การแยกส่วนประกอบ. งานที่ซับซ้อนมักจะไม่ล้มเหลวในทุกส่วนพร้อมกัน งานด้านหุ่นยนต์อาจแบ่งย่อยออกเป็น การรับรู้ (perception), การวางแผน (planning) และการสั่งการมอเตอร์ (motor execution) งานวิศวกรรมซอฟต์แวร์อาจแยกออกเป็น การออกแบบอัลกอริทึม, การนำไปใช้งาน (implementation) และความครอบคลุมของการทดสอบ (testing coverage) การให้คะแนนเชิงความน่าจะเป็น (probabilistic scoring) ช่วยให้ผู้ตรวจสอบสามารถประเมินแต่ละส่วนประกอบย่อยได้เป็นรายชิ้น คุณไม่ได้เรียนรู้แค่ว่าคำตอบนั้นอ่อนแอ แต่คุณจะรู้ว่ามันอ่อนแอที่จุดไหน ความแม่นยำในการวินิจฉัยนั้นช่วยให้การแก้ไขทำได้รวดเร็วและตรงจุดมากขึ้น
ผลลัพธ์ในโดเมนที่ยาก
ประโยชน์ของเฟรมเวิร์กนี้ปรากฏให้เห็น