สวัสดีครับ
ผมคือนักพัฒนาที่เคยมาแนะนำบริการการมีส่วนร่วมของภาคประชาชนชื่อ 'Uhheung' เมื่อประมาณ 6 เดือนก่อน ซึ่งเป็นบริการที่ช่วยให้ดูร่างกฎหมายและแสดงความคิดเห็นได้ง่ายขึ้น
ครั้งนี้ผมได้เพิ่มฟีเจอร์ AI ตรวจสอบข้อเท็จจริง เพื่อพยายามลดข่าวปลอมและการถกเถียงที่สิ้นเปลืองในคอมมูนิตี้ จึงอยากมาแบ่งปันทั้งสิ่งที่กังวลและความผิดพลาดเชิงเทคนิคที่เจอระหว่างทาง
ตอนแรกผมเริ่มแบบง่ายมาก แค่โยนข้อความเป้าหมายเข้าไปแล้วเขียนพรอมป์ต์ว่า "ช่วยตรวจสอบว่าข้อความนี้เป็นความจริงหรือไม่" แต่พอเอาไปใช้จริงในบริการ ก็มีปัญหาที่ไม่คาดคิดถาโถมเข้ามา
ระบบพยายามตรวจสอบข้อเท็จจริงแม้กระทั่ง 'ความคิดเห็น' ส่วนบุคคลธรรมดา ราวกับว่าเป็นข้อเท็จจริง และยังสรุปออกมาอย่างน่าเชื่อถือทั้งที่ไม่มีหลักฐานรองรับด้วย ยิ่งไปกว่านั้น ถ้าหลังจากตรวจสอบข้อเท็จจริงเสร็จแล้ว ผู้เขียนมาแก้ไขเนื้อหา ก็จะเกิดสถานการณ์ชวนงงที่ผลลัพธ์ไม่สอดคล้องกับต้นฉบับ
สุดท้ายผมเลยทิ้งโครงสร้างเริ่มต้นไปเกือบทั้งหมด และตอนนี้ได้ปรับแก้ pipeline ค่อนข้างมาก จนมาทำงานในรูปแบบด้านล่างนี้
1. คัดแยกสิ่งที่ต้องตรวจสอบ (ความคิดเห็น vs ข้อเท็จจริง)
แทนที่จะตรวจสอบทั้งข้อความรวดเดียว เราให้ระบบดึงเฉพาะ 'ข้ออ้างเชิงข้อเท็จจริง' ที่ตรวจสอบเชิงวัตถุวิสัยได้ออกมาก่อน เช่น จะเมินประโยคตัดสินเชิงคุณค่าอย่าง "นโยบายนี้แย่ที่สุด" และเลือกเอาเฉพาะประโยคอย่าง "ร่างกฎหมายนี้ขึ้นภาษี 20%" มาเป็นเป้าหมาย
เพื่อให้เข้าใจบริบทได้แม่นยำ เราไม่ได้ดูแค่ข้อความเป้าหมาย แต่ยัง นำโพสต์ต้นฉบับ คอมเมนต์แม่ ไปจนถึงรูปภาพที่แนบมา มัดรวมแบบ multimodal เพื่อส่งบริบทให้ AI ด้วย
2. ทำให้ระบบตอบว่า "ไม่รู้" ได้
นี่เป็นหนึ่งในจุดที่ใส่ใจมากที่สุด เพื่อป้องกัน hallucination ซึ่งเป็นลักษณะเฉพาะของ LLM เราควบคุมพรอมป์ต์อย่างเข้มงวดให้ตอบว่า 'ไม่ทราบ', 'ขอระงับการตัดสิน' ในกรณีที่มีหลักฐานน่าเชื่อถือสำหรับการตรวจสอบไขว้ไม่เพียงพอ หรือเป็นเรื่องที่ยืนยันไม่ได้ แทนที่จะฝืนสรุปผล
3. เก็บ snapshot ต้นฉบับและเปิดเผยแหล่งอ้างอิงอย่างโปร่งใส
เพื่อป้องกันปัญหาที่ผู้เขียนแก้ไขข้อความภายหลัง เราจัดเก็บข้อมูลต้นฉบับ (snapshot) ณ ช่วงเวลาที่มีการขอตรวจสอบข้อเท็จจริงไว้ตามเดิม เมื่อผู้ใช้อื่นเข้ามาดูผลลัพธ์ ก็จะสามารถตรวจสอบได้อย่างโปร่งใสว่า "ระบบตรวจสอบโดยอ้างอิงข้อความ/รูปภาพใด ณ เวลาไหน" และ "อ้างอิงแหล่งข้อมูลใดบ้าง"
4. การจัดการทราฟฟิกและทรัพยากร
เพราะกระบวนการดึงบริบททั้งหมดและตรวจสอบแบบนี้ค่อนข้างหนัก จึงจำเป็นต้องมีการจัดการคิวรอของผู้ใช้ ดังนั้นเราจึงส่งคำขอทั้งหมดเข้า asynchronous queue โดยใช้ Redis Cluster + BullMQ แล้วให้ background worker ประมวลผลตามลำดับ
โดยคำนึงถึงต้นทุนและความเร็ว เราใช้ Gemini 3.5 Flash เป็นโมเดลหลัก และเมื่ออัตรา error สูงขึ้นหรือการให้เหตุผลที่ซับซ้อนล้มเหลว ก็จะใช้ Gemini 3.1 Pro เป็น fallback
(เพื่อป้องกันการใช้งานแบบไม่ยั้ง เรากำหนดข้อจำกัดให้ใช้ฟรีวันละ 1 ครั้ง และหลังจากนั้นจะหัก point ภายในแอป)
การบ้านที่ยังแก้อยู่
แม้จะวางตรรกะป้องกันไว้พอสมควรแล้ว แต่ก็ยังมีเคสยากอีกมากที่รับมือได้ลำบาก เช่น กรณีที่ช่วงเวลาอ้างอิงของสถิติต่างกัน คำพูดของนักการเมืองที่มีการเปรียบเปรยหรือเปิดช่องให้ตีความ หรือบทความยาวที่จงใจผสมข้อเท็จจริงกับเรื่องเท็จอย่างแนบเนียน ก็ยังยากที่จะจัดการได้อย่างสมบูรณ์
คุณสามารถเข้าไปทดสอบได้โดยตรงในแอป Uhheung
หากใครมีเคล็ดลับเรื่องพรอมป์ต์ที่ช่วยจับอาการหลอนของระบบได้ดีกว่าเดิมในตรรกะการตรวจสอบแบบนี้ หรือมีไอเดีย UX/UI ที่ช่วยให้ผู้ใช้ยอมรับผลลัพธ์ที่คลุมเครือได้ดีขึ้น ก็ยินดีรับคำแนะนำครับ ขอบคุณที่อ่านมาถึงตรงนี้!
Google Play: https://play.google.com/store/apps/details?id=kr.uhheung.app
App Store: https://apps.apple.com/kr/app/%EC%96%B4%ED%9D%A5/id6751951353
ยังไม่มีความคิดเห็น