ในที่สุดก็ได้อ่าน gist ของ LLM Wiki ของ Karpathy สักที (ใช่ มาช้ากว่ากระแส XD)
และพูดตามตรง แนวคิดทั้งหมดก็เหลือแค่สิ่งง่ายๆ: "RAG ที่อัปเดตได้"
1. ปัญหา
เมื่อ LLM ทำงานกับเอกสาร ไม่มีการสะสมอะไรเลย ทุกคำถาม – โมเดลจะดึงชิ้นส่วนมา สังเคราะห์ใหม่ตั้งแต่ต้น แล้วก็ลืม ความรู้ไม่เคยถูกคอมไพล์ และที่สำคัญกว่านั้นสำหรับผม: แทบไม่มีข้อมูลที่มีประโยชน์ถูกดึงออกมาจากบทสนทนาด้วยซ้ำ
RAG ช่วยได้บางส่วน (ในความหมายกว้าง – โฟลเดอร์ที่มีไฟล์ .md ก็คือ RAG เช่นกัน) แต่ไปป์ไลน์มาตรฐาน (ที่ทุกคนใช้) ไม่มีฟังก์ชันอัปเดต การกลั่น หรือการทำความสะอาดตัวเอง ความรู้จะถูกวางลงในดัชนีครั้งเดียวแล้วก็นอนนิ่งอยู่ตรงนั้น ช่องว่างนั้นคือสิ่งที่ LLM Wiki มาเติมเต็ม
การกลับมุมของ Karpathy: ระหว่างแหล่งข้อมูลดิบกับคุณ มี wiki แบบ markdown ที่เอเจนต์จะเขียนและดูแลอย่างค่อยเป็นค่อยไป คอมไพล์ครั้งเดียว แล้วก็อัปเดตอยู่เสมอ
2. สถาปัตยกรรม: 3 ชั้น
- raw/ – แหล่งข้อมูลดิบที่ไม่เปลี่ยนแปลง เอเจนต์ไม่เขียนลงไปที่นี่
- wiki/ – หัวใจของระบบ หน้า markdown (เอนทิตี, แนวคิด) ที่ LLM เขียนและเชื่อมโยงกันเอง โดยพื้นฐานแล้วคือความรู้ที่มีโครงสร้างเป็นกราฟ
- CLAUDE.md – คู่มือวิธีการรัน LLM Wiki เท่านั้น ประกอบด้วย: รูปแบบหน้า, ข้อตกลงในการเชื่อมโยง, วิธีการนำเข้า, กฎการตรวจสอบ สิ่งที่เปลี่ยน Claude จากแชทบอทเป็นผู้ดูแล wiki ที่มีวินัย
เพียงพอสำหรับหลายร้อยหน้าโดยไม่ต้องปรับแต่งเพิ่มเติม:
3. การดำเนินการ
สามการดำเนินการ – คุณอยากวาดเป็นฟังก์ชัน API ทันที:
- Ingest -> add(source: file | list[file]) วางแหล่งข้อมูล -> เอเจนต์อ่าน -> คุยกับคุณ -> เขียนสรุป -> อัปเดตดัชนี -> แก้ไขหน้าเอนทิตีที่เกี่ยวข้อง -> เพิ่มใน log แหล่งข้อมูลหนึ่งแตะ 10-15 หน้า
- Query -> search(prompt: str) การดำเนินการที่สำคัญที่สุด ตอบคำถามของคุณ + (จุดสำคัญ) จะบันทึกการสังเคราะห์กลับเข้าไปใน wiki โดยอัตโนมัติเป็นหน้าใหม่ การสำรวจจะทบต้นแทนที่จะหายไปในประวัติแชท เบื้องหลังมันคือ add(source=dialogue) โดยพื้นฐาน
- Lint -> lint() ไม่มีอาร์กิวเมนต์ ตรวจสอบ wiki เป็นระยะ: ความขัดแย้ง, หน้าที่ไม่มีลิงก์, ข้อมูลที่ล้าสมัย, การอ้างอิงที่ขาดหาย เรียกเมื่อมีข้อความผู้ใช้ทุก N ข้อความ หรือเมื่อมีจำนวนบรรทัดที่เปลี่ยน ง่ายต่อการแนบกับ /schedule
ทำให้ผมนึกถึง Claude Dreaming – ผมคิดว่า Dreaming ได้แรงบันดาลใจบางส่วนจากรูปแบบนี้ (ถึงแม้ชุดฟังก์ชันจะต่างกันเล็กน้อย)
4. การทำดัชนี
ไฟล์พิเศษสองไฟล์ทำให้ wiki สามารถนำทางได้:
- index.md – สถานะปัจจุบัน แคตตาล็อกของทุกหน้าพร้อมคำอธิบายหนึ่งบรรทัด เอเจนต์จะอ่านมันก่อนทุกคำถาม – เป็นบริบทขั้นต่ำว่า "ใน wiki มีอะไรบ้าง"
- log.md – บันทึกของทุกเหตุการณ์ ไม่มีรูปแบบตายตัว ไทม์ไลน์ที่เพิ่มอย่างเดียว ถ้าบรรทัดมีรูปแบบที่สอดคล้องกัน (เช่น \
## [YYYY-MM-DD] ingest | title\) log จะ grep ได้อย่างสะอาดด้วยเครื่องมือ unix ทั่วไป – มีประโยชน์สำหรับการตรวจสอบ
index.md สามารถขยายขนาดได้อีก (ดัชนีเวกเตอร์, BM25, GraphDB, ...) – ผมจะพูดถึงในโพสต์แยก
5. สรุปประเด็นสำคัญ
นี่คือวิธีที่ผมจะมอง: มันไม่ใช่ทางเลือกระหว่าง RAG และ LLM Wiki – พวกมันคือสองจุดบนแกน "ความทรงจำที่ทบต้น" เส้นเดียวกัน
RAG ไม่จำเป็นต้องเป็น vector DB – โฟลเดอร์ของไฟล์ markdown ก็คือ RAG เช่นกัน
ดังนั้นคุณสามารถพูดใหม่ได้ว่า LLM Wiki คือ RAG ที่มีสามสิ่งเสริมด้านบน:
- ชั้นการสรุปความ
- การเขียนโครงสร้างในระดับสรุปความแบบกึ่งอิสระ (แทบไม่มีข้อจำกัด)
- การตรวจสอบโครงสร้างเป็นระยะ + การปรับปรุงตัวเอง (CRON)
