# ทำไมต้อง 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 ตรง ๆ คุ้มกว่า),
หรือเป็นข้อมูลใช้ครั้งเดียวทิ้ง

พร้อมแล้วไปลงมือกัน → [ติดตั้ง](../part2/install.md)
