ทำไมคำตอบที่ดูมั่นใจถึงอาจแย่ยิ่งกว่าการไม่มีคำตอบเลย
คุณสร้างแชทบอทภายในองค์กรเสร็จสิ้น คุณป้อนนโยบาย HR, ข้อกำหนดทางวิศวกรรม และเอกสารการเริ่มงาน (onboarding) ทั้งหมดที่บริษัทมีให้มัน พนักงานใหม่คนหนึ่งถามเกี่ยวกับวงเงินค่าใช้จ่ายในการเดินทางสำหรับการเลี้ยงรับรองลูกค้า บอทตอบกลับทันที มันฟังดูมั่นใจมาก วงเงินที่มันระบุคือ 75 ดอลลาร์ต่อคน
แต่นโยบายจริงระบุไว้ที่ 50 ดอลลาร์ บอทกุเรื่องขึ้นมาเอง มันไม่ได้เปิดไฟล์ของคุณเลย มันแค่เดาโดยอาศัยรูปแบบที่ฝังอยู่ในข้อมูลที่ใช้ฝึกฝน (training data) เมื่อหลายปีก่อน นี่คือความจริงอันโหดร้ายของการใช้โมเดลภาษาขนาดใหญ่ (LLM) แบบดิบๆ กับเอกสารส่วนตัว เนื่องจากพวกมันไม่สามารถเข้าถึงความรู้ภายในของคุณได้ เมื่อข้อเท็จจริงที่ต้องการอยู่นอกเหนือจากค่าน้ำหนัก (weights) ที่ใช้ฝึกฝน พวกมันจะสร้างเรื่องขึ้นมาแทนที่จะยอมรับว่าไม่รู้ ในสภาพแวดล้อมการใช้งานจริง (production) เรื่องนี้จะไม่ใช่เรื่องตลกอีกต่อไป แต่จะกลายเป็นความเสี่ยง (liability)
Retrieval-Augmented Generation หรือ RAG ถูกสร้างขึ้นมาเพื่อแก้ปัญหานี้โดยเฉพาะ แทนที่จะสั่งให้โมเดลจดจำทุกอย่าง คุณเปลี่ยนเป็นการอนุญาตให้มัน "ค้นหา" ข้อมูลแทน
จากการเดา สู่การอ่าน
ลองนึกภาพว่า LLM แบบดิบๆ คือเพื่อนร่วมงานที่ชาญฉลาดและมีความจำแบบภาพถ่าย (photographic memory) แต่เป็นคนที่ลาออกจากบริษัทไปก่อนที่คุณจะเข้ามา พวกเขาสามารถเขียนร้อยแก้วที่สละสลวย แก้โจทย์ตรรกะ และอธิบายแนวคิดต่างๆ ด้วยภาษาง่ายๆ แต่ถ้าคุณถามเกี่ยวกับความเปลี่ยนแปลงของ API ในไตรมาสที่แล้ว พวกเขาจะแค่กุเรื่องที่ฟังดูสมเหตุสมผลขึ้นมา เพราะพวกเขาไม่มีทางเลือกอื่น
RAG ช่วยให้เพื่อนร่วมงานคนนั้นเข้าถึงตู้เก็บเอกสารได้ เมื่อผู้ใช้ถามคำถาม ระบบจะไม่โยนคำถามใส่โมเดลแบบสุ่มสี่สุ่มห้า แต่จะทำการดึงเอกสารที่เกี่ยวข้องออกมาก่อน แล้วใส่เข้าไปใน prompt เพื่อใช้เป็นบริบท (context) จากนั้นจึงค่อยให้โมเดลอ่านและตอบคำถาม โมเดลจะเปลี่ยนจากการ "พยายามนึก" ข้อเท็จจริง มาเป็นการ "ทำความเข้าใจ" ข้อเท็จจริงที่วางอยู่ตรงหน้ามันจริงๆ
กระบวนการนี้แบ่งออกเป็นสองส่วนอย่างชัดเจน คือ การเตรียมการแบบออฟไลน์ (offline groundwork) และการตอบสนองแบบออนไลน์ (online response)
เฟส 1: ขั้นตอนการเตรียมการ (Offline)
นานก่อนที่ใครจะพิมพ์คำถาม คุณต้องเปลี่ยนคอลเลกชันเอกสารที่กระจัดกระจายให้กลายเป็นฐานความรู้ที่ค้นหาได้ การเตรียมการขั้นพื้นฐานนี้จะเป็นตัวตัดสินว่าระบบ RAG ของคุณจะรุ่งหรือจะร่วงอย่างเงียบๆ
Document loaders คือจุดเริ่มต้นของคุณ ตัวเชื่อมต่อเหล่านี้จะดึงข้อความดิบจาก PDF, พื้นที่ทำงานใน Notion, โฟลเดอร์ SharePoint, หน้าเว็บ และวิกิภายในองค์กร นี่คือจุดที่ความจริงเริ่มปรากฏ ตัวโหลดอาจดึงข้อความที่สะอาดจากเอกสาร Word ได้ แต่กลับไปติดขัดเมื่อเจอ PDF ที่สแกนมาซึ่งเป็นเพียงรูปภาพที่ไม่มีเลเยอร์ข้อความฝังอยู่ ตัวโหลดจะคืนค่าเป็นค่าว่าง (empty string) ฐานข้อมูลของคุณก็ไม่มีอะไรเก็บไว้ และในภายหลังผู้ใช้ก็จะได้รับคำตอบว่า "ฉันไม่รู้" โดยไม่มีการแจ้งเตือนล่วงหน้า ดังนั้นควรตรวจสอบเสมอว่าตัวโหลดของคุณดึงข้อมูลอะไรออกมาได้จริง ให้ลองสุ่มตรวจเอกสารจำนวนหนึ่งจากแต่ละแหล่งข้อมูลก่อนที่คุณจะเชื่อใจระบบ (pipeline) นี้
ขั้นตอนต่อมาคือ text splitting หรือที่เรียกว่าการทำ chunking คุณไม่สามารถป้อนนโยบายความปลอดภัยความยาว 80 หน้าเข้าไปใน prompt ทีเดียวได้ เพราะจะเกินขีดจำกัดของบริบท (context limits) และทำให้ข้อมูลสำคัญถูกกลบด้วยสัญญาณรบกวน (noise) แทนที่จะทำแบบนั้น คุณต้องตัดเอกสารออกเป็นส่วนๆ (chunks) เคล็ดลับคือการเลือกขนาดที่เหมาะสม Chunk ที่เล็กเกินไป เช่น มีแค่ประโยคเดียว มักจะทำให้บริบทสำคัญหายไป เช่น Chunk ที่อ่านว่า "คำขอทั้งหมดต้องได้รับการอนุมัติจากผู้จัดการ" อาจลืมระบุว่ากฎนี้ใช้กับการเดินทางระหว่างประเทศเท่านั้น ในขณะที่ Chunk ที่ใหญ่เกินไป เช่น ทั้งบท จะทำให้ค่า embedding เจือจางและทำให้การค้นหา (retrieval) สับสน เพราะมันครอบคลุมถึง 15 หัวข้อพร้อมกัน ในทางปฏิบัติ หลายทีมมักจะเริ่มด้วย chunk ขนาดระหว่าง 300 ถึง 500 tokens โดยมีส่วนที่ซ้อนทับกัน (overlap) 50 tokens เพื่อไม่ให้ประโยคที่คาบเกี่ยวกันถูกตัดขาดจนเสียความหมาย คุณสามารถปรับแต่งสิ่งนี้ตามเนื้อหาของคุณได้ เอกสาร API มักจะใช้ chunk ขนาดเล็กได้ แต่สัญญาทางกฎหมายมักต้องการ chunk ที่ใหญ่กว่าเพื่อรักษาตรรกะแบบมีเงื่อนไข (conditional logic) เอาไว้
เมื่อทำ chunk เสร็จแล้ว แต่ละส่วนจะถูกแปลงเป็น embedding ซึ่งหมายถึงการนำข้อความผ่านโมเดลที่ให้ผลลัพธ์เป็นรายการตัวเลข หรือที่เรียกว่า vector ซึ่งเป็นตัวแทนความหมายเชิง semantic ของ chunk นั้นๆ แนวคิดที่คล้ายกันจะอยู่ใกล้กันในพื้นที่ทางคณิตศาสตร์นี้ เช่น "นโยบายการสมทบเงิน 401k" และ "กฎการสมทบเงินเพื่อการเกษียณ" จะอยู่ใกล้กันมากกว่า "นโยบายการสมทบเงิน 401k" กับ "การตั้งค่าเครื่องพิมพ์ในสำนักงาน" เวกเตอร์เหล่านี้จะถูกเก็บไว้ใน vector database เช่น Pinecone, Weaviate หรือทางเลือกแบบ open-source อย่าง Chroma Vector store ไม่ใช่แค่ที่เก็บข้อมูลทิ้งๆ ขว้างๆ แต่มันคือดัชนี (index) ที่ได้รับการปรับแต่งมาเพื่อการค้นหาแบบ approximate nearest-neighbor ช่วยให้คุณค้นหา chunk ที่เกี่ยวข้องที่สุดได้ภายในเวลาไม่กี่มิลลิวินาที แม้ว่าจะมีเอกสารเป็นล้านฉบับก็ตาม
เฟส 2: เส้นทางแบบสด (Online)
When a user finally asks, "What is our travel reimbursement policy for client dinners?", the live pipeline kicks in.
The