สร้างผู้ช่วย Claude จากคลังความรู้: ให้กฎมีที่มา และงานมีหลักฐาน

จากไฟล์ต้นทางสู่วิกิและกฎการทำงาน พร้อมบทเรียนจากเดโมที่ให้ผู้ช่วยคาดการณ์ ทดลอง และแสดงผลก่อนบอกว่างานเสร็จ

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

ในวิดีโอ I Built Another Andrej Karpathy Using Claude ของ Nate Herk | AI Automation ผู้สาธิตนำบทความ บทบรรยาย และโพสต์ของ Andrej Karpathy มาจัดเป็นคลังความรู้สำหรับผู้ช่วยใน Claude Code จากนั้นสกัดแนวทางทำงานและทดลองกับงานเขียนโค้ด สิ่งที่น่านำมาศึกษาคือโครงสร้างความรู้และวงจรตรวจงาน ไม่ใช่การอ้างว่าผู้ช่วยกลายเป็นบุคคลต้นแบบ

เก็บต้นทางให้ย้อนตรวจได้

ขั้นแรกในเดโมคือรวบรวมเนื้อหาจากหลายช่องทาง แล้วเก็บเป็นไฟล์ต้นทาง ผู้สาธิตกล่าวถึงการดึงคำบรรยายวิดีโอด้วย YouTube Transcript API และ yt-dlp และการดึงโพสต์ผ่านบริการ API อีกตัว โดยแยกงานรวบรวมตามแหล่งข้อมูล

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

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

เปลี่ยนไฟล์ดิบเป็นวิกิ

ภาพอธิบายในคลิปแบ่งระบบออกชัดเจน: Raw files ทางซ้ายผ่าน LLM ไปสู่ Pages, Index และ Logs ทางขวา ผู้สาธิตอธิบายให้โมเดลอ่านข้อมูลแล้วสร้างหน้าความรู้ที่เชื่อมถึงกัน พร้อมดัชนีและบันทึกการเปลี่ยนแปลง

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

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

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

แปลงความรู้เป็นกฎที่ใช้ตรวจงาน

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

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

กฎที่ดีต้องเขียนเป็นพฤติกรรมที่สังเกตได้ เช่น:

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

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

คาดการณ์ รัน และแสดงผลจริง

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

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

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

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

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

อัปเดตความรู้โดยเห็นสิ่งที่เปลี่ยน

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

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

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

นำไปลองกับงานของทีม

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

1. เลือกงานหนึ่งประเภท ระบุผู้ใช้ ผลลัพธ์ และเรื่องที่ต้องส่งให้คนตัดสินใจ
2. รวบรวมแหล่งหลัก เลือกเอกสารที่ได้รับอนุญาตและยืนยันได้ว่าใช้กับงานนั้น เก็บต้นฉบับไว้
3. สร้างหน้าความรู้พร้อมที่มา แยกข้อเท็จจริง ข้อยกเว้น และสิ่งที่ยังไม่ทราบ แล้วเชื่อมดัชนีให้ค้นเจอ
4. เขียนกฎการส่งงาน ระบุว่าคำตอบต้องมีหลักฐานอะไร และเมื่อใดต้องหยุดถาม
5. ทดสอบทั้งคำถามปกติและคำถามที่ไม่มีคำตอบ ผู้ช่วยควรบอกส่วนที่ยังไม่รู้ได้ ไม่ใช่ตอบให้ครบทุกข้อด้วยการเดา
6. ตรวจซ้ำหลังเพิ่มความรู้ เก็บผลเดิมไว้เทียบ และให้คนอนุมัติการเปลี่ยนกฎสำคัญ

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