บทที่ 30: เมื่อมีเอกสารเยอะ ปัญหาคือหาไม่เจอ ไม่ใช่ไม่มีความรู้

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

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

นี่เป็นผลงานเล็กมาก แต่ช่วยเปลี่ยนคำขอแบบ “ช่วยหาข้อมูลเก่าให้หน่อย” ให้เป็นงานที่คนและ AI ทำต่อได้โดยไม่ต้องเดา

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

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

ผู้จัดการจำได้ว่าทีมเคยตกลงเรื่องนี้แล้ว เขาค้นคำว่า “กล่องบุบ” ในแชต พบข้อความเมื่อหกเดือนก่อน พนักงานอีกคนค้นคำว่า “สินค้าเสียหาย” ในคู่มือ พบเงื่อนไขอีกแบบ ส่วนไฟล์ชื่อ return-policy-final.pdf และ return-policy-final-v2.pdf ต่างก็เขียนว่า “ฉบับล่าสุด”

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

สิ่งที่ทีมต้องการคือ “แฟ้มหลักฐานขนาดเล็ก” ซึ่งมี

• คำถามที่ค้น
• รายการเอกสารที่พบ
• วันที่และสถานะของแต่ละเอกสาร
• ข้อความที่เกี่ยวข้อง
• สิ่งที่ยังขัดกัน
• คนที่ต้องยืนยันคำตอบ

ทันทีที่ได้แฟ้มนี้ ผู้จัดการจึงตอบลูกค้าได้โดยรู้ว่าคำตอบมาจากไหน และรู้ด้วยว่าจุดใดควรแก้นโยบายเพื่อไม่ให้ทีมสับสนซ้ำ

ต้นทุนที่มองไม่เห็นของการหาไม่เจอ

เอกสารที่หาไม่เจอไม่ได้เงียบเฉย มันสร้างงานเพิ่มทุกวัน

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

ความขัดแย้งสำคัญอยู่ตรงนี้:

ยิ่งธุรกิจบันทึกมาก แต่ไม่มีระบบค้นและที่มา ทีมอาจยิ่งมั่นใจผิดได้ง่ายขึ้น

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

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

ให้นึกว่าเอกสารทุกชิ้นเป็นหนังสือในห้องสมุด

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

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

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

• คลังความรู้ (knowledge base): พื้นที่รวมเอกสารและข้อมูลที่ถูกจัดให้ค้นหรืออ่านต่อได้
• ดัชนี (index): รายการช่วยชี้ว่าเอกสารใดพูดถึงอะไร โดยไม่ต้องเปิดทุกไฟล์ทีละชิ้น
• คำค้น (query): ถ้อยคำหรือคำถามที่เราใช้ขอให้ระบบหาเอกสาร
• ผลค้น (search result): รายการเบาะแสที่ระบบเห็นว่าเกี่ยวข้อง ยังไม่ใช่คำตอบสุดท้าย
• แหล่งที่มา (source): เอกสาร เหตุการณ์ หรือหลักฐานต้นทางที่ใช้รองรับข้อสรุป

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

การทำให้ความรู้ “หาเจอ” ต้องมีอย่างน้อยสี่ชั้น

ชั้นที่ 1: รู้ว่ามีอะไรอยู่บ้าง

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

ชั้นที่ 2: จำกัดขอบเขตให้ชัด

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

ชั้นที่ 3: เปิดต้นฉบับ ไม่หยุดที่ตัวอย่างผลค้น

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

ชั้นที่ 4: บอกสิ่งที่ยังหาไม่พบ

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

ผลงานประจำบท: ใบค้นหาหนึ่งหน้า

ใช้แม่แบบนี้ก่อนเริ่มค้นจริง

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

พื้นผิวปัจจุบันของ Arra ที่เกี่ยวข้อง

สำหรับภาพรวมในบทนี้ ให้รู้จักเพียงห้าหน้าที่

• oracle_list ช่วยดูรายการเอกสารโดยยังไม่ต้องมีคำค้น
• oracle_concepts ช่วยดูว่าคลังมีหัวข้อใดอยู่บ้าง
• oracle_search ช่วยหาเอกสารที่เกี่ยวข้อง
• oracle_read ช่วยเปิดอ่านเอกสารเต็มจากผลค้น
• oracle_stats ช่วยดูจำนวนเอกสารและสถานะของดัชนีหรือระบบค้นความหมาย

ชื่อเหล่านี้เป็นชื่อเครื่องมือ MCP ในชุดซอร์สที่หนังสือใช้ตรวจข้อเท็จจริง ชื่อเก่าที่อาจพบในบทความรุ่นก่อนยังมีไว้เพื่อความเข้ากันได้บางส่วน แต่หนังสือใหม่ไม่ใช้เป็นเส้นทางหลัก

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

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

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

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

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

ตัวอย่างนี้อธิบายเส้นทางงาน ไม่ได้ยืนยันว่าสถานะการทำงานจริงของทุก House พร้อมอยู่เสมอ และไม่ใช้ชื่อหน้าต่างหรือพาธจริงของระบบ

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

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

ถ้าคำตอบคือ “ต้องถามฉัน” ปัญหาแรกอาจอยู่ที่ความรู้ยังไม่มีทางเข้าที่คนอื่นใช้ได้ การเพิ่ม AI จึงยังไม่ช่วย

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

ภารกิจของบทนี้คือสร้างใบค้นหาจากกรณีจำลองต่อไปนี้:

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

เขียนให้ครบแปดช่องตามแม่แบบด้านบน โดยยังไม่ต้องค้นอินเทอร์เน็ตหรือระบบจริง

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

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

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

• ได้ใบค้นหาหนึ่งหน้าที่คนอื่นอ่านแล้วตั้งคำค้นต่อได้
• มีช่อง “สิ่งที่ไม่ให้เดา” อย่างน้อยหนึ่งข้อ
• มีเกณฑ์ชัดว่าต้องพบอะไรจึงจะตอบได้

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

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

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

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

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

• การมีดัชนีไม่ได้รับประกันว่าเอกสารทุกชิ้นถูกทำดัชนีครบ
• ผลค้นอันดับแรกไม่ได้แปลว่าเป็นฉบับล่าสุด
• จำนวนผลค้นมากไม่ได้แปลว่าคำตอบมั่นคงกว่า
• การค้นแบบอ่านอย่างเดียวยังอาจทำให้ข้อมูลลับปรากฏบนหน้าจอ จึงต้องกำหนดขอบเขตและปิดบังข้อมูลก่อนนำไปสอนหรือแชร์
• oracle_verify ซึ่งจะพบในบทถัด ๆ ไปอาจเปลี่ยนข้อมูลได้ การทำงานปริยาย/check=false อยู่ฝั่งเขียนและอาจทำเครื่องหมายรายการกำพร้าในดัชนี มีเพียงการระบุ check=true อย่างชัดเจนที่ใช้เป็นการตรวจแบบอ่านอย่างเดียว และยังไม่ได้รับรองความจริงทางธุรกิจของเนื้อหา

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

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

คำถามชวนคิด

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

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

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