ช่วงนี้ผมกำลังทดลองสิ่งที่คิดว่าน่าจะเป็น direction ที่สำคัญ…

ช่วงนี้ผมกำลังทดลองสิ่งที่คิดว่าน่าจะเป็น direction ที่สำคัญมากของการใช้ LLM กับ personal knowledge systems:

ไม่ใช่ใช้ LLM เป็นแค่ “เครื่องตอบคำถามจากกองเอกสาร” แต่ใช้ LLM เป็น “ผู้ดูแลคลังความรู้” ที่คอยบำรุงรักษา second brain ให้เราอย่างต่อเนื่อง

ผมคิดว่าหลายคนตอนนี้คุ้นกับ pattern แบบ RAG: เราโยนเอกสารเข้าไป, ระบบทำ embedding/retrieval, แล้วเวลาถามคำถาม มันค่อยดึง chunks ที่เกี่ยวข้องขึ้นมาเพื่อ compose คำตอบ

มันใช้งานได้ และในหลายกรณีก็ดีพอ แต่ปัญหาหลักของมันคือ: มันไม่มี persistence ในระดับ synthesis

ทุกครั้งที่ถาม ระบบต้อง rediscover ความสัมพันธ์ใหม่ ต้องสังเคราะห์ใหม่ ต้องหาว่าเอกสาร A กับ B กับ C เชื่อมกันยังไงใหม่ทุกครั้ง ต้องพยายาม infer ว่าข้อมูลล่าสุดขัดกับข้อมูลเก่าหรือเปล่าใหม่ทุกครั้ง ต้องพยายาม compose “best current understanding” ใหม่ทุกครั้ง

พูดง่ายๆ คือ RAG เก่งเรื่อง retrieval แต่ไม่ได้แก้ปัญหา maintenance ของ knowledge base

ซึ่งในมุมผม ปัญหาของ knowledge work จริงๆ ไม่ใช่แค่ “หาเจอไหม” แต่คือ “สิ่งที่รู้อยู่แล้วถูกจัดระเบียบ ดูแล และสะสมดีขึ้นไหม”

นี่คือจุดที่ผมเริ่มมองว่า architecture ควรเปลี่ยนจาก: raw documents + retrieval ไปเป็น: raw documents + compiled wiki + maintenance loop

แนวคิดที่ผมกำลังใช้เรียกว่า LLM-maintained wiki

หลักการคือ: แทนที่จะให้ model ไปค้นจากเอกสารดิบทุกครั้ง เราให้มันอ่าน source ใหม่ทีละชิ้น แล้วอัปเดต “ชุดความรู้ถาวร” ที่เป็น markdown wiki

พูดอีกแบบ: เราไม่ได้ใช้ LLM แค่ตอน answer-time แต่ใช้มันตอน compile-time ด้วย

พอ source ใหม่เข้ามา สิ่งที่เกิดขึ้นไม่ใช่แค่ “index เพิ่ม” แต่คือ:

summary ถูกอัปเดต canonical topic pages ถูกปรับ new evidence ถูก integrate evidence gaps ถูกระบุ contradictions ถูกเปิดเผย useful synthesis ถูกเก็บเป็น note ถาวร นี่ทำให้ knowledge base ไม่ได้เป็นแค่ archive แต่มันกลายเป็น evolving artifact

ผมคิดว่าอันนี้สำคัญมาก เพราะถ้าเรามอง second brain จริงๆ ปัญหาใหญ่สุดไม่ใช่ capture แต่คือ maintenance cost

ทุกคน capture ได้ แต่สิ่งที่พังเสมอคือ:

สรุปเก่าไม่ถูกแก้ links ไม่ถูกสร้าง MOC ไม่ถูกอัปเดต concept ซ้ำซ้อนเกิดขึ้นเรื่อยๆ project notes กับ resource notes เริ่มทับกัน useful answers หายไปใน chat history system ค่อยๆ เสื่อมสภาพจนค้นอะไรก็เจอแบบครึ่งๆ กลางๆ มนุษย์มัก abandon knowledge systems ไม่ใช่เพราะมันไม่มีคุณค่า แต่เพราะ maintenance burden โตเร็วเกินไป

LLM กลับเหมาะกับงานนี้มากผิดปกติ เพราะมันไม่เบื่อกับงานอย่าง:

อัปเดต 5 ไฟล์จาก source เดียว แก้ wording ให้ consistent เติม cross-links ย้าย insight จาก project note ไป canonical topic page บอกว่า claim ไหนยัง unsupported สรุปคำตอบที่มี value แล้ว file กลับเป็น synthesis note ในแง่นี้ LLM ไม่ได้มาแทน “การคิด” แต่มาแทน “bookkeeping ของความรู้”

และนั่นอาจเป็น use case ที่มี leverage สูงกว่าการให้มันตอบคำถามเฉพาะหน้าเสียอีก

สถาปัตยกรรมที่ผมใช้ตอนนี้แยกเป็น 3 ชั้นชัดเจน

1. Raw Source Layer อันนี้เป็น immutable source library เก็บ source ดิบแบบไม่แก้ บทบาทของมันคือ provenance และ re-verification

ผมคิดว่าจุดนี้สำคัญมาก เพราะถ้าไม่มี source layer แยกชัดเจน wiki จะกลายเป็น narrative layer ที่ค่อยๆ drift ได้ง่าย แต่ถ้ามี source layer เป็นหลักฐาน LLM สามารถ maintain synthesis ได้โดยยังย้อนกลับไป check evidence ได้เสมอ

2. Compiled Knowledge Layer นี่คือหัวใจของระบบ เป็นชุด markdown pages ที่ LLM maintain:

topic pages syntheses index log schema ชั้นนี้ไม่ใช่ raw memory แต่มันคือ compiled memory

พูดในภาษาของ software systems: source documents เหมือน source code wiki pages เหมือน build artifacts ที่ยัง readable และ maintainable โดยมนุษย์

และความต่างสำคัญมาก: เวลาถามคำถามดีๆ กับระบบนี้ สิ่งที่ model อ่านไม่ใช่แค่ document chunks แต่เป็น accumulated understanding ของระบบ

3. Operational Layer อันนี้คือ project notes, active work, handoff state, blockers, next actions

ผมพบว่าถ้าไม่แยกชั้นนี้ออกจาก knowledge layer ระบบจะเริ่มมั่วเร็วมาก เพราะ note เดียวจะพยายามตอบทั้งสองคำถามพร้อมกัน:

ตอนนี้งานไปถึงไหน เรารู้อะไรแล้วบ้างเกี่ยวกับเรื่องนี้ สองอย่างนี้ควรอยู่คนละที่

ในระบบที่ผมใช้อยู่ ผมพยายามยึดกฎง่ายๆ:

project note ตอบว่า what is happening now wiki page ตอบว่า what do we know so far source layer ตอบว่า where does this come from แค่นี้ก็ช่วยลด note sprawl และ role confusion ไปเยอะมาก

อีกจุดที่สำคัญมากคือ navigation discipline

ปัญหาของหลายระบบ AI knowledge retrieval คือมัน scale ด้วยการ “อ่านเพิ่ม” แต่พออ่านเพิ่มมากขึ้น latency, token cost, และ coherence ก็ลดลง

ผมเลยใช้กฎง่ายๆ:

อ่าน index ก่อนเสมอ เปิดแค่ 1-3 notes ที่เกี่ยวที่สุด เปิด source เฉพาะเมื่อ confidence matters จำกัด write set ต่อ ingest ให้เล็ก นี่ทำให้ agent ไม่ต้อง brute-force อ่านทั้ง vault และช่วยให้ system predictable ขึ้นมาก

ในมุมนี้ ผมมองว่า markdown wiki + good navigation + controlled maintenance loop อาจ practical กว่า retrieval-heavy architecture ในหลาย use case ที่ scale ยังไม่ใหญ่มาก

อีกมุมที่ผมคิดว่าน่าสนใจคือ vendor independence

ถ้าเราสร้างระบบทั้งหมดบน:

markdown files simple folder structure schema docs thin runner scripts เราจะไม่ผูก knowledge base กับ provider ใด provider หนึ่ง storage layer ยังเป็นของเรา structure layer ยังเป็นของเรา workflow layer ยังเป็นของเรา

LLM backend เปลี่ยนได้

ตอนนี้ผมลองทั้ง:

local backend ผ่าน Ollama cloud backend ผ่าน Copilot CLI + GPT-5 mini สุดท้ายผมพบว่าจริงๆ สิ่งสำคัญกว่า model ตัวไหน คือ maintenance contract หรือพูดให้ชัดคือ กติกาว่า model อ่านอะไร, เขียนอะไร, และห้ามแตะอะไร

ถ้า contract ไม่ชัด model เก่งแค่ไหนก็มั่วได้ ถ้า contract ชัด model ขนาดกลางก็เริ่ม useful มาก

ผมเลยมองว่าการออกแบบ schema/workflow สำหรับ knowledge-maintenance agents อาจสำคัญพอๆ กับ model quality เอง

ตัวอย่าง use case ที่ผมลองคือ online sales knowledge base

ผม ingest source จริงจาก TikTok For Business แล้วให้ system:

เก็บ source ไว้ใน source library อัปเดต canonical topic page เรื่อง Online Sales เพิ่มความรู้ใหม่เกี่ยวกับ pixel instrumentation event tracking Add-to-Cart optimization during learning broad targeting budget floors Spark Ads reuse log ว่า ingest อะไรไปแล้ว สิ่งที่น่าสนใจคือหลัง ingest เสร็จ เวลาถามว่า “ตอนนี้ร้านควรโฟกัสอะไร” model ไม่ได้ตอบจาก scratch แต่มันตอบจาก compiled understanding ที่ถูกอัปเดตแล้ว

นี่คือจุดที่ผมคิดว่า LLM Wiki ต่างจาก RAG ที่สุด: มันทำให้ “คำตอบในอนาคต” ดีขึ้น เพราะ “ความรู้ในอดีต” ถูกดูแลไว้แล้ว

และผมคิดว่านี่อาจเป็น missing piece ของ AI-native second brain: ไม่ใช่ retrieval อย่างเดียว ไม่ใช่ chat อย่างเดียว ไม่ใช่ note capture อย่างเดียว แต่เป็นระบบที่มี maintenance loop จริง

ถ้าจะสรุปสิ่งที่ผมเชื่อหลังจากลองทำ: อนาคตของ AI knowledge systems อาจไม่ใช่การทำ retrieval ให้เก่งขึ้นเรื่อยๆ อย่างเดียว แต่อาจเป็นการสร้างระบบที่เก่งในการ:

turning raw inputs into maintained knowledge preserving synthesis surfacing uncertainty keeping canonical artifacts current and making useful answers accumulate instead of disappear หรือพูดสั้นที่สุด: RAG helps you answer questions LLM-maintained knowledge systems help you build understanding

และผมคิดว่าความต่างระหว่าง “answering” กับ “understanding” นี่แหละ คือสิ่งที่จะกำหนดว่าระบบ AI knowledge tools รุ่นถัดไปจะหน้าตาเป็นยังไง

---

📖 อ่านบทความเต็มบน Facebook | 🔔 ติดตาม SynapTech