← กลับไปที่บล็อก

Markdown Wiki กำลังเข้ามาแทนที่ RAG อย่างเงียบ ๆ นี่คือเหตุผล

· Save Team
ragllmknowledge-basekarpathymcpaisave-vaultmarkdown

สองปีที่ผ่านมา คำตอบมาตรฐานสำหรับ “ฉันจะให้ความรู้แก่ LLM ได้อย่างไร?” คือ RAG สร้างฐานข้อมูลเวกเตอร์ แบ่งเอกสาร embed พวกมัน รัน nearest-neighbor search ตอน query เย็บผลลัพธ์กลับเข้า prompt

มันทำงานได้ ในระดับหนึ่ง ทุกคนที่เคย ship ระบบ RAG รู้จักโหมดความล้มเหลว: chunks ที่สูญเสีย context, embeddings ที่ดึงข้อความผิด, การจัดอันดับที่ทึบแสง, ไม่มี provenance, edge cases แปลก ๆ เมื่อผู้ใช้ถามสิ่งที่ index ไม่ได้ถูก tune ไว้

ในเดือนเมษายน 2026 Andrej Karpathy โพสต์ workflow ที่แทบไม่ทำสิ่งใดจากนั้นเลย และทำงานได้ดีกว่าสำหรับความรู้ส่วนตัว เขาเรียกมันว่า LLM Knowledge Bases สถาปัตยกรรมเป็นแค่โฟลเดอร์ไฟล์ markdown, LLM ที่เข้าถึง filesystem ได้ และนิสัย VentureBeat เรียกมันว่า “ห้องสมุด markdown ที่พัฒนาอยู่และดูแลโดย AI” — คำอธิบายที่จับสิ่งที่ใหม่จริง ๆ

รูปแบบ post-RAG มาถึงแล้ว บทความนี้อธิบายว่ามันคืออะไร ทำไมมันถึงทำงาน และ Save Vault ทำให้เข้าถึงได้โดยไม่ต้องตั้งค่าสำหรับนักพัฒนาได้อย่างไร

RAG พยายามแก้ปัญหาอะไร

ปัญหาเดิม: LLM มี context window ขนาดตายตัว ฐานความรู้ของคุณใหญ่กว่า window ดังนั้นคุณต้องการวิธีดึงส่วนที่เกี่ยวข้องสำหรับแต่ละคำถาม

ในปี 2023 เวกเตอร์เป็นคำตอบที่ชัดเจน Embed ทุกอย่าง ค้นหาด้วย similarity ฉีด k chunks แรก มันผสานได้ดีกับ context window เล็ก ๆ ของ GPT-3.5 และ Claude 1 รูปแบบ “AI startup” ทั้งหมดคือ “RAG เหนือ X”

สามสิ่งเปลี่ยนไป

  1. Context window ระเบิด Claude ออก context 1M token ปีนี้ Gemini และ GPT-5 คล้ายกัน หนึ่งล้าน token คือประมาณ 750,000 คำ — พอที่จะเก็บ wiki ขนาดเล็กไว้ในหน่วยความจำทั้งหมด
  2. Filesystem MCP ออก LLM สามารถเปิดไฟล์บนดิสก์ได้โดยตรง ไม่ต้องการ chunks ที่ pre-indexed พวกมันสามารถนำทาง อ่าน และอ่านซ้ำเหมือนมนุษย์
  3. LLM เก่งขึ้นในการอ่าน Claude Opus 4 สามารถรับไฟล์หลายร้อยไฟล์ในหนึ่ง session และใช้เหตุผลข้ามไฟล์เหล่านั้นอย่างสอดคล้องกัน ปัญหาคอขวดย้ายจาก “คุณภาพการดึงข้อมูล” ไปเป็น “ผู้ใช้ต้องการอะไรจริง ๆ”

เมื่อสามสิ่งนั้นเป็นจริง RAG เริ่มดูเหมือน workaround สำหรับข้อจำกัดที่ไม่มีอีกต่อไป

รูปแบบ Markdown Wiki มีลักษณะอย่างไร

การตั้งค่าของ Karpathy เรียบง่าย:

  1. โฟลเดอร์ raw ทุกหน้าเว็บที่เขาต้องการเก็บถูกบันทึกเป็นไฟล์ .md ในไดเรกทอรี raw/ เขาใช้ Obsidian Web Clipper สำหรับสิ่งนี้
  2. รอบ compile เป็นระยะ ๆ LLM agent (Claude Code ในกรณีของเขา) อ่านทุกอย่างใน raw/ สร้างหน้าแนวคิด เขียนสรุป และสร้าง backlinks ซึ่งผลิต wiki ที่มีโครงสร้างบนวัสดุดิบ
  3. วนรอบ query เมื่อเขามีคำถาม เขาถาม LLM มันค้นหา wiki เปิดไฟล์ที่เกี่ยวข้อง และตอบโดยใช้เนื้อหา
  4. รอบ lint บางครั้ง LLM สแกน wiki เพื่อหาความไม่สอดคล้อง ข้อมูลที่ขาดหาย หรือการเชื่อมต่อใหม่ที่ควรบันทึก

wiki วิจัยปัจจุบันของเขา ~100 บทความและ ~400K คำ เขาถามคำถามที่ซับซ้อนและได้รับคำตอบที่มีแหล่งอ้างอิง

ไม่มีฐานข้อมูลเวกเตอร์ ไม่มีโมเดล embedding ไม่มีกลยุทธ์การแบ่ง chunks ไม่มีการจัดอันดับการดึงข้อมูล แค่ไฟล์ markdown โครงสร้างโฟลเดอร์ และ LLM ที่สามารถอ่านพวกมัน

ทำไมมันทำงานได้ดีกว่า RAG (สำหรับสิ่งนี้)

รูปแบบ wiki มีข้อได้เปรียบเชิงโครงสร้างที่ RAG ไม่สามารถตามทันโดยไม่กลายเป็น wiki เอง

Provenance ฟรี ทุกคำตอบอ้างอิงไฟล์ คุณสามารถเปิดมัน อ่านมัน แก้ไขมัน ลบมัน ไม่มี “embedding บอกอย่างนั้น”

การแก้ไขเป็นเรื่องเล็กน้อย ไฟล์ markdown คือข้อความ เปิดในโปรแกรมแก้ไขใด ๆ แก้การสะกด เพิ่มโน้ต ลบส่วน การ query ครั้งต่อไปสะท้อนการเปลี่ยนแปลงทันที ไม่มีขั้นตอน re-embedding

โครงสร้างสะสม เมื่อ LLM compile wiki มันสร้าง backlinks และหน้าแนวคิด wiki จะ ดีขึ้น ยิ่งคุณบันทึกมาก เพราะ LLM มี context มากขึ้นในการเชื่อมต่อ entries ใหม่ index เวกเตอร์แค่ใหญ่ขึ้น

ความสามารถในการพกพาสมบูรณ์ โฟลเดอร์ไฟล์ .md ทำงานใน Obsidian, VS Code, GitHub, Logseq, vim หรือ cat ฐานข้อมูลเวกเตอร์คือกล่องดำที่คุณต้องการ runtime เฉพาะเพื่ออ่าน

คุณสามารถอ่านเองได้ สิ่งนี้ฟังดูชัดเจน แต่มันคือข้อได้เปรียบที่ใหญ่ที่สุด บางครั้งคุณจะต้องการรู้ว่ามีอะไรอยู่ในฐานความรู้ของคุณ กับ RAG นั่นคือการ query รายงาน กับ markdown มันคือ ls

การแลกเปลี่ยนที่ซื่อสัตย์: RAG ยังชนะเมื่อคุณมีเอกสารหลายล้านรายการ การเข้าถึงแบบ multi-tenant หรือข้อจำกัด latency ที่เข้มงวด (คิดถึง chatbot ลูกค้าสัมพันธ์เหนือ corpus บทความช่วยเหลือหลายล้านรายการ) สำหรับความรู้ส่วนตัว — การอ่าน การวิจัย โดเมนของคุณ — รูปแบบ wiki ดีกว่าอย่างเคร่งครัดแล้ว

ส่วนที่ขาดหายไป: การนำเข้า

รูปแบบของ Karpathy มีสมมติฐานเงียบ ๆ: การนำ markdown ที่สะอาดเข้า raw/ นั้นง่าย สำหรับนักพัฒนาที่ใช้ Obsidian Web Clipper อยู่แล้ว มันก็เป็นอย่างนั้น สำหรับคนอื่น ๆ นี่คือขั้นตอนที่ workflow ตาย

Web Clipper อาจมีปัญหากับหน้าที่มี paywall, ไซต์ที่หนักด้วย JavaScript, เนื้อหาวิดีโอ, X threads, และทุกอย่างที่เป็น dynamic ผู้คนบันทึก HTML ที่ยุ่งเหยิง ยอมแพ้ และสรุปว่า “สิ่งนี้ไม่เหมาะสำหรับฉัน”

ส่วนขยาย Save มีอยู่เพื่อแก้ปัญหาขั้นตอนนี้โดยเฉพาะ มันใช้ Gemini เพื่อดึงเนื้อหาที่สะอาดจากหน้าใด ๆ รวมถึง:

  • บทความหลัง paywalls ที่คุณเข้าถึงได้
  • วิดีโอ YouTube (transcript ครบถ้วน + สรุป AI)
  • X/Twitter threads
  • Instagram reels และ TikTok captions (ถอดความ)
  • การอภิปรายใน Reddit
  • เอกสารที่มี code blocks ไม่เสียหาย
  • SPA แบบ dynamic ที่ clipper ดั้งเดิมติดขัด

คลิกเดียว Markdown ที่สะอาดออกมาอีกด้านหนึ่ง วางลงในโฟลเดอร์

ส่วนที่ขาดหายไปอีกส่วน: การตั้งค่า MCP

รูปแบบของ Karpathy ยังสมมติว่าคุณสามารถกำหนดค่าเซิร์ฟเวอร์ MCP ได้ สำหรับผู้ใช้ Claude Code นี่คือ cd หนึ่งบรรทัด สำหรับทุกคนที่ใช้ Claude Desktop หมายถึงการแก้ไขไฟล์การกำหนดค่า JSON และรีสตาร์ทแอป — และทำ path ให้ถูกต้อง และจำที่จะทำมันใหม่เมื่อคุณย้ายโฟลเดอร์

Save Vault รวมส่วนที่ขาดหายทั้งสองส่วนเข้าในแอปเดียว:

  • ส่วนขยาย Save ป้อน markdown ที่สะอาดเข้า Save Vault โดยอัตโนมัติ
  • Save Vault เขียนไปยัง ~/Documents/Save Vault/ จัดระเบียบเป็นฐานความรู้ (โฟลเดอร์ย่อย)
  • เซิร์ฟเวอร์ MCP ในตัวเปิดเผย list_knowledge_bases, list_files, read_file และ search ให้ Claude
  • การสลับ “เชื่อมต่อกับ Claude” ใน menu bar เชื่อมเซิร์ฟเวอร์ MCP เข้ากับ Claude Desktop และ Claude Code ไม่ต้องแก้ไข JSON

ผลลัพธ์คือรูปแบบ Karpathy ที่ตัดขอบหยาบออก บันทึกหน้า → ลงใน vault → Claude ตอบคำถามเกี่ยวกับมันได้ ไม่มีฐานข้อมูลเวกเตอร์ ไม่มีการแบ่ง chunks ไม่มี embeddings

มีลักษณะอย่างไรในทางปฏิบัติ

ลองจินตนาการว่าคุณกำลังวิจัยคู่แข่ง

วันที่ 1 คุณบันทึกหน้าราคา บล็อกโพสต์สาม รายการ และ Hacker News thread เกี่ยวกับรอบ seed ของพวกเขา ห้าไฟล์ใน Competitors KB

วันที่ 5 คุณถาม Claude: “บริษัทนี้เปลี่ยนแปลงราคาอะไรในปีที่ผ่านมา และลูกค้าตอบสนองอย่างไร?” Claude ค้นหา Competitors KB ของคุณ อ่านไฟล์ที่เกี่ยวข้อง อ้างอิงหน้าราคา ค้นหา sentiment ของ HN thread และตอบ — ทั้งหมดมีแหล่งอ้างอิง

วันที่ 30 คุณมี 40 ไฟล์ใน Competitors, Customers และ AI Research คุณขอให้ Claude compile แต่ละ KB เป็น wiki มันเขียนหน้าแนวคิด เชื่อมโยงพวกมัน ตั้งธงความขัดแย้ง ตอนนี้คุณมี wiki สดสาม อันที่คุณสามารถ query เหมือนเสิร์ชเอนจิน แต่ดีกว่า — เพราะมันเก็บแค่สิ่งที่ คุณ คัดเลือก

วันที่ 90 Wiki ของคุณใหญ่กว่ารายงานนักวิเคราะห์ที่คุณจะซื้อ ทันสมัยกว่าเอกสาร consultant ใด ๆ และเป็นของคุณทั้งหมด ทุกการกล่าวอ้างมีแหล่งอ้างอิงจากไฟล์ที่คุณบันทึก

นี่คือความรู้สึกของฐานความรู้ส่วนตัวจริง ๆ เมื่อ friction หายไป RAG ควรส่งมอบสิ่งนี้แต่ไม่ได้ทำ รูปแบบ Karpathy ทำ — เมื่อส่วน ingestion และ MCP ถูกเชื่อมต่อให้คุณ

ลองทำ

  1. ติดตั้ง Save Chrome extension
  2. ติดตั้ง Save Vault จาก savemarkdown.co
  3. สลับ เชื่อมต่อกับ Claude ใน menu bar
  4. บันทึก 10 สิ่งที่คุณวางแผนจะอ่าน
  5. เปิด Claude และถามคำถามที่เชื่อมพวกมันเข้าด้วยกัน

นั่นคือ workflow post-RAG มันกำลังแทนที่ฐานข้อมูลเวกเตอร์สำหรับความรู้ส่วนตัวอยู่แล้ว สิ่งที่เหลืออยู่คือการเริ่มสร้างของคุณเอง

Save Vault ฟรี ส่วนขยาย Save ฟรีสำหรับ 3 การบันทึกต่อเดือน ไม่จำกัด $5.99/เดือน savemarkdown.co