AI เจอข้อเท็จจริง แต่ทำเงื่อนไขที่ทำให้มันจริงหายไป
คำตอบที่ผิดแล้วน่าขัดใจ บางครั้งไม่ได้ดูเหมือน AI แต่งเรื่องเลยครับ มันอ้างตัวเลขจริง ใช้ภาษาดี และพูดอย่างมั่นใจ เพียงแต่เงื่อนไขสำคัญไม่ได้ตามมาด้วย
ลองนึกถึงคู่มือสมมติที่บอกว่าเบิกค่าแว่นได้ปีละไม่เกิน 3,000 บาท แต่เฉพาะพนักงานประจำที่ผ่านทดลองงานแล้ว พอถาม AI ว่า “ยังไม่ผ่านโปรเบิกได้ไหม?” มันกลับตอบว่าได้ เพราะค้นมาเจอแค่บรรทัดเรื่องวงเงิน
นี่ไม่ใช่นโยบายของ NEXT4I หรือองค์กรใดนะครับ เป็นตัวอย่างให้เห็นว่า ข้อความตรงเรื่องยังไม่เท่ากับหลักฐานที่ครบพอตัดสินใจ
ผมมอง Chunking ใน RAG จากตรงนี้ เราไม่ได้แค่แบ่งเอกสารเป็นชิ้นเล็กๆ แต่กำลังเลือกว่าความสัมพันธ์อะไรจะยังอยู่ เมื่อข้อมูลเดินทางจากไฟล์ไปถึงคำตอบ
เวลาอ่านคู่มือ เราไม่ได้อ่านแค่ตัวอักษร
คนอ่านใช้หัวข้อ ตารางและหมายเหตุช่วยเข้าใจโดยแทบไม่รู้ตัว หัวข้อบอกว่ากำลังพูดถึงสิทธิ์ไหน หัวคอลัมน์บอกว่าตัวเลขเป็นบาทต่อปีหรือต่อเดือน หมายเหตุบอกว่ามีข้อยกเว้นอะไร
ความหมายจึงไม่ได้อยู่ในประโยคเดียวเสมอไป มันอยู่ในความสัมพันธ์ระหว่างประโยคด้วย
RAG (Retrieval-Augmented Generation) คือแนวทางที่ระบบค้นข้อมูลมาให้โมเดลอ่านก่อนตอบ ปกติไม่ได้ยกทั้งคลังมาให้ทุกครั้ง จึงต้องมีหน่วยข้อมูลที่ค้นหาได้ เราเรียกการแบ่งเนื้อหาเป็นหน่วยเหล่านี้ว่า Chunking
แต่พอแบ่ง ความสัมพันธ์เดิมอาจตามมาหรือหลุดไปก็ได้
“ไม่เกิน 3,000 บาทต่อปี” บอกวงเงินและหน่วย แต่ไม่บอกว่าใครมีสิทธิ์ ส่วน “เฉพาะพนักงานประจำที่ผ่านทดลองงานแล้ว” บอกเงื่อนไข แต่ถ้าไม่มีหัวข้อ ก็ไม่รู้ว่ากำลังพูดถึงสวัสดิการไหน
ทั้งสองท่อนอาจคัดจากต้นฉบับอย่างถูกต้อง แต่ท่อนใดท่อนหนึ่งยังตอบทุกคำถามไม่ได้ครับ
PDF ที่ภาพสวย แต่ข้อความที่อ่านออกมาไม่สวยตาม
ผมเคยทดลอง RAG กับ PDF แนะนำการท่องเที่ยวในประเทศไทย เอกสารออกแบบมาสวยมาก ทั้งภาพ สีและการวางหน้า แต่ข้อความที่สกัดออกมากลับวุ่นวาย
สระและวรรณยุกต์ไทยไปอยู่ผิดตำแหน่ง พื้นหลังสีและลายน้ำรบกวนการอ่าน บางหน้าต้องลองขาวดำให้ตัวหนังสือชัดขึ้น แต่ก็เสี่ยงเสียบริบทจากภาพ ผมใช้หลายโมเดลช่วยเทียบผล แล้วให้คนตรวจคำผิดอีกครั้ง
ไม่ใช่ทุก PDF ต้องใช้วิธีเดียวกันนะครับ นี่เป็นประสบการณ์หนึ่งที่ทำให้ผมเริ่มระวังขั้นตอนก่อนค้นหามากขึ้น
ตอนนั้นปัญหาไม่ได้เริ่มจาก LLM ตอบผิด แต่มันอาจอ่านข้อมูลผิดตั้งแต่ยังไม่ถึงขั้นสร้างคำตอบ ถ้าคำหายไปตั้งแต่ตรงนั้น ต่อให้เปลี่ยนขนาด Chunk ก็ไม่ได้ทำให้คำนั้นกลับมาเอง
แต่ถ้าข้อความต้นทางถูก แล้วเราหั่นเงื่อนไขออกจากวงเงิน การกลับไปแก้ OCR ก็ไม่ตรงจุดเหมือนกันครับ เราต้องรู้ก่อนว่าความหมายเสียตรงไหน
หั่นเล็กลง ไม่ได้แปลว่าเข้าใจง่ายขึ้นเสมอ
ชิ้นสั้นที่พูดเรื่องเดียวอาจค้นหาได้เจาะจงกว่าหัวข้อใหญ่ที่ปนหลายเรื่อง แต่มันจะช่วยได้ถึงจุดหนึ่งเท่านั้น ถ้าสั้นจนไม่รู้ว่าพูดถึงอะไรหรือขาดข้อยกเว้น ความตรงเรื่องก็อาจไม่ได้ช่วยให้ตอบถูก
อีกด้านหนึ่ง การส่งคู่มือ 100 หน้าทั้งฉบับก็ไม่ใช่คำตอบทุกกรณี โมเดลมีขนาดข้อมูลที่รับได้ ข้อมูลไม่เกี่ยวข้องกิน Token และอาจทำให้ประเด็นที่ต้องใช้ตอบถูกกลบ
เอกสารสั้นอาจส่งทั้งฉบับได้ แต่ไม่ได้หมายความว่าทั้งคลังควรตามมาทุกครั้งที่ถาม
คำถามที่ผมอยากใช้แทน “หั่นเล็กแค่ไหนดี?” คือ “อะไรต้องอยู่ด้วยกัน เพื่อให้คำถามนี้ตอบได้?”
ถามเรื่องวงเงินอาจใช้ข้อมูลไม่มาก ถามเรื่องสิทธิ์ต้องมีเงื่อนไข และถามเปรียบเทียบข้อกำหนดหลายข้ออาจต้องได้หลักฐานจากหลายส่วน ทั้งหมดไม่ได้ใช้ขนาดบริบทเดียวกันเพียงเพราะอยู่ในไฟล์เดียวกัน
สิ่งที่ใช้ค้นหา กับสิ่งที่ใช้ทำความเข้าใจ อาจไม่ใช่ชิ้นเดียวกัน
เราสามารถค้นจากย่อหน้าสั้นๆ ก่อน แล้วขยายไปอ่านหัวข้อใหญ่ที่ย่อหน้านั้นอยู่ได้ แนวทาง Parent-child ทำหน้าที่แบบนี้: Child ช่วยชี้ตำแหน่ง ส่วน Parent ช่วยให้บริบทครบ
แต่มันไม่ได้แปลว่าให้ดึงทุกอย่างรอบๆ มา ต้องคุมขนาดและลิงก์ต้นทางให้ถูก และถ้าเป็นข้อมูลองค์กร ส่วนที่เพิ่มเข้ามาต้องผ่านการตรวจสิทธิ์ก่อนโมเดลเห็นด้วย
อีกวิธีคือเติมชื่อเอกสาร หัวข้อ หรือคำอธิบายสั้นๆ ให้ชิ้นที่กำกวมก่อนทำดัชนีค้นหา บริบทเหล่านี้ช่วยบอกว่าท่อนที่เจอเป็นเรื่องอะไร
ถ้าใช้ AI เขียนคำอธิบายเพิ่ม ก็ต้องระวังว่ามันอาจเติมเงื่อนไขที่ต้นฉบับไม่มี คำอธิบายเพื่อช่วยค้นไม่ใช่หลักฐานแทนข้อความจริง เราต้องเก็บต้นฉบับไว้ให้อ้างอิงและตรวจซ้ำได้เสมอ
วิธีที่ซับซ้อนควรแก้ปัญหาที่เราพบจริง
มีหลายวิธีแบ่งข้อมูล แต่ผมไม่อยากเลือกจากชื่อที่ดูฉลาดที่สุดครับ
ตัดตามขนาดทำง่ายแต่เสี่ยงผ่าประโยค วิธีที่ลองแบ่งตามย่อหน้าหรือประโยคก่อนช่วยรักษาขอบเขต แต่ไม่ได้เข้าใจความหมายเอง วิธีตามโครงสร้างใช้หัวข้อและตารางที่มีอยู่ ส่วนวิธีให้โมเดลช่วยดูการเปลี่ยนประเด็นก็เพิ่มต้นทุนและขึ้นกับคุณภาพข้อมูล
ถ้าคู่มือมีหัวข้อชัดอยู่แล้ว ผมจะลองใช้ก่อน ไม่ต้องให้โมเดลเดาสิ่งที่ผู้เขียนจัดมาแล้ว หัวข้อที่ยาวเกินยังแบ่งย่อยได้ โดยพาชื่อหัวข้อและแหล่งอ้างอิงไปด้วย
Overlap หรือการให้ข้อความตรงรอยต่อทับซ้อนกัน ช่วยบางกรณี แต่ไม่คืนข้อความที่อ่านผิด ไม่รับประกันว่าจะพาเงื่อนไขที่ห่างหลายหน้ามาด้วย และถ้าซ้ำมากไปก็อาจแย่งพื้นที่หลักฐานส่วนอื่น
ช่วง 300-500 Tokens และ Overlap 10-20% เป็นค่าตั้งต้นสำหรับลองกับข้อความมีย่อหน้า ไม่ใช่ผลทดลองหรือค่ามาตรฐาน เอกสาร คำถาม Tokenizer และงบบริบทยังเป็นตัวกำหนดว่าควรใช้เท่าไร
สำหรับผม ขั้นตอนที่เพิ่มควรมีเหตุผลจากปัญหาที่ตรวจพบ ไม่ใช่เพิ่มเพราะรู้สึกว่าใช้ AI มากขึ้นแล้วน่าจะดีขึ้น
คำตอบลื่นหู เป็นสิ่งที่ต้องตรวจหลังหลักฐาน
ประโยคที่อ่านแล้วดูดีบอกว่าโมเดลเรียบเรียงเก่ง แต่ยังไม่บอกว่ามันได้อ่านเงื่อนไขครบ
ผมจะแยกตรวจสามเรื่อง:
- ระบบค้นอะไรมา: เจอข้อความที่เป็นหลักฐานจริงหรือไม่?
- โมเดลได้อ่านอะไร: มีเงื่อนไข ข้อยกเว้น หน่วยตัวเลขและ Version ที่ต้องใช้ครบไหม?
- คำตอบสรุปอะไร: ตรงกับหลักฐานไหม และแหล่งอ้างอิงรองรับข้อความที่ตอบจริงหรือเปล่า?
คำถามจริงช่วยให้เห็นรอยรั่วได้ดี ลองถามทั้งวงเงิน กรณีที่ไม่มีสิทธิ์ และเรื่องที่เอกสารไม่ได้บอก ระบบควรยอมรับว่าหลักฐานไม่พอ ไม่ใช่หยิบประโยคใกล้เคียงมาทำให้ดูเหมือนมีคำตอบ
Prompt อาจช่วยให้โมเดลระวังการเดา แต่ทำให้ประโยคที่ไม่ได้ส่งมากลับมาไม่ได้ครับ
รักษาเหตุผลที่ทำให้ข้อเท็จจริงนั้นใช้ได้
ผมมอง Chunking เป็นส่วนหนึ่งของการออกแบบหลักฐาน ต้องเริ่มจากข้อความที่ถูก รักษาความสัมพันธ์ที่จำเป็น เก็บทางกลับไปตรวจต้นฉบับ และทดสอบว่าข้อมูลที่ตรงเรื่องครบพอตอบจริงหรือไม่
ไม่มีวิธีหั่นใดรับประกันคำตอบ แม้ Markdown ทำให้โครงสร้างชัดขึ้น ก็ไม่ได้ทำให้ AI เข้าใจหรืออ้างอิงถูกเองทุกครั้ง
ข้อมูลอ่านผิดหั่นดีก็ไม่ช่วย อ่านถูกแต่เงื่อนไขหลุดก็ตอบผิดได้แหล่ะครับ สิ่งที่ควรตามไปกับข้อเท็จจริงคือเงื่อนไขที่ทำให้มันใช้ได้ ไม่ใช่แค่ประโยคที่ดูเกี่ยวข้อง
ถ้าคุณใช้ AI ตอบจากเอกสาร ลองเล่าว่าคุณตรวจอย่างไรว่าบริบทที่ส่งไปยังรักษาเงื่อนไขสำคัญไว้ครบครับ
โฆษณา
- ดาวน์โหลดแอปพลิเคชัน
- © 2026 Blockdit
