ทำไมต้อง OKF (เทียบกับ RAG)
ถ้าคุณเคยทำระบบ AI ตอบคำถามจากเอกสารองค์กร คุณน่าจะเคยใช้ RAG (Retrieval-Augmented Generation) มาก่อน OKF ไม่ได้มาฆ่า RAG แต่มาแก้จุดอ่อนที่ RAG เจอบ่อยในงานจริง
RAG แบบเดิมทำงานยังไง
เอกสารดิบ → ตัดเป็น chunk → ทำ embedding → เก็บใน vector DB
↓ (ตอนถาม)
ถาม → หา chunk ใกล้เคียง → ยัดเข้า context → ตอบ
LLM ค้นพบความรู้ใหม่จากศูนย์ทุกครั้งที่ถาม ไม่มีการสะสม ไม่มีการเข้าใจว่า chunk ไหน เกี่ยวกับอะไร ขัดกับอะไร หรือเก่าไปแล้ว
จุดอ่อนที่ RAG เจอบ่อย
| ปัญหา | เกิดอะไรขึ้น |
|---|---|
| Chunking artifacts | ตัดประโยคขาดกลาง เช่น "พนักงาน work from home ได้ ยกเว้น 90 วันแรก" อาจเหลือแค่ "พนักงาน work from home ได้" → ตอบผิดอย่างมั่นใจ |
| Knowledge decay | เพิ่มเอกสารใหม่เรื่อย ๆ แต่ของเก่าที่ขัดกันยังอยู่ → ดึงของเก่ามาตอบ (เป็นสาเหตุความล้มเหลวของโปรเจกต์ RAG จำนวนมาก) |
| กล่องดำ | retrieval คืน chunk ที่ดูใกล้เคียงแต่ไม่ใช่คำตอบที่ดีที่สุด และไม่มีใครเห็น |
| ไม่สะสม | คำถามที่ต้องสังเคราะห์ 5 เอกสาร ต้องประกอบใหม่ทุกครั้ง ไม่มีอะไรถูกสร้างขึ้นถาวร |
OKF ต่างยังไง
OKF เปลี่ยนจาก "ดึง chunk ดิบตอนถาม" เป็น "wiki ที่ AI ดูแลและสังเคราะห์ไว้ล่วงหน้า":
- เมื่อมีแหล่งใหม่เข้ามา AI อ่าน สรุป และผสานเข้า wiki ที่มีอยู่ — อัปเดตหน้า แก้ cross-reference และ ตั้งธงเมื่อข้อมูลใหม่ขัดกับของเก่า
- ตอนถาม โหลดหน้า Markdown ที่ "ย่อยมาแล้ว" เข้า context ตรง ๆ — ไม่มี chunk, ไม่มี vector math
- ความรู้กลายเป็น ของถาวรที่ทบต้น ทุกครั้งที่เพิ่มแหล่ง wiki ก็รวยขึ้น
| มิติ | RAG (ดิบ) | OKF (สังเคราะห์ไว้) |
|---|---|---|
| รูปแบบเก็บ | vector DB เฉพาะทาง | ไฟล์ Markdown ธรรมดา + git |
| คนอ่านออกไหม | ไม่ (เป็น UI/ไบนารี) | อ่านออกด้วย text editor |
| version control | ยาก | ได้ในตัว (git diff/PR/blame) |
| รู้ว่าขัดกัน/เก่าไหม | ไม่รู้ | ตั้งธงและ supersede ได้ |
| ผูก vendor | สูง | ไม่มี (เป็นไฟล์) |
"RAG ตายแล้ว" จริงไหม?
ไม่ — วิศวกรส่วนใหญ่มองว่าเป็น คนละชั้น (layer) ไม่ใช่เลือกอย่างใดอย่างหนึ่ง:
- Layer 1 — wiki (OKF): ความรู้แกนที่สังเคราะห์แล้ว ค้นเจอที่นี่ก็จบ (เร็วสุด สัญญาณดีสุด)
- Layer 2 — เอกสารดิบ + vector search: ใช้เมื่อ wiki ยังไม่ครอบคลุม (fallback ลงไปขุดของดิบ)
- Layer 3 — ความรู้ทั่วไปของ LLM: เติมช่องว่างที่ไม่มีทั้งใน wiki และเอกสารดิบ
OKF starter ในหนังสือเล่มนี้รองรับทั้งสองโลก: wiki เป็นหลัก และมี hybrid search (BM25 + semantic) ให้ต่อยอดเมื่อ wiki โตขึ้น (ดูภาคที่ 6)
เมื่อไรควร / ไม่ควรใช้ OKF
เหมาะ เมื่อ: ความรู้ต้องอยู่นาน, ใช้ซ้ำ, มีคนหลายคน/หลาย agent ใช้ร่วมกัน, ต้องตรวจสอบย้อนหลังได้, อยากเลี่ยง vendor lock-in
อาจไม่คุ้ม เมื่อ: เป็นเอกสารดิบจำนวนมหาศาลที่ไม่เคยสังเคราะห์ (ใช้ RAG ตรง ๆ คุ้มกว่า), หรือเป็นข้อมูลใช้ครั้งเดียวทิ้ง
พร้อมแล้วไปลงมือกัน → ติดตั้ง