ตารางที่ไม่เคยมีอยู่

บทที่ 2 — ตารางที่ไม่เคยมีอยู่

ช่างเทคนิคจากบริษัทเครื่องกลทางตะวันออกเฉียงเหนือเล่าให้เราฟังขณะจิบเอสเปรสโซ ด้วยความใจเย็นแบบเวเนโต้ที่มักจะนำไปสู่หายนะ: "แชทบอทของเราทราบทุกอย่างเกี่ยวกับเครื่องยนต์ ยกเว้นข้อมูลของเครื่องยนต์." จากนั้นเขาก็อธิบาย ผู้ช่วย AI ภายในของพวกเขาสามารถอธิบายกลุ่มผลิตภัณฑ์ บริบทการใช้งาน ประวัติแบรนด์ ข้อได้เปรียบทางการแข่งขันได้อย่างน่าอัศจรรย์ ในแง่ของการเล่าเรื่อง แต่เมื่อลูกค้าถามแรงบิดที่กำหนดของรุ่น CMP50L ซึ่งเป็นข้อมูลทางเทคนิคที่ผู้คนเปิดแคตตาล็อก หรือตัวเลขที่ใช้ซื้อเครื่องยนต์ แชทบอทจะตอบอย่างคลุมเครือ บางครั้งก็สมเหตุสมผล บางครั้งก็ไม่ห้าเดือนของการพัฒนา ผู้จัดการฝ่ายปฏิบัติการที่สับสนมากขึ้นเรื่อยๆ และไม่มีใครรู้สาเหตุ

การวินิจฉัยเกิดขึ้นโดยบังเอิญ เกือบจะด้วยความเบื่อหน่าย ขณะที่ตรวจสอบฐานข้อมูลด้วยตนเองหลังจากการประชุมที่ไม่สิ้นสุด แคตตาล็อก PDF มีตารางทางเทคนิค 342 ตาราง แต่ในฐานข้อมูลมีเพียงศูนย์ ไม่มีแม้แต่จำนวนน้อย: ศูนย์ ไม่มีเลย โค้ดที่ดึงตารางจาก PDF จะบันทึกข้อมูลในฟิลด์ที่ชื่อ columns และ data ในขณะที่โค้ดที่ใช้จัดทำดัชนีนั้นคาดหวังฟิลด์ที่ชื่อ headers และ rows คำเหมือนที่ไม่ได้รับการเคารพ ข้อตกลงภายในที่ถูกข้ามไปในการปรับปรุงโครงสร้างที่ถูกลืม ผลลัพธ์คือเป็นเวลาห้าเดือนที่เงียบสงัด: ความฉลาดเชิงตัวเลขทั้งหมดของแคตตาล็อก — คู่ ค่ากำลัง เส้นผ่านศูนย์กลาง น้ำหนัก รหัสการสั่งซื้อ แรงดันไฟฟ้า — หลุดออกจากก๊อกน้ำโดยไม่เคยเทลงในแก้ว ตาราง 342 ตาราง หายไปทีละตารางอย่างเงียบ ๆ เหมือนพิธีกรรมทางศาสนา

นี่คือบั๊กประเภทที่ไม่ส่งเสียงร้อง ไม่ทำให้เกิดข้อยกเว้น ไม่ทำให้ระบบหยุดทำงาน และไม่ปรากฏในบันทึกใดๆ เพียงแค่ส่วนหนึ่งของโลกหายไปจากระบบของคุณ และไม่มีใครสังเกตเห็นจนกว่าผู้ใช้—โดยปกติคือผู้ใช้ที่โกรธเคือง—จะตั้งคำถามอย่างต่อเนื่องจนแสดงให้เห็นถึงช่องว่างนั้น และนี่เป็นสัญลักษณ์ของปัญหาที่ใหญ่กว่าชื่อฟิลด์มาก: เฟรมเวิร์ก RAG ทั่วไปได้รับการปรับให้เหมาะสมสำหรับข้อความต่อเนื่อง—บทความ หน้าเว็บ ย่อหน้าเรื่องราว—และปฏิบัติต่อตารางเหมือนเป็นพลเมืองชั้นสอง หากพวกเขารับการปฏิบัติเลย แต่เอกสารทางธุรกิจของอิตาลีคือตารางบ่อยครั้ง แคตตาล็อกทางเทคนิค รายการราคา ข้อกำหนดผลิตภัณฑ์ แผ่นข้อมูลความปลอดภัย ใบสั่งซื้อ: ส่วนที่มีค่าสำหรับผู้ที่ปรึกษาเอกสารเหล่านี้คือส่วนที่เป็นตาราง ซึ่งเป็นส่วนที่พังทลายเป็นอันดับแรกและไม่มีใครสังเกตเห็น

บทเรียนไม่ได้อยู่ที่ "ระวังชื่อฟิลด์" แต่เป็นเรื่องที่ยุ่งยากกว่านั้น ใน RAG ที่จริงจัง ทุกประเภทของเนื้อหา—ตาราง รูปภาพ รหัสตัวอักษรและตัวเลข หัวข้อย่อย่าง หมายเหตุ—ต้องการการจัดการที่เฉพาะเจาะจง ออกแบบ และทดสอบ และการทดสอบการทำงานไม่ใช่ "แชทบอทตอบคำถามง่ายๆ"—แม้แต่ระบบที่เสียก็สามารถตอบคำถามเหล่านั้นได้ เพราะมีข้อมูลที่ลอยตัวอยู่มากมายพอที่จะสร้างสิ่งที่น่าจะเป็นไปได้ การทดสอบที่แท้จริงคือ "แชทบอทตอบคำถามที่บังคับให้มันแตะต้องทุกส่วนของไปป์ไลน์" คำถามเฉพาะเจาะจง คำถามเชิงตัวเลขที่สามารถตรวจสอบได้ คำถามที่มีคำตอบที่ถูกต้องเพียงคำตอบเดียว และถ้าหากระบบผิดพลาด คุณจะรู้ทันที

หากคุณไม่ได้ทำการทดสอบนี้ คุณจะไม่รู้ว่า RAG ของคุณทำงานหรือไม่ คุณแค่รู้ว่ามันไม่ได้บ่น และ "ไม่ได้บ่น" เป็นเกณฑ์คุณภาพที่ต่ำมากสำหรับระบบที่ผู้คนจะใช้ในการตัดสินใจ