การถามตอบจากเอกสารขององค์กร
RAG Server สำหรับคลังความรู้องค์กร
RAG server คือเครื่องที่ให้โมเดลค้นเอกสารขององค์กรคุณก่อนตอบ และอ้างอิงหน้าที่ใช้เสมอ เหมาะกับงานถามตอบจากคู่มือ สัญญา และฐานข้อมูลภายใน ต้องใช้ embedding model, vector database และ LLM ทำงานร่วมกัน ขนาดเครื่องจึงมาจากปริมาณเอกสารและจำนวนผู้ใช้ ไม่ใช่จากขนาดโมเดลอย่างเดียว
RAG แก้ปัญหาอะไร
คำตอบอยู่ในเอกสาร แต่ไม่มีใครหาเจอทัน
องค์กรส่วนใหญ่มีคำตอบอยู่แล้วในคู่มือ สัญญา และนโยบายภายใน ปัญหาคือการหาให้เจอ RAG server ทำให้คนถามด้วยภาษาปกติ แล้วได้คำตอบพร้อมแหล่งที่มา
คู่มือและขั้นตอนการทำงาน
พนักงานใหม่ถามว่าเรื่องนี้ทำอย่างไร แล้วได้คำตอบพร้อมหน้าที่มา แทนที่จะต้องอ่านคู่มือทั้งเล่ม
สัญญาและเอกสารกฎหมาย
ค้นเงื่อนไข วันหมดอายุ และภาระผูกพัน ข้ามสัญญาหลายฉบับ พร้อมอ้างอิงข้อที่พบ
นโยบายและสวัสดิการของ HR
ตอบคำถามพนักงานเรื่องการลา สวัสดิการ และระเบียบภายใน โดยไม่ต้องส่งทุกคำถามผ่าน HR
เอกสารเทคนิคและสเปก
ทีมบริการค้นสเปกเครื่อง ขั้นตอนซ่อม และอาการเสียในอดีต จากคลังเอกสารที่คุณมีอยู่แล้ว
คำตอบพร้อมอ้างอิงหน้าเอกสาร
ทุกคำตอบชี้กลับไปที่ไฟล์และหน้าที่ใช้ ผู้อ่านจึงตรวจสอบได้ก่อนนำไปใช้
องค์ประกอบ
หกองค์ประกอบบนเครื่องเดียว
RAG ไม่ใช่โมเดลเดียว แต่เป็นลูกโซ่ของหลายขั้นตอน องค์กรส่วนใหญ่รันทั้งลูกโซ่บนเครื่องเดียวได้ และแต่ละขั้นดันทรัพยากรคนละด้าน
| องค์ประกอบ | หน้าที่ | ทรัพยากรหลัก | ตัวกำหนดขนาด |
|---|---|---|---|
| ingestion และ OCR | แปลง PDF ไฟล์ Word เอกสารสแกน และภาพถ่ายเอกสาร ให้เป็นข้อความที่ค้นได้ | CPU และ GPU ระหว่างประมวลผล | จำนวนหน้าต่อรอบ และสัดส่วนเอกสารสแกนที่ต้องใช้ OCR |
| embedding model | แปลงข้อความที่แบ่ง chunk แล้วให้เป็น vector เพื่อค้นด้วยความหมาย | GPU (ใช้ VRAM น้อย) และ NVMe | ขนาดคลังเอกสาร และความถี่ในการทำ index ใหม่ |
| vector database | เก็บ vector และค้น chunk ที่ใกล้เคียงกับคำถามที่สุด | RAM และ NVMe | จำนวน chunk คูณมิติของ vector โดย index ควรอยู่ใน RAM |
| reranker | จัดลำดับ chunk ที่ค้นได้ใหม่ ก่อนส่งให้โมเดลที่เขียนคำตอบ | GPU | จำนวนคำถามต่อนาที แลกมาด้วย latency ที่เพิ่มขึ้นเล็กน้อย |
| LLM | เรียบเรียงคำตอบจาก chunk ที่ค้นได้ พร้อมอ้างอิงแหล่งที่มา | VRAM เป็นหลัก | ขนาดโมเดลคูณ precision บวก KV cache ต่อผู้ใช้พร้อมกันหนึ่งคน |
| แอปหน้าบ้าน | หน้าจอถามตอบ สิทธิผู้ใช้ ประวัติคำถาม และการจัดการคลังเอกสาร | CPU และ RAM | จำนวนผู้ใช้ทั้งหมด ไม่ใช่จำนวนผู้ใช้พร้อมกัน |
ขนาดเครื่องตามปริมาณเอกสาร
คลังเอกสารกำหนด RAM และ NVMe ก่อนจะกำหนด GPU
index แบบ vector ควรอยู่ใน RAM เพื่อให้ค้นได้เร็ว ส่วนไฟล์ต้นฉบับและ index สำรองอยู่บน NVMe ส่วน GPU เข้ามาเกี่ยวกับโมเดลที่เขียนคำตอบ และจำนวนผู้ใช้พร้อมกัน
| ขนาดคลังเอกสาร | RAM | NVMe | ขนาดเครื่อง | ผู้ใช้พร้อมกัน |
|---|---|---|---|---|
| ไม่เกิน 100,000 หน้า | 64 ถึง 128 GB | 2 TB | ระดับ Workstation ถึง Server 1 GPU | 1 ถึง 20 |
| 100,000 ถึง 1 ล้านหน้า | 128 ถึง 256 GB | 4 ถึง 8 TB | Server 1 GPU | 20 ถึง 80 |
| มากกว่า 1 ล้านหน้า | 256 GB ขึ้นไป | 8 TB ขึ้นไป กระจายหลาย NVMe | Server 4 GPU | 80 ขึ้นไป |
ความแม่นยำและสิทธิ
คำตอบถูกต้อง ตรวจแหล่งที่มาได้ และเห็นเฉพาะสิ่งที่ผู้อ่านมีสิทธิเห็น
ระบบถามตอบที่องค์กรพึ่งพาได้ต้องผ่านสามข้อ คือ ตอบจากเอกสารจริง แสดงว่าคำตอบมาจากไหน และเคารพสิทธิที่เอกสารเหล่านั้นมีอยู่แล้ว
- สิทธิระดับเอกสาร
- แต่ละคนเห็นคำตอบเฉพาะจากเอกสารที่ตนมีสิทธิอ่าน สิทธิอิงตามกลุ่มผู้ใช้ใน Mimir Suites ที่ส่งมอบมาพร้อมเครื่อง และถูกตรวจตอนดึงเอกสาร ไม่ใช่ตอนแสดงคำตอบ
- ทุกคำตอบมีอ้างอิง
- ทุกคำตอบแสดงไฟล์และหน้าที่ใช้ และเปิดต้นฉบับได้ทันที เมื่อไม่มีเอกสารรองรับคำถาม ระบบจะบอกว่าไม่พบ ซึ่งดีกว่าการเดา
- เนื้อหาอยู่ภายในองค์กร
- เอกสาร index และคำถาม อยู่บนเครื่องของคุณทั้งหมด ไม่มีเนื้อหาถูกส่งออกไปยังบริการภายนอก ซึ่งสำคัญเมื่อคลังเอกสารมีข้อมูลส่วนบุคคลที่อยู่ภายใต้ PDPA
- รอบการทำ index ใหม่
- เอกสารที่เปลี่ยนบ่อยทำ index ใหม่รายวัน ส่วนคลังที่นิ่งแล้วทำรายสัปดาห์ ระบบบันทึกว่าคำตอบหนึ่งใช้เอกสารเวอร์ชันใด จึงตรวจย้อนหลังได้
คำถามที่พบบ่อย
คำถามที่มักเกิดขึ้นก่อนเริ่มโครงการ RAG
- ใช้เอกสารสแกนเก่าที่ไม่มีชั้นข้อความได้ไหม
- ได้ เราใส่ขั้นตอน OCR ไว้ก่อนทำ index เอกสารสแกน ภาพถ่าย และ PDF ที่เป็นภาพล้วน จึงกลายเป็นข้อความก่อน คุณภาพคำตอบขึ้นกับคุณภาพของต้นฉบับ หน้าที่เบลอหรือเอียงมากควรสแกนใหม่
- ต้องจัดระเบียบเอกสารก่อนไหม
- ไม่ต้องเริ่มจากศูนย์ แม้โครงสร้างที่ชัดเจนจะให้ผลดีกว่า เราเริ่มจากคลังเอกสารที่คุณมีอยู่ ตัดไฟล์ซ้ำและเวอร์ชันที่ถูกแทนที่ออก แล้วตกลงกันว่าแต่ละกลุ่มเห็นโฟลเดอร์ใดได้บ้าง ที่เหลือระบบจัดการให้
- ยังมีโอกาสตอบผิดอยู่ไหม
- โมเดลภาษาทุกตัวผิดได้ RAG ลดความเสี่ยงด้วยการบังคับให้คำตอบมาจากเอกสารที่ค้นได้ และแสดงแหล่งที่มาเสมอ ทุกคำตอบจึงตรวจสอบได้ เราตั้งค่าให้ระบบบอกว่าไม่พบ เมื่อไม่มีเอกสารรองรับคำถามนั้น
- เพิ่มเอกสารแล้วต้องสร้างระบบใหม่ไหม
- ไม่ต้อง เอกสารใหม่เข้าคิว ingestion แล้วถูกเพิ่มเข้า index เดิม ระบบยังตอบคำถามได้ระหว่างที่งานนั้นทำงานอยู่ การสร้าง index ใหม่ทั้งหมดจำเป็นเฉพาะตอนเปลี่ยน embedding model ซึ่งเราวางแผนไว้ล่วงหน้า
บอกเรามาว่าคลังเอกสารของคุณมีอะไร แล้วเราออกแบบระบบให้
ส่งมาว่ามีเอกสารชนิดไหน ประมาณกี่หน้า และใครควรเห็นอะไรได้บ้าง เราตอบกลับพร้อมโครงร่างระบบ RAG และสเปกเครื่องที่รองรับคลังขนาดนั้น