บทที่ 32: ถามคลังความรู้โดยไม่บังคับให้มันเดา

ผลลัพธ์ของบทนี้

เมื่อจบบทนี้ คุณจะมีแม่แบบ “คำถามที่มีขอบหลักฐาน” และชุดคำตอบสี่ส่วน ได้แก่ ข้อสรุปที่รองรับ หลักฐานที่ใช้ ความขัดแย้ง และสิ่งที่ยังไม่รู้

เป้าหมายคือทำให้คนอ่านรู้ว่าแต่ละประโยคยืนอยู่บนอะไร ความฉลาดของถ้อยคำเป็นเรื่องรอง

สถานการณ์ใกล้ตัว

ผู้บริหารถามว่า “ปีนี้ลูกค้ากลุ่มสมาชิกชอบรับสินค้าวันไหนมากที่สุด”

ในคลังมีบันทึกจากทีมบริการลูกค้าสามฉบับ รายงานส่งของหนึ่งเดือน และบทเรียนเก่าที่เขียนว่า “ลูกค้าหลายคนสะดวกวันเสาร์” แต่ไม่มีชุดข้อมูลทั้งปี ไม่มีนิยามคำว่า “สมาชิก” และไม่รู้ว่ารายงานหนึ่งเดือนเป็นช่วงเทศกาลหรือไม่

ถ้าคำถามถูกเขียนว่า “บอกวันที่ลูกค้าชอบมากที่สุด” ระบบถูกผลักให้เลือกคำตอบหนึ่ง แม้หลักฐานไม่พอ

ถ้าเปลี่ยนเป็น

“ค้นหลักฐานในคลังช่วงเวลาจำลองนี้ว่าเอกสารใดกล่าวถึงวันที่สมาชิกสะดวกรับสินค้า สรุปเฉพาะสิ่งที่เอกสารรองรับ แยกความเห็นออกจากข้อมูล และถ้ายังตอบคำว่า ‘มากที่สุด’ ไม่ได้ ให้บอกข้อมูลที่ขาด”

ผลลัพธ์ที่ดีอาจตอบว่า “พบข้อสังเกตเรื่องวันเสาร์สองแหล่ง และหลักฐานยังไม่พอให้สรุปว่านิยมมากที่สุดทั้งปี” คำตอบนี้สั้นกว่า ปลอดภัยกว่า และบอกขั้นต่อไปได้

ต้นทุนของคำตอบที่ดูครบเกินหลักฐาน

AI มักถูกให้รางวัลทางอ้อมเมื่อทำประโยคให้ลื่นและจบ ผู้ใช้เองก็รู้สึกสบายใจกับคำตอบที่ชัดเจน แต่ความลื่นไม่ใช่หลักฐาน และความแน่นอนทางภาษาไม่ใช่ความแน่นอนของข้อมูล

ในธุรกิจ คำตอบที่เกินหลักฐานอาจนำไปสู่การจัดคนผิดวัน สั่งสต็อกผิดจำนวน หรือเปลี่ยนนโยบายจากตัวอย่างที่ไม่เป็นตัวแทน ต้นทุนเริ่มตั้งแต่ไม่มีใครเห็นว่าคำตอบนั้นยังไม่เคยถูกพิสูจน์ และอาจจบด้วยคำตอบที่ผิด

ภาพเปรียบเทียบ

ให้นึกว่าคำถามเป็นกรอบรูป หากกรอบเล็กและระบุขอบชัด เราจะเห็นว่าอะไรอยู่ในภาพและอะไรอยู่นอกภาพ แต่ถ้าขอให้ช่างภาพเติมพื้นที่ว่างให้เต็ม เขาอาจวาดฉากที่ไม่เคยอยู่ตรงนั้น

ขอบหลักฐานไม่ได้ทำให้ระบบรู้น้อยลง มันทำให้เส้นแบ่งระหว่าง “พบ” กับ “คาด” มองเห็นได้

ขอบเขตตามตัวอักษร: ระบบทำงานกับข้อมูลและไม่ได้มองผ่านกล้องหรือวาดภาพจริง กรอบรูปช่วยเตือนให้เราระบุขอบเขตคำถาม สิ่งที่อยู่นอกกรอบยังอาจมีอยู่ แม้หลักฐานชุดนี้ยังไม่รองรับ

ศัพท์ใหม่ในบทนี้

• ขอบหลักฐาน (evidence boundary): ขอบเขตว่าคำตอบอนุญาตให้ใช้ข้อมูลใดและช่วงเวลาใด
• ข้อกล่าวอ้าง (claim): ประโยคที่ต้องมีหลักฐานรองรับ
• ความไม่แน่นอน (uncertainty): ระดับที่ข้อมูลยังไม่พอ ขัดกัน หรืออาจเปลี่ยน
• หลักฐานตรง: ข้อมูลที่ตอบประเด็นนั้นโดยตรง
• หลักฐานแวดล้อม: ข้อมูลที่ช่วยอธิบาย แต่ยังพิสูจน์ข้อสรุปไม่ได้เอง

แก่นของเรื่อง

คำถามที่ไม่บังคับให้เดามีองค์ประกอบหกข้อ

1. ระบุงานที่จะนำคำตอบไปใช้

“เพื่อจัดตารางพนักงานทดลองหนึ่งสัปดาห์” ต่างจาก “เพื่อเปลี่ยนนโยบายทั้งปี” งานที่มีผลกว้างต้องการหลักฐานมากกว่า

2. ระบุแหล่งและช่วงเวลา

บอกให้ค้นเฉพาะเอกสารประเภทใด โครงการใด และช่วงเวลาใด ถ้าไม่กำหนด ระบบอาจนำบทเรียนเก่ามาปนกับนโยบายใหม่

3. ขอให้เปิดต้นฉบับ

ใช้ oracle_search เพื่อหาผู้สมัคร แล้วใช้ oracle_read เพื่ออ่านเนื้อหาเต็ม หลักสำคัญคืออย่าตอบจาก snippet หรือชื่อไฟล์เพียงอย่างเดียว

4. ขอให้แยกข้อเท็จจริง การตีความ และคำถามค้าง

ตัวอย่าง:

• ข้อเท็จจริง: รายงานจำลองเดือนมิถุนายนมีการส่งวันเสาร์ 42 ครั้ง
• การตีความ: วันเสาร์อาจเป็นวันที่สะดวกสำหรับบางกลุ่ม
• ยังไม่รู้: ทั้งปีวันใดสูงที่สุด และคำว่า “สมาชิก” ถูกใช้สม่ำเสมอหรือไม่

5. อนุญาตให้ตอบว่าไม่พบ

เขียนตรง ๆ ว่า “หากไม่มีหลักฐานพอ ห้ามเติมคำตอบ ให้ระบุสิ่งที่ค้นแล้วและข้อมูลที่ต้องหาเพิ่ม” ประโยคนี้ลดแรงกดดันให้สร้างข้อสรุปปลอม

6. กำหนดคนรับผิดชอบการตัดสินใจ

คลังความรู้ช่วยแสดงสิ่งที่เคยถูกบันทึก ผู้จัดการยังต้องตรวจว่าข้อมูลเป็นปัจจุบันและเหมาะกับการตัดสินใจครั้งนี้

ผลงานประจำบท: ชุดคำตอบสี่ส่วน

ใช้โครงนี้กับทุกคำถามที่มีผลต่อธุรกิจ

A. คำตอบสั้นที่มีขอบ

จากเอกสารจำลองสามฉบับ พบว่าวันเสาร์ถูกกล่าวถึงซ้ำ แต่หลักฐานยังไม่ครอบคลุมทั้งปี จึงยังสรุปคำว่า “มากที่สุด” ไม่ได้

B. ตารางหลักฐาน

C. ความขัดแย้งหรือช่องว่าง

• เอกสารใช้คำว่า “สมาชิก” ไม่เหมือนกัน
• ไม่มีข้อมูลวันอาทิตย์ในรายงานหนึ่งฉบับ
• ยังไม่พบผู้อนุมัติ learning เก่า

D. ขั้นต่อไปที่ไม่ข้ามอำนาจมนุษย์

ให้เจ้าของข้อมูลยืนยันนิยามสมาชิก และรวบรวมข้อมูลครบสามเดือนก่อนใช้ปรับตารางถาวร

พื้นผิวปัจจุบันและขอบเขตของสิ่งที่ตรวจได้

• oracle_search ช่วยหาเอกสารผู้สมัครตามคำค้น ประเภท โครงการ หรือโหมดค้น
• oracle_read ช่วยเปิดเอกสารเต็ม
• oracle_list และ oracle_concepts ช่วยตรวจว่าคลังมีอะไรและครอบคลุมหัวข้อใด
• oracle_stats ช่วยดูสถานะดัชนีและระบบ vector
• oracle_verify ช่วยตรวจความสอดคล้องระหว่างไฟล์บนดิสก์กับดัชนี แต่ต้องกำหนด check=true อย่างชัดเจนจึงอยู่ในขอบเขตอ่านอย่างเดียว การทำงานปริยาย/check=false อาจเขียนเครื่องหมายกำกับรายการกำพร้าลงดัชนี

ข้อสุดท้ายสำคัญมาก: การ verify ว่าไฟล์ไม่ตกจากดัชนี ไม่ได้ verify ว่าเนื้อหาในไฟล์เป็นความจริง เช่นเดียวกับการตรวจว่าสมุดบัญชีมีครบทุกหน้า ไม่ได้แปลว่าตัวเลขทุกช่องถูก

บัตรความเสี่ยงของ oracle_verify: ในบทเรียนนี้ห้ามเรียกโดยไม่ระบุค่า ห้ามใช้ check=false และห้ามถือชื่อคำว่า verify ว่าปลอดภัยเอง หากผู้ดูแลไม่ได้ยืนยัน check=true และสภาพแวดล้อมทดลอง ให้ตัดเครื่องมือนี้ออกจากแบบฝึกทันที

ตัวอย่างจำลองตามกระบวนการ Oracle V4

เส้นทางครบ: มนุษย์ส่งเรื่องให้ Earth AI แล้ว Earth AI ส่งต่อให้ Jan เลือก House เมื่อ House ทำงานเสร็จ รายงานจะกลับผ่าน Jan และ Earth AI จนถึงมนุษย์

เจ้าของธุรกิจขอ “ข้อเสนอทดลองตารางรับสินค้า” Earth AI ทำรายละเอียดงานที่ระบุว่าเป็นการทดลอง ไม่ใช่นโยบายถาวร Jan ส่งให้ House ที่เหมาะสมค้นคลังและทำชุดคำตอบสี่ส่วน

House พบหลักฐานจำลองสามชิ้นและช่องว่างสองข้อ จึงส่งรายงานเป็นไฟล์กลับ Jan โดยติดป้ายว่า “หลักฐานไม่พอสำหรับการเปลี่ยนนโยบาย” Jan ส่งรายงานผ่าน Earth AI กลับให้เจ้าของ เจ้าของจึงเลือกทำการทดลองขนาดเล็กและตั้งวันทบทวน แทนการให้ AI ตัดสินจากข้อสังเกตครั้งเดียว

นี่คือการใช้ AI เพื่อทำให้ความไม่แน่นอนมองเห็น ไม่ใช่ซ่อนมันไว้ใต้ภาษาที่มั่นใจ

หยุดแล้วมองอีกครั้ง

เปิดรายงานล่าสุดของคุณในใจ แล้วลองเติมคำว่า “จากหลักฐานใด” หลังทุกประโยคสำคัญ ประโยคใดตอบได้ทันที ประโยคใดตอบว่า “จากประสบการณ์” และประโยคใดไม่รู้ที่มาเลย

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

ลองทำอย่างปลอดภัย

ใช้หลักฐานสังเคราะห์สามใบ:

• เอกสาร A: “ลูกค้าจำลอง 8 จาก 20 รายเลือกส่งวันเสาร์ในเดือนหนึ่ง”
• เอกสาร B: “พนักงานสองคนสังเกตว่าลูกค้าวัยทำงานมักถามหาวันหยุด”
• เอกสาร C: “ตารางอีกเดือนหนึ่งไม่มีข้อมูลวันรับสินค้า 30%”

ตอบคำถามว่า “วันเสาร์คือวันที่ลูกค้าชอบที่สุดหรือไม่” ด้วยโครงสี่ส่วน ห้ามเพิ่มตัวเลขหรือเหตุผลที่ไม่มีในสามใบ

ก่อนเริ่ม (preflight)

• ตรวจว่าทุกชื่อ ตัวเลข และช่วงเวลาเป็นข้อมูลแต่งขึ้น
• เขียนวัตถุประสงค์ว่า “ฝึกแยกหลักฐาน” ไม่ใช่ใช้ตัดสินใจจริง
• กำหนดว่าคำตอบ “ยังสรุปไม่ได้” ถือเป็นผลลัพธ์ที่ยอมรับได้

ผลที่คาดหวัง (expected result)

• มีคำตอบสั้นหนึ่งย่อหน้า
• มีตารางแหล่ง-สิ่งที่รองรับ-ข้อจำกัด
• มีอย่างน้อยสองสิ่งที่ยังไม่รู้
• ไม่มีประโยคใดอ้างว่าตัวอย่าง 20 รายแทนลูกค้าทั้งหมด

หยุดและถามคนเมื่อ… (stop condition)

• หยุดเมื่อเริ่มค้นข้อมูลจริงเพื่อทำให้คำตอบ “ดูครบ”
• หยุดเมื่อจะนำผลจำลองไปตั้งตารางพนักงานหรือส่งให้ลูกค้า
• หยุดหากระบบแสดงไฟล์หรือข้อมูลที่อยู่นอกขอบเขตที่ได้รับอนุญาต

วิธีกู้คืน (recovery)

• ลบประโยคที่ไม่มีแหล่งรองรับ
• เปลี่ยนคำว่า “คือ” เป็น “อาจ” เฉพาะเมื่อมีหลักฐานแวดล้อม และอธิบายข้อจำกัด
• ถ้าข้อมูลไม่พอ ให้จบด้วยคำถามเก็บข้อมูลรอบถัดไป

ระวังความเข้าใจผิด

• การใส่อ้างอิงไม่ได้รับประกันว่าอ้างอิงนั้นเกี่ยวข้องหรือยังเป็นปัจจุบัน
• การมีหลายเอกสารกล่าวซ้ำไม่เท่ากับเอกสารเหล่านั้นเป็นอิสระจากกัน อาจคัดลอกมาจากต้นทางเดียว
• “ไม่พบในคลัง” ไม่เท่ากับ “ไม่มีอยู่จริง” อาจยังไม่ถูกนำเข้า หรือดัชนีอาจไม่ครบ
• ข้อสรุปจากข้อมูลภายในไม่ควรถูกเผยแพร่ภายนอกโดยอัตโนมัติ
• งานกฎหมาย การแพทย์ การเงิน หรือเรื่องที่กระทบสิทธิ์บุคคลต้องมีผู้เชี่ยวชาญและคนรับผิดชอบตรวจ ไม่ใช้เพียงผลค้นจากคลัง

สามเรื่องที่ควรจำ

1. ถามให้ระบบแสดงหลักฐาน ความขัดแย้ง และสิ่งที่ยังไม่รู้
2. ค้นก่อน แล้วเปิดอ่านต้นฉบับก่อนสรุป
3. ตรวจดัชนีครบ ไม่ได้แปลว่าเนื้อหาจริง คนยังต้องตัดสินใจ

คำถามชวนคิด

คำถามใดในธุรกิจของคุณมักถูกถามในรูปที่บังคับให้เลือก “ใช่หรือไม่” ทั้งที่หลักฐานจริงควรตอบเป็นระดับหรือเงื่อนไข

สะพานไปบทถัดไป

เมื่อเราพบข้อสรุปที่มีประโยชน์ ความอยากตามธรรมชาติคือ “เก็บไว้เลย” แต่การเก็บความรู้ผิดหรือไม่มีที่มาอาจทำให้ความผิดนั้นถูกค้นซ้ำได้ง่ายขึ้น บทต่อไปจึงเริ่มที่ประตูเขียนข้อมูล