LLM Wiki เจาะลึกเชิงเทคนิค

LLM Wiki คืออะไร?

Design pattern ที่ ให้ LLM ดูแล knowledge base แทนที่จะ re-derive context ใหม่ทุก query

LLM Wiki คือ folder ของ markdown files ที่ LLM ทั้งอ่านและเขียน — knowledge base ที่ compound ข้าม session Pattern นี้ Andrej Karpathy ระบุไว้ใน gist สั้น ๆ ขึ้นต้นด้วยข้อความสำคัญ:

"The wiki is a persistent, compounding artifact." — Karpathy

ประโยคเดียวนี้คือสิ่งที่ทำให้ pattern นี้ต่างจาก AI-knowledge tool เกือบทั้งหมดในตลาด ระบบ retrieval ส่วนใหญ่เป็น stateless — query ใหม่ก็ derive answer ใหม่จาก raw chunks. LLM Wiki เป็น stateful — query ดึงจาก synthesis ที่สะสมไว้ และ (เลือกได้) อัพเดต synthesis นั้นด้วยสิ่งที่เรียนรู้จาก query ใหม่

3 layers, 3 operations

Pattern มี 3 layers พอดี:

• Raw sources — เอกสารที่จับมา ห้ามแก้ไขหลังจับ
• Wiki — entity pages ที่ LLM สังเคราะห์และดูแล
• Schema — รัฐธรรมนูญ: กฎ, entity types, lifecycle policies

และมี 3 operations พอดี:

• Ingest — เปลี่ยน source ใหม่เป็นการอัพเดต wiki (หลายหน้า)
• Query — ดึงความรู้ที่สะสมเพื่อตอบคำถาม
• Lint — ตรวจสุขภาพเป็นระยะ (contradictions, orphans, decay)

การแบ่งงาน

มนุษย์ดูแลการ curate sources และตัดสินคุณภาพ LLM ทำงาน bookkeeping — อัพเดต cross-references, รักษา consistency, ดึงเรื่องที่ขัดแย้งให้เห็น การแบ่งไม่ใช่ "LLM ทำงาน มนุษย์ตรวจ" — แต่เป็น "มนุษย์ curate, LLM ทำสวน"

ทำไมไม่ใช้ RAG อย่างเดียว?

Retrieval-Augmented Generation ใช้ดีสำหรับ lookup. LLM Wiki เพิ่ม layer ด้านบน: synthesis ที่สะสม

Retrieval-Augmented Generation (RAG) — Lewis et al., 2020 — รวม model weights (parametric memory) กับ external retrievable corpus (non-parametric memory) ทุก query โมเดลดึง chunks ที่เกี่ยวข้องและ generate response ที่อ้างอิงจาก chunks เหล่านั้น มันใช้ได้ มันคือ default ของ AI-knowledge systems ปัจจุบัน

แต่ paper RAG ตัวต้นฉบับเองยอมรับ 2 ปัญหาที่ยังเปิดอยู่:

"Providing provenance for their decisions and updating their world knowledge remain open research problems." — Lewis et al.

LLM Wiki แก้ทั้งสองต่างจาก RAG variants ที่มาทีหลัง:

• Provenance → ทุก wiki claim cite specific raw file พร้อม confidence number
• Updating → ingest re-touch ทุก page ที่กล่าวถึง entity เปิด contradiction ให้มนุษย์ resolve

RAG vs LLM Wiki — เปรียบเทียบ canonical

Production hybrid

ระบบจริงใช้ ทั้งคู่. RAG ดึง raw chunks (เร็ว, ปัจจุบัน); wiki เก็บ synthesised understanding (compound, traceable). Anthropic phrasing: "structured note-taking provides persistent memory with minimal overhead" — note-taking คือ wiki, just-in-time retrieval คือ RAG

Query flow ที่ใช้ได้จริง:

1. เจอ wiki ก่อน — ถูก, synthesised
2. ถ้า wiki silent หรือ confidence ต่ำ → fall through ไป RAG บน raw documents — แพง, raw
3. ถ้า RAG ให้คำตอบดี → file back เป็น wiki page ใหม่ ("save valuable findings" ฝั่งของ query operation)

บรรพบุรุษ: Zettelkasten

Architecture เก่า 70 ปี Niklas Luhmann ทำ manual ด้วยกระดาษ 90,000 ใบ ความใหม่อยู่ที่ maintenance layer

Zettelkasten ("กล่องสลิป" ภาษาเยอรมัน) คือระบบจัดการความรู้บน 3 หลักการ:

1. Atomicity — 1 ความคิดต่อ 1 note
2. Cross-referencing — links ที่ชัดเจนระหว่าง notes
3. Unique identification — IDs ที่เสถียร (Luhmann ใช้ numbered hierarchy)

Niklas Luhmann นักสังคมวิทยาเยอรมัน สร้าง Zettelkasten ของตัวเอง ~90,000 ใบกระดาษตลอดชีวิต เขาให้เครดิตว่ามันเป็น engine เบื้องหลัง ~50 หนังสือ + ~550 บทความ ระบบของเขาถูก digitise ในปี 2019 และเปิดให้สาธารณชนดูได้

Genealogy

Lineage จากกระดาษถึง LLM Wiki ตรงไป:

Atomic notes, explicit linking, metadata-driven retrieval ที่นิยาม LLM Wiki สืบทอดมาจาก index card โดยตรง Architecture ผ่านการพิสูจน์ด้วย practice 70 ปี

การสอนแบบ shortcut

ถ้าผู้เรียนเข้าใจ Zettelkasten — เขาเข้าใจ LLM Wiki Framing:

"LLM Wiki = Zettelkasten + LLM ที่ทำ maintenance"

สิ่งที่เป็น manual ใน Zettelkasten ดั้งเดิม:

• เขียนแต่ละการ์ด
• แทรก links ระหว่างการ์ด
• เปิดกล่องดูเพื่อหา orphans
• อ่านซ้ำและเขียนใหม่เมื่อมี card ใหม่เข้ามา

ทั้ง 4 อย่างกลายเป็น operations ของ LLM มนุษย์อยู่ใน role curation/judgement; LLM ทำสวนที่กิน hours/week ก่อน

3 layers

Raw แก้ไม่ได้. Wiki สังเคราะห์. Schema เป็นรัฐธรรมนูญ. กฎ mutability ต่างกันต่อ layer คือวินัยที่กัน drift

Raw layer (raw/)

Primary sources ที่จับมา — verbatim, ไม่แก้ไขหลังจับ:

raw/
├── 2026-05-09-karpathy-llm-wiki-gist.md
├── 2026-05-09-rag-paper.md
└── ...

Frontmatter บันทึก source_url, ingested_at, source_type. ตัว text เองคือสิ่งที่ source พูดตอน ingest. ถ้า upstream เปลี่ยน — re-ingest เป็นไฟล์ใหม่ที่มี date prefix ใหม่ ไม่แก้ไฟล์เก่า รักษา audit trail

Wiki layer (wiki/)

Entity pages ที่ LLM สร้าง 1 concept ต่อ 1 file:

wiki/
├── concept:llm-wiki.md
├── concept:rag.md
├── pattern:citation-discipline.md
└── ...

Pages เป็น synthesised, ไม่ใช่ copy ทุก claim cite raw source: [src: raw/...] {conf: 0.5}. Pages อัพเดตเมื่อ source ใหม่เข้ามา — confidence เพิ่มขึ้น, claims reinforce กัน, contradictions ถูกเปิดให้มนุษย์ resolve

Schema layer (SCHEMA.md / CLAUDE.md / AGENTS.md)

รัฐธรรมนูญ ระบุ:

• Entity types (concept, pattern, principle, risk, tool, decision)
• Relation types (composes, depends-on, mitigates, ฯลฯ)
• กฎ confidence + decay
• Lint policies
• กฎ privacy

Schema คือ กลไกวินัย ถ้าไม่มี — LLM-maintained wiki จะ diverge ในสัปดาห์ ถ้ามี — artifact คงตัวได้หลายปี Schema updates ควร rare และ deliberate — มันคือ constitution ไม่ใช่ config

ทำไม 3 layers ไม่ใช่ 2?

ระบบ 2-layer (raw + wiki, ไม่มี schema) ขาดกลไกวินัย LLM ไม่มี contract สำหรับเขียน pages, entities หมายถึงอะไร, lint เมื่อไหร่ หลัง dozens of sources — vibe ของ ingest ทุกครั้งต่างกัน, formatting drift, citation styles drift, page granularity drift Schema คือสิ่งที่ทำให้ pattern นี้ maintainable ไม่ใช่แค่ one-shot synthesis

Page template + citation discipline

ทุก page มี shape เหมือนกัน. ทุก claim cite source พร้อม confidence number. วินัยนี้คือสิ่งที่ทำให้ artifact น่าเชื่อถือ

Standard page template

---
id: <entity-type>:<kebab-slug>
type: <entity-type>
title: <Human-readable title>
status: active                    # active | stale | faded | orphan
confidence: 0.5
sources: []                       # raw/ files ที่มีส่วน
created: YYYY-MM-DD
updated: YYYY-MM-DD
updated_log:
  - YYYY-MM-DD: created
tiers: semantic
half_life_days: 180
tags: []
---

# <Title>

## Summary
หนึ่งย่อหน้า ภาษาธรรมดา

## Claims
- <Claim.> `[src: raw/...] {conf: 0.5}`
- <Another.> `[src: raw/A.md, raw/B.md] {conf: 0.8}`

## Relationships
- composes → [[entity-id]] `{conf: 0.x}`

## Open questions
- [ ] <question>

## Changelog
- YYYY-MM-DD — created

กฎ citation

ทุก claim cite raw file อย่างน้อย 1 ตัว พร้อม confidence number. ห้ามมี floating assertion ถ้า cite ไม่ได้ — มันไม่เข้า wiki

Format ทำ 3 อย่างพร้อมกัน:

• บังคับ grounding — LLM padding pages ด้วย priors ไม่ได้
• เปิดทาง decay — claims ที่ confidence ต่ำและเก่า marks ตัวเองเป็น stale
• เปิด contradictions — ตอน source B contradicts source A — ทั้ง 2 citations อยู่; supersession ชัดเจน

Confidence math

First observation:               conf = 0.5
Reinforcement (independent src): conf = 1 - (1 - conf) * 0.6
                                 (asymptote → 1.0)
Contradiction:                   เปิด supersession candidate
                                 (อย่าลด silently)

หลัง 1 reinforcement: 0.5 → 0.8 หลัง 2: 0.8 → 0.92 หลัง 3: 0.92 → 0.968. Diminishing returns โดยตั้งใจ — เมื่อ claim มั่นคงแล้ว citation เพิ่มไม่ได้ bump confidence มาก

Anti-patterns

• ❌ "[src: official docs]" — ไร้ความหมาย ต้อง point ไป raw/<file>.md
• ❌ One mega-citation ท้าย page — ทำลาย per-claim audit
• ❌ ไม่มี confidence number — decay ทำไม่ได้
• ❌ Synthesise claims เกิน sources — trace ไม่ได้ก็ห้ามเขียน

ลองทำมือ

เดินผ่าน ingest 1 ครั้ง, query 1 ครั้ง, lint 1 ครั้ง — ไม่ใช้ tooling ใด สร้าง muscle memory ก่อน automate

Ingest workflow (manual)

1. Capture — ชี้ LLM ที่ source บันทึก verbatim ไป raw/YYYY-MM-DD-<slug>.md พร้อม frontmatter
2. Extract — เลือก entities ที่ระบุ (ตาม catalogue ของ SCHEMA) ต่อ entity: มีอยู่แล้ว? อัพเดต ถ้าไม่ — สร้าง
3. Write/update — ต่อ entity page เพิ่ม claims พร้อม [src:] markers bump confidence claims ที่ reinforce
4. Reconcile — อัพเดต index.md และ log.md อัพเดต graph/edges.jsonl
5. Summarise — บอกมนุษย์: pages ที่เพิ่ม, ที่แก้, contradictions ที่เปิด

Note: ingest ครั้งเดียวมัก update 3-10 pages. ถ้า touch แค่ 1 — คุณพลาด cross-references re-scan

Query workflow

1. Parse — เลือก entities ในคำถาม
2. Retrieve — grep wiki/ หา IDs ที่ตรง อ่าน pages ตาม [[wikilinks]] 1-2 hops
3. Synthesise — ประกอบ answer จาก claims ที่สะสม cite specific pages
4. (Optional) File back — ถ้าคำถามใหม่ + reusable save Q+A เป็น wiki/q-<slug>.md

Lint workflow

เป็นระยะ ไม่ใช่ทุก ingest. แนะนำ: ทุก 10 ingests, หรือทุกสัปดาห์/เดือน

เช็ค:

• Orphans — pages ที่ไม่มี link เข้า และไม่อยู่ใน index.md
• Broken wikilinks — [[entity-id]] ที่ไม่มีอยู่
• Contradictions — propose supersession; ห้าม delete silent
• Stale claims — apply decay; mark status: faded เมื่อ conf < 0.2 และ untouched 2× half-life
• Citation integrity — ทุก [src:] marker ชี้ไปไฟล์ที่มีอยู่

Output: audit artefact raw/lint-YYYY-MM-DD.md ระบุ พบอะไร, แก้แล้ว, escalate

การออกแบบ Schema

Schema คือการตัดสินใจที่ leverage สูงสุด ตั้ง entity catalogue + decay parameters ให้ดีตั้งแต่ต้น ห้ามแก้บ่อย

Schema design คือการตัดสินใจที่ leverage สูงสุดใน LLM Wiki พอตั้งแล้วและ LLM operate against it ไปสัปดาห์ — เปลี่ยน schema แพง (ทุก page อาจต้อง migrate). Version แรกควร deliberate

Design checklist

1. Entity catalogue — เลือก 5-8 types หลีกเลี่ยง 20
2. Relation catalogue — เลือก 6-10 ใช้ default set ถ้าไม่แน่ใจ
3. Decay half-life ต่อ type — fast (tools): 90 days สเสถียร (decisions): 365 days
4. Privacy rules — list ชัดเจนว่าอะไรห้ามเข้า wiki/
5. Confidence formula — เก็บ default ถ้าไม่มีเหตุผล

Entity catalogues ทั่วไปต่อ domain

Anti-patterns ใน schema design

• ❌ 20+ entity types — over-engineered; LLM เลือกยากขึ้น
• ❌ Vague types ("note", "thing") — types ควรแบ่ง space ชัด
• ❌ Schema ใน chat history — LLM ลืมระหว่าง session; commit เข้า file
• ❌ Schema ยาวกว่า wiki — over-specified ก่อน wiki มี signal

Tooling: Obsidian + Git

Local-first, markdown-native, ฟรี Viewer ไม่ได้ owned data ของคุณ — wiki แค่ folder

ทำไม Obsidian ฟิตกับ pattern

Recommended plugin set

Git เป็น version layer

ทำ wiki folder เป็น git repo. ประโยชน์:

• Audit trail — ทุกการเปลี่ยนแปลง versioned พร้อม commit message
• Branch สำหรับ experiments (ลอง schema ใหม่ใน branch)
• Diff edits — ดูว่า LLM เปลี่ยนอะไร session นี้
• Sync ผ่าน GitHub สำหรับหลาย device

Setup จริง:

cd ~/your-wiki-folder
git init
echo "raw/private/" > .gitignore   # ถ้ามี private sources
git add .
git commit -m "Initial wiki snapshot"

จากนั้น LLM (Claude Code, Cursor, etc.) edit files; คุณ git diff review เป็นระยะ; commit เมื่อพอใจ

Failure modes

Claim drift = ปัญหาอันดับ 1 บวก orphans, contradictions, schema gaps. Mitigation เป็น layered

Claim drift = wiki ค่อย ๆ พูดสิ่งที่ raw sources ไม่ support แล้ว rarely catastrophic วันแรก — compound. หลัง 6 เดือนไม่ lint, wiki 50 หน้าอาจมี claims 10-20% ที่ไม่ตรง sources แล้ว

4 แบบที่ drift เกิด

1. Re-write โดยไม่ re-read — LLM update page ตาม priors ของตัวเอง ไม่ตาม raw ที่ cite
2. Source update upstream — raw ของเรา dated; upstream blog ถูกแก้
3. Cascading reinforcement — Page A cites B which cites C; trail ไป raw บางลง
4. Schema evolution — schema เพิ่ม type; old pages ไม่ conform; lint flag แต่ไม่มีคน migrate

Failure modes อื่น

ทำไม "supersession over deletion"

Delete claims เก่ารู้สึก tidy มันผิด Audit trail สำคัญกว่าความเรียบร้อย — 6 เดือนข้างหน้า คุณอาจต้องรู้ ทำไม wiki เคยพูดว่า X. Mark old claims status: stale, link ไป superseding claim, ทิ้งไว้ในไฟล์

Provenance audit

Drift check ที่ลึกที่สุด — เลือก 5 claims สุ่ม verify ด้วยมือว่า cited raw ยังพูดสิ่งที่ claim:

for page in wiki/*.md; do
  for src in $(grep -oE 'raw/[^]]+' "$page"); do
    [ -f "$src" ] || echo "BROKEN CITATION: $page → $src"
  done
done

รันรายเดือน ถ้า 1+ claim สุ่ม fail verification — full lint sweep overdue

Integration กับ agents (production angle)

LLM Wiki ฟิตใน Anthropic context-engineering framing เป็น persistent memory layer Compose กับ just-in-time retrieval

Agents ปัจจุบัน — "LLMs autonomously using tools in a loop" — มี context budget ตายตัวที่ถูกกินโดย tool calls และ intermediate reasoning Anthropic context-engineering ระบุข้อจำกัด:

"As the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases."

ปรากฏการณ์นี้เรียก context rot มัน motivate ให้ treat context เป็น scarce resource — และทำ case ให้ LLM Wiki:

"Structured note-taking enables persistent memory outside the context window — agents write notes that get pulled back in later, providing 'persistent memory with minimal overhead.'"

Just-in-time pattern

Anthropic แนะนำ agents รักษา "lightweight identifiers (file paths, stored queries, web links, etc.) and use these references to dynamically load data into context at runtime." นี่คือ shape ของ LLM Wiki — wiki เก็บ references และ synthesised pages; agent โหลดเฉพาะที่ต้องการ on demand

Wiki + RAG + agents compose

Query มาถึง
  ↓
Agent เช็ค LLM Wiki ก่อน (ถูก, synthesised, traceable)
  ↓
ถ้า wiki มีคำตอบ → cite + return
ถ้า wiki silent หรือ confidence ต่ำ:
  ↓
  Agent invoke RAG บน raw documents (แพง, fresh)
  ↓
  ถ้า RAG ให้คำตอบดี → return
  ↓
  Optional: file back เป็น wiki page ใหม่ (compound)

Wiki = cache; RAG = source-of-truth fallback ทั้งคู่ถูกกว่า, traceable กว่า, compound กว่าใช้ทีเดียว

Sub-agent architecture

Anthropic แนะนำ specialised sub-agents ที่จัดการ task เฉพาะใน clean context window, return condensed summaries (1,000-2,000 tokens) ให้ coordinator. LLM Wiki compose natively:

• Coordinator dispatch sub-agent ต่อ query
• Sub-agent อ่าน wiki (clean context), produce answer
• Sub-agent optionally write wiki page ใหม่ ถ้าเรียนรู้อะไรใหม่
• Coordinator ได้ summary, ไม่ context bloat

Evaluation — รู้ได้ไงว่า wiki แข็งแรง?

5 metrics. Baseline วันนี้, re-check รายเดือน. สุขภาพ wiki observable — ถ้าคุณวัดมัน

LLM Wiki ไม่มี "test set" ธรรมชาติ สุขภาพ observable ผ่าน metrics ที่จับ failure modes จากโมดูล 09

5 metrics

Per-page quality scoring

ต่อ page ที่แก้ใน lint, rate 0-1 บน:

• Cite sources ทุก claim?
• ภายใน consistent?
• Well-structured (frontmatter + sections + relationships)?
• Atomic (1 concept) vs sprawling?

Pages < 0.5 → flag rewrite

Sampling-based provenance audit

ทุก lint pass: เลือก 5 claims สุ่ม verify ด้วยมือว่า cited raw ยังพูดสิ่งนั้น ถ้า 1+ fail — full sweep overdue

สิ่งที่ ไม่ วัด

• Page count — ใหญ่กว่าไม่ได้แข็งแรงกว่า อาจหมายถึง sprawl
• Total words — เหมือนกัน ขนาดที่ถูกขึ้นกับ domain
• "Coverage" ของ sources — cite ทุก raw ไม่ใช่เป้าหมาย sources บางตัวอาจไม่สมควรมี wiki page

Cheatsheet & แหล่งอ้างอิง

หน้าเดียวสรุป — อ่านอะไรต่อ

Quality checklist

พื้นฐาน

• ☐ 3 layers มีครบ (raw/, wiki/, SCHEMA.md)
• ☐ Raw files มี frontmatter (source_url, ingested_at, source_type)
• ☐ Wiki pages ตาม standard template
• ☐ ทุก claim cite raw file พร้อม confidence
• ☐ Wikilinks ใช้ entity IDs ([[concept:foo]])

Operations

• ☐ Ingest touch หลาย pages (rule: 3-10)
• ☐ Query เป็น wiki-first, RAG-fallback
• ☐ Lint รันทุก 10 ingests หรือรายสัปดาห์
• ☐ Provenance audit รายเดือน
• ☐ Supersession ใช้แล้ว — ไม่มี silent deletion

Engineering

• ☐ Schema commit ใน file (ไม่ใช่ chat history)
• ☐ Wiki ใน git
• ☐ Health metrics นิยาม + baseline แล้ว
• ☐ Privacy/secrets rules ชัดเจน + บังคับ
• ☐ Tested ผ่าน human + LLM session อย่างน้อย 1

แหล่งอ้างอิงที่ cite

• Andrej Karpathy — LLM Wiki gist (the seed)
• Lewis et al. — RAG paper (2020)
• Zettelkasten on Wikipedia — บรรพบุรุษ 70 ปี
• Obsidian — Vault concepts
• Anthropic — Effective context engineering for AI agents

เรียนต่ออะไรดี

• Anthropic Memory + context-engineering articles — production agent perspective
• Sönke Ahrens — How to Take Smart Notes — modern Zettelkasten guide
• Obsidian Dataview docs — programmatic queries
• Karpathy gists อื่น — frequent design patterns สำหรับ LLM workflows

Artefact ภายใน

• Wiki Index — 11 หน้ามี citation
• Slides (EN) · Slides (TH)
• English version