LLM-Wiki - สร้างคลังความรู้ส่วนตัวด้วย LLM

 (gist.github.com/karpathy)
168 คะแนน โดย GN⁺ 25 일 전 | 15 ความคิดเห็น | แชร์ทาง WhatsApp
  • Andrej Karpathy เพิ่งเปิดเผยว่า ช่วงนี้เขาใช้โทเคนไปกับการ สร้างคลังความรู้ส่วนตัว มากกว่าการเขียนโค้ด และได้เผยแพร่ ไฟล์คู่มือแนวคิด สำหรับสร้างวิกิที่ขับเคลื่อนด้วย LLM นี้
  • เพียงส่งไฟล์นี้ให้เอเจนต์ มันก็จะสร้างวิกิให้เองและแนะนำวิธีใช้งาน
  • เป็นแนวทางที่ LLM เขียนและดูแลวิกิโดยตรง ต่างจาก RAG ที่ดึงข้อมูลจากต้นฉบับใหม่ทุกครั้งเมื่อมีการค้นหา โดยแนวทางนี้สร้าง วิกิถาวร (persistent wiki) ที่ความรู้จะสะสมเพิ่มขึ้นอย่างต่อเนื่อง
  • สามารถเปิดวิกิด้วยเครื่องมืออย่าง Obsidian แล้วให้ LLM แก้ไขและอัปเดตไฟล์ Markdown แบบเรียลไทม์ ขณะที่ผู้ใช้โฟกัสกับการคัดเลือกแหล่งข้อมูลและตั้งคำถาม
  • เมื่อเพิ่มแหล่งข้อมูลใหม่ LLM จะอ่านเนื้อหาแล้วผสานเข้ากับวิกิเดิมพร้อมเชื่อมโยงข้ามหน้า และการประมวลผลแหล่งข้อมูลเพียงหนึ่งชิ้นอาจอัปเดตหน้าวิกิได้ 10~15 หน้า
  • ใช้ได้กับทุกด้านที่ ความรู้สะสมตามกาลเวลา เช่น สุขภาพส่วนตัว การจัดการเป้าหมาย งานวิจัย บันทึกการอ่าน หรือวิกิภายในทีม
  • ลด ต้นทุนงานดูแลบันทึก ซึ่งเป็นอุปสรรคสำคัญของการดูแลวิกิ ให้เกือบเป็นศูนย์ด้วย LLM จึงช่วยแก้ปัญหาที่ทำให้หลายคนเลิกดูแลวิกิไป

แนวคิดหลัก

  • วิธีใช้เอกสารกับ LLM ส่วนใหญ่คือ RAG (Retrieval-Augmented Generation): อัปโหลดชุดไฟล์แล้วให้ LLM ค้นหาช่วงข้อความที่เกี่ยวข้องเมื่อมีคำถาม จากนั้นจึงสร้างคำตอบ
    • NotebookLM, การอัปโหลดไฟล์ใน ChatGPT และระบบ RAG ส่วนใหญ่ทำงานแบบนี้
    • เป็นการสกัดความรู้ใหม่ทุกครั้ง โดย ไม่มีการสะสมความรู้
  • แนวทางของ LLM-Wiki แตกต่างออกไป: แทนที่ LLM จะค้นจากต้นฉบับโดยตรง มันจะ ค่อย ๆ สร้างและดูแลวิกิถาวร
    • เมื่อเพิ่มแหล่งข้อมูลใหม่ LLM จะอ่านเนื้อหา สกัดสาระสำคัญ และผสานเข้ากับวิกิเดิม
    • อัปเดตหน้าเอนทิตี ปรับสรุปหัวข้อ ระบุความขัดแย้งกับข้ออ้างเดิม และเสริมการสังเคราะห์ข้อมูล
  • วิกิคือ ผลลัพธ์แบบถาวรที่เติบโตทบต้น (persistent, compounding artifact): มีการเชื่อมโยงข้ามหน้าพร้อมแล้ว มีการระบุความขัดแย้งแล้ว และสะท้อนการสังเคราะห์ข้อมูลไว้แล้ว
  • ตัวอย่างการใช้งานจริง: เปิด LLM agent ไว้ด้านหนึ่ง และเปิด Obsidian ไว้อีกด้าน เพื่อดูการแก้ไขที่ LLM ทำแบบเรียลไทม์
    • Obsidian = IDE, LLM = โปรแกรมเมอร์, วิกิ = codebase

การนำไปใช้

  • ส่วนบุคคล: ติดตามเป้าหมาย สุขภาพ จิตใจ การพัฒนาตนเอง — รวบรวมบันทึกประจำวัน บทความ และโน้ตจากพอดแคสต์ มาสร้างเป็นบันทึกตัวตนที่มีโครงสร้าง
  • งานวิจัย: อ่านงานวิจัย บทความ และรายงานตลอดหลายสัปดาห์ถึงหลายเดือน แล้วสร้างวิกิที่ครอบคลุมและสะท้อนข้อเสนอที่พัฒนาไปเรื่อย ๆ
  • การอ่านหนังสือ: สรุปทีละบท พร้อมสร้างหน้าแยกสำหรับตัวละคร ธีม และเส้นเรื่อง — ผู้อ่านทั่วไปสามารถสร้างหน้าที่เชื่อมโยงกันนับพันหน้าได้แบบ Tolkien Gateway
  • ธุรกิจ/ทีม: ใช้ Slack thread, บันทึกการประชุม เอกสารโปรเจกต์ และการคุยกับลูกค้า เพื่อสร้างวิกิภายในที่ LLM ดูแลรักษา
  • นอกจากนี้ยังใช้ได้กับการวิเคราะห์คู่แข่ง due diligence การวางแผนเดินทาง โน้ตการเรียน หรือการศึกษางานอดิเรกเชิงลึก รวมถึง ทุกด้านที่ความรู้มีการสะสม

สถาปัตยกรรม (3 เลเยอร์)

  • แหล่งข้อมูลต้นฉบับ (Raw sources): ชุดเอกสารต้นทางที่คัดเลือกไว้ — เช่น บทความ งานวิจัย รูปภาพ ไฟล์ข้อมูล
    • เปลี่ยนแปลงไม่ได้ (immutable) โดย LLM อ่านได้อย่างเดียวและไม่แก้ไข
    • เลเยอร์นี้คือ แหล่งความจริง (source of truth)
  • วิกิ (The wiki): ไดเรกทอรีของไฟล์ Markdown ที่ LLM สร้างขึ้น — รวมสรุป หน้าเอนทิตี หน้าคอนเซปต์ การเปรียบเทียบ ภาพรวม และการสังเคราะห์
    • LLM เป็นเจ้าของเลเยอร์นี้ทั้งหมด: สร้างหน้า อัปเดตเมื่อมีแหล่งข้อมูลใหม่ และดูแลการเชื่อมโยงข้ามหน้า
    • ผู้ใช้อ่านอย่างเดียว ส่วน LLM เป็นผู้เขียน
  • สคีมา (The schema): เอกสารตั้งค่าที่บอก LLM ถึงโครงสร้าง คอนเวนชัน และเวิร์กโฟลว์ของวิกิ (เช่น CLAUDE.md สำหรับ Claude Code และ AGENTS.md สำหรับ Codex)
    • เป็นไฟล์ตั้งค่าหลักที่ทำให้ LLM กลายเป็น ผู้จัดการวิกิอย่างเป็นระบบ แทนแชตบอตทั่วไป
    • ผู้ใช้และ LLM สามารถร่วมกันพัฒนาไฟล์นี้ไปตามเวลา

งานหลัก (Operations)

  • Ingest: เพิ่มแหล่งข้อมูลใหม่เข้าไปในชุดต้นฉบับ แล้วสั่งให้ LLM ประมวลผล
    • LLM จะอ่านแหล่งข้อมูล → พูดคุยสาระสำคัญ → เขียนหน้าสรุปลงวิกิ → อัปเดตดัชนี → อัปเดตหน้าเอนทิตี/คอนเซปต์ที่เกี่ยวข้อง → เพิ่มรายการในล็อก
    • แหล่งข้อมูลหนึ่งชิ้นอาจส่งผลต่อ หน้าวิกิ 10~15 หน้า
    • จะทำทีละแหล่งข้อมูลพร้อมมีส่วนร่วมใกล้ชิด หรือปล่อยให้ทำแบบชุดใหญ่โดยลดการกำกับดูก็ได้
  • Query: ถามคำถามกับวิกิ แล้วให้ LLM หาเพจที่เกี่ยวข้องและสังเคราะห์คำตอบพร้อมการอ้างอิง
    • คำตอบอาจอยู่ในรูปหน้า Markdown, ตารางเปรียบเทียบ, slide deck (Marp), กราฟ (matplotlib), canvas และรูปแบบอื่น ๆ
    • คำตอบที่ดีสามารถบันทึกกลับเข้าไปเป็นหน้าใหม่ในวิกิได้ — การสำรวจเองก็กลายเป็นส่วนหนึ่งของฐานความรู้
  • Lint: ให้ LLM ตรวจสุขภาพวิกิเป็นระยะ
    • รายการตรวจ ได้แก่ ความขัดแย้งระหว่างหน้า ข้ออ้างเก่าที่ถูกแทนที่โดยแหล่งข้อมูลล่าสุด หน้า orphan ที่ไม่มีลิงก์เข้ามา คอนเซปต์สำคัญที่ยังไม่มีหน้าของตัวเอง การเชื่อมโยงข้ามหน้าที่ขาดหาย และช่องว่างของข้อมูลที่เติมได้ด้วยการค้นเว็บ

การทำดัชนีและการบันทึกล็อก

  • index.md: ไฟล์ศูนย์กลางของเนื้อหา — ทำแคตตาล็อกทุกหน้าของวิกิพร้อมลิงก์ สรุปหนึ่งบรรทัด และเมทาดาทา
    • LLM จะอ่านดัชนีก่อนเมื่อมีการตอบคำถาม แล้วจึงไปสำรวจหน้าที่เกี่ยวข้อง
    • ทำงานได้ดีในระดับ แหล่งข้อมูลประมาณ ~100 ชิ้น และหลายร้อยหน้า โดยไม่ต้องมีโครงสร้าง RAG แบบใช้ embeddings
  • log.md: บันทึกตามลำดับเวลา — จดประวัติ ingest, query และการผ่าน lint ตามลำดับ
    • หากเขียน prefix ของแต่ละรายการให้สม่ำเสมอ ก็สามารถ parse ด้วยเครื่องมือ Unix ได้
      • ตัวอย่าง: ## [2026-04-02] ingest | Article Title → ใช้ grep "^## \[" log.md | tail -5 เพื่อตรวจดู 5 รายการล่าสุด

เครื่องมือ CLI ทางเลือก

  • เมื่อวิกิเติบโตขึ้น อาจสร้างเครื่องมือขนาดเล็กเพื่อให้ LLM ทำงานได้มีประสิทธิภาพมากขึ้น
  • qmd: search engine แบบโลคัลสำหรับไฟล์ Markdown — รองรับการค้นหาแบบไฮบริด BM25/เวกเตอร์และ LLM reranking ทั้งหมดทำงานบนอุปกรณ์
    • รองรับทั้ง CLI (ให้ LLM เรียก shell ออกไปได้) และ MCP server (ให้ LLM ใช้เป็นเครื่องมือแบบเนทีฟได้)
  • ถ้าขนาดยังเล็ก ไฟล์ดัชนีอย่างเดียวก็เพียงพอ และหากจำเป็นก็สามารถให้ LLM ช่วยเขียนสคริปต์ค้นหาแบบง่ายขึ้นมาเองได้

เคล็ดลับและการใช้เครื่องมือ

  • Obsidian Web Clipper: ส่วนขยายเบราว์เซอร์ที่แปลงบทความบนเว็บเป็น Markdown — มีประโยชน์สำหรับเพิ่มแหล่งข้อมูลเข้าชุดต้นฉบับอย่างรวดเร็ว
  • การเก็บรูปภาพไว้ในเครื่อง: ไปที่ Obsidian Settings → Files and links เพื่อตั้งค่าเส้นทางโฟลเดอร์แนบไฟล์ แล้วสามารถใช้คีย์ลัดบันทึกรูปลงดิสก์ในเครื่องได้
    • LLM ไม่สามารถอ่านข้อความ Markdown ที่มีรูป inline ได้ทั้งหมดในครั้งเดียว จึงควรอ่านตัวข้อความก่อนแล้วค่อยดูรูปแยกต่างหาก
  • Obsidian Graph View: เหมาะที่สุดสำหรับดูภาพรวมทั้งวิกิ — ตรวจสอบความเชื่อมโยง หน้า hub และหน้า orphan
  • Marp: ฟอร์แมต slide deck ที่ใช้ Markdown — มีปลั๊กอินสำหรับ Obsidian และสามารถสร้างงานนำเสนอจากเนื้อหาในวิกิได้โดยตรง
  • Dataview: ปลั๊กอิน Obsidian สำหรับรัน query กับ page frontmatter — หาก LLM เพิ่ม YAML frontmatter (แท็ก วันที่ จำนวนแหล่งข้อมูล) ก็จะสร้างตารางและลิสต์แบบไดนามิกได้
  • วิกิคือ git repository ของไฟล์ Markdown — ได้ทั้งประวัติเวอร์ชัน การแตก branch และการทำงานร่วมกันแบบฟรี

หลักการทำงาน

  • อุปสรรคหลักของการดูแลฐานความรู้ไม่ใช่การอ่านหรือการคิด แต่คือ งานดูแลบันทึก (bookkeeping): การอัปเดตการเชื่อมโยงข้ามหน้า การทำสรุปให้ทันสมัย การระบุความขัดแย้ง และการรักษาความสอดคล้องกันในหลายสิบหน้า
  • เหตุผลที่คนเลิกใช้วิกิคือ ภาระการดูแลเติบโตเร็วกว่าคุณค่าที่ได้รับ
  • LLM ไม่เบื่อ ไม่ลืมอัปเดตการเชื่อมโยงข้ามหน้า และจัดการ 15 ไฟล์พร้อมกันได้ → ต้นทุนการดูแลจึงเข้าใกล้ศูนย์อย่างมาก
  • แนวคิดนี้มีความเกี่ยวข้องเชิงจิตวิญญาณกับ Memex (1945) ของ Vannevar Bush: เป็นคลังความรู้ส่วนตัวที่มีการคัดสรรอย่างกระตือรือร้น และการเชื่อมโยงระหว่างเอกสารมีคุณค่าไม่แพ้ตัวเอกสารเอง
    • ปัญหาเรื่อง "ใครจะเป็นคนดูแล" ที่ Bush แก้ไม่ได้ LLM เข้ามารับหน้าที่นี้

ลักษณะของเอกสารนี้

  • เอกสารนี้ตั้งใจเขียนให้เป็นนามธรรม — เป้าหมายคือสื่อสารแนวคิด ไม่ใช่บังคับใช้ implementation แบบใดแบบหนึ่ง
  • รายละเอียดอย่างโครงสร้างไดเรกทอรี คอนเวนชันของสคีมา รูปแบบหน้า หรือเครื่องมือ จะแตกต่างกันไปตามโดเมน ความชอบ และ LLM ที่ใช้
  • ทุกองค์ประกอบเป็นแบบทางเลือกและโมดูลาร์ — ใช้เฉพาะสิ่งที่จำเป็น และละสิ่งที่ไม่ต้องการได้
  • แนะนำให้ แชร์กับ LLM agent แล้วค่อยร่วมกันปรับให้เป็นเวอร์ชันที่เหมาะกับความต้องการของตนเอง

บทความที่เกี่ยวข้อง

15 ความคิดเห็น

 
xguru 25 일 전

นี่เป็นตัวอย่างการนำไปใช้: Farzapedia: Wikipedia ส่วนตัวที่สร้างจากไดอารี บันทึก และข้อความ 2,500 รายการ

  • ใช้ LLM ป้อนข้อมูลจากไดอารี, Apple Notes และบทสนทนา iMessage จำนวน 2,500 รายการ แล้วสร้างบทความวิกิแบบละเอียด 400 หน้าโดยอัตโนมัติ
  • ครอบคลุมทั้งเพื่อน สตาร์ทอัพ สาขาวิจัยที่สนใจ อนิเมะที่ชอบและอิทธิพลของมัน พร้อม เชื่อมโยงถึงกันด้วย backlink
  • วิกินี้ไม่ได้ออกแบบมาเพื่อให้อ่านโดยมนุษย์เท่านั้น แต่เป็น knowledge base สำหรับเอเจนต์ โดยจัดโครงสร้างไฟล์และ backlink ให้เหมาะกับการที่เอเจนต์จะ crawl
  • เชื่อม Claude Code เข้ากับวิกิ และใช้ index.md เป็นจุดเริ่มต้น เพื่อให้เวลา query เอเจนต์สามารถไล่สำรวจหน้าที่จำเป็นได้เอง
  • ตัวอย่างการใช้งาน: เวลาทำหน้า landing page ใหม่ ถ้าขอว่า "ช่วยเสนอไอเดีย copy และดีไซน์โดยอ้างอิงจากภาพและภาพยนตร์ที่สร้างแรงบันดาลใจให้ฉันช่วงหลัง" เอเจนต์จะรวบรวมข้อมูลจากเอกสาร "ปรัชญา" ที่อิงสารคดี Studio Ghibli, เอกสาร "คู่แข่ง" ที่มีสกรีนช็อต landing page ของบริษัท YC ตลอดจนภาพสินค้าที่ระลึก Beatles จากยุค 1970 ที่เก็บไว้ แล้วสรุปคำตอบให้
  • เมื่อ 1 ปีก่อนเคยสร้างระบบคล้ายกันด้วย RAG แต่ ประสิทธิภาพไม่ดีนัก และพบว่าวิธีที่ให้เอเจนต์สำรวจผ่านไฟล์ระบบโดยตรงมีประสิทธิภาพกว่ามาก
  • เมื่อเพิ่มรายการใหม่เข้าไป เช่น บทความ ภาพแรงบันดาลใจ หรือโน้ตการประชุม ระบบจะ อัปเดตเอกสารเดิมที่เกี่ยวข้อง 2~3 หน้าโดยอัตโนมัติ หรือสร้างเอกสารใหม่

ข้อดี 4 ประการของการทำ personalization ด้วย LLM Wiki ที่ Karpathy อธิบาย

  • ยก Farzapedia ข้างต้นเป็นตัวอย่างใช้งานจริงที่ดีของแนวคิด LLM Wiki และสรุปข้อดีของแนวทางนี้ไว้ 4 ข้อ เมื่อเทียบกับวิธี personalization แบบ AI เดิมที่ว่า "ยิ่งใช้ก็ยิ่งดีขึ้นเอง"
  • ความชัดเจน (Explicit): ผลลัพธ์ของ memory มีอยู่เป็นวิกิอย่างชัดเจน สามารถตรวจสอบและจัดการได้โดยตรงว่า AI รู้อะไรหรือไม่รู้อะไร — ความรู้ไม่ได้ถูกฝังอยู่ในระบบภายในที่มองไม่เห็น แต่ อยู่ในรูปแบบที่มองเห็นได้จริง
  • ความเป็นเจ้าของข้อมูล (Yours): ข้อมูลถูกเก็บไว้ใน คอมพิวเตอร์เครื่องตัวเอง ไม่ได้อยู่ในระบบของผู้ให้บริการ AI รายใด และไม่ถูกล็อกให้อยู่ในรูปแบบที่ดึงออกไม่ได้ จึงยังคงควบคุมข้อมูลได้อย่างสมบูรณ์
  • ไฟล์มาก่อนแอป (File over app): memory ประกอบด้วย ชุดไฟล์ในฟอร์แมตมาตรฐาน เช่น Markdown และรูปภาพ จึงใช้ร่วมกับเครื่องมือและ CLI ต่าง ๆ ได้ — เอเจนต์สามารถใช้ชุดเครื่องมือ Unix ได้ทั้งหมด และผู้ใช้ก็เปิดดูผ่านอินเทอร์เฟซที่ต้องการ เช่น Obsidian ได้
  • อิสระในการเลือก AI (BYOAI): สามารถ เชื่อมต่อ AI ที่ต้องการได้อย่างอิสระ ไม่ว่าจะเป็น Claude, Codex หรือ OpenCode — ในทางหลักการยังสามารถ fine-tune AI โอเพนซอร์สด้วยวิกิเหล่านี้ เพื่อให้ไม่ได้แค่อ้างอิงข้อมูล แต่ ฝังความรู้ส่วนตัวลงไปใน weights เอง ได้ด้วย
  • วิธีนี้ไม่ใช่วิธีที่ง่ายที่สุด และยังต้องมีการจัดการ file directory แต่เอเจนต์สามารถช่วยงานส่วนนี้ได้มากพอสมควร
  • เขาย้ำว่า "ความสามารถในการใช้เอเจนต์ (agent proficiency) คือทักษะแกนหลักของศตวรรษที่ 21" พร้อมแนะนำให้ลองสัมผัสเครื่องมือที่รับคำสั่งเป็นภาษาอังกฤษแล้วทำงานบนคอมพิวเตอร์แทนเราได้ด้วยตัวเอง
 
dkmin 24 일 전

ขอบคุณที่แชร์ครับ ผมลองรันดูแล้ว น่าทึ่งมาก
คาดว่าในคอมมูนิตี้น่าจะมีวิธีที่พัฒนาต่อยอดออกมาอีกเรื่อย ๆ
 
kurthong 23 일 전

ผมก็ลองทำดูแล้วเหมือนกัน ตอนที่ใช้อุปกรณ์หลายเครื่องอยู่ ผมเพิ่มส่วนเล็กน้อยเพื่อให้เชื่อม Obsidian vault กับการสำรองข้อมูลบน GitHub ได้ และยังทำ parser สำหรับ Codex กับ Gemini ใส่ไว้ด้วยครับ https://github.com/hang-in/seCall
 
kuthia 21 일 전

ดูเรียบร้อยดีนะ
 
trpgfox 22 일 전

ว้าว ตอนแรกอ่านเนื้อหาแล้วก็ยังรู้สึกมืดแปดด้านอยู่ แต่พออ้างอิง Git นี้แล้วก็เริ่มมองเห็นแนวทางขึ้นมาเลย ขอบคุณมากจริง ๆ
 
kurthong 23 일 전

เนื่องจาก bm25 ค่อนข้างอ่อนในการค้นหาภาษาเกาหลี ผมจึงได้ใส่การ์ดเรลแยกต่างหากที่สามารถค้นหาภาษาเกาหลีได้ดีไว้ด้วย
 
GN⁺ 25 일 전
ความคิดเห็นจาก Hacker News

  • แนวทางนี้ดูเหมือนสุดท้ายจะนำไปสู่ model collapse
    ถ้าดูจากงานวิจัยของ Nature ยิ่ง LLM เขียนเอกสารมากเท่าไร คุณภาพก็ยิ่งเสื่อมสะสมลง โดยค่อย ๆ เขียนข้อมูลเดิมที่ถูกต้องใหม่ให้กระชับน้อยลง
    น่าแปลกใจที่ Karpathy มองไม่เห็นปัญหานี้ พวกหัวสุดโต่งสาย AI ให้ความรู้สึกเหมือนสูญเสีย ‘สามัญสำนึก’ บางอย่างไป
    เวลาที่เริ่มอยากเน้น “ซอสสูตรลับที่ฉันเขียนเอง” มากกว่าสิ่งที่ LLM สร้างขึ้น ก็ควรถามตัวเองว่าทำไมถึงเป็นแบบนั้น

    • บทความนั้นไม่ได้พูดถึงการ ฝึก LLM แต่เป็นการใช้โมเดลที่ฝึกเสร็จแล้วอย่าง ChatGPT หรือ Claude มาเขียนวิกิส่วนตัว
    • คอมเมนต์ของ Karpathy หายไปเพราะโดนแฟล็ก ซึ่งเป็นการคัดลอกย่อหน้ายาวเชิงเยาะเย้ยที่ Claude เขียนมาแปะตรง ๆ
      ผิดหวังที่เขาตอบสนองแบบนั้น ทำให้นึกถึงคำว่า “ถ้าพูดแบบมนุษย์ไม่ได้ ก็อย่าพูดเสียดีกว่า”
      คนฉลาดจำนวนมากดูเหมือนกำลังเห็น ‘ผีในเครื่องจักร’ แล้วค่อย ๆ สูญเสียสัมผัสแบบมนุษย์ไป
      บทความ “I Saw Something New in San Francisco” ของ Ezra Klein ชี้ปรากฏการณ์นี้ได้ดี
    • ผมเคยลองทำ self-updating HTML file และพบว่าด้วยพรอมป์ตง่าย ๆ แบบในรีโพนี้ ก็ทำงานได้ค่อนข้างดีโดยไม่เกิดลูปวน
    • จากประสบการณ์ของผม LLM แค่จะ ดูแล claude.md ไฟล์เดียวให้ดี ยังทำไม่ได้เลย ทั้งวิกินี่ยิ่งเป็นไปไม่ได้

  • ผมกำลังทำอะไรคล้ายกันด้วยแนวทางแบบ เน้นการจัดการ
    โดยเชื่อมความทรงจำทั่วทั้ง workspace เข้ากับ task หรือโปรเจกต์ และควบคุมแบบเรียลไทม์ผ่านอินเทอร์เฟซ SPA
    ดูได้ที่โปรเจกต์ hmem
    ผมเคยพยายามให้โมเดลสลับเข้าโหมดวิจัยเพื่อจัดระเบียบความรู้ภายใน แต่สุดท้ายมันก็มั่วเหมือน LLM soup
    สำหรับโปรเจกต์เขียนโค้ด สิ่งที่ได้ผลที่สุดคือ requirement ที่ชัดเจน การปรับปรุงแบบวนรอบ และโค้ดที่มีเอกสารกำกับดี ถ้าความทรงจำมากเกินไปกลับยิ่งเพิ่มข้อผิดพลาด

  • ท้ายที่สุดแล้วนี่ดูเหมือนเป็นการ เลื่อนปัญหาออกไป
    ถ้าจะคงวิกิไว้ LLM ก็ต้องกลับมาอ่านวิกิแทนต้นฉบับทุกครั้ง และระหว่างทางข้อผิดพลาดชั้นที่สองก็จะสะสม
    ผมกลับคิดว่าถ้ามี โมเดลรุ่นถัดไป ที่มี 10M context หรือระดับ 1000tps ออกมา แนวทางแบบนี้ก็คงหมดความหมาย

    • ตอนนี้ก็มีโมเดล 1M context แล้ว แต่พอราว 200k~300k token ก็เริ่มเกิด memory loss แล้ว ต่อให้เป็น 10M context ข้อจำกัดพื้นฐานก็ยังเหมือนเดิม
    • ผมสร้าง ระบบบน Obsidian ใช้เองและครอบด้วยสคีมาที่มีโครงสร้าง
      เลเยอร์กลางนี้มีประโยชน์มากในการจับเจตนาการออกแบบและดู ช่องว่าง ระหว่างมันกับ implementation จริง
      ผมมองว่าระบบอัตโนมัติแบบอ้างอิงตัวเองเต็มรูปแบบไม่มีคุณค่า คุณค่าที่แท้จริงอยู่ที่โครงสร้างซึ่งมนุษย์เข้าไปแทรกแซงได้ว่า “สิ่งนี้ควรทำงานแบบนี้”
      สุดท้ายการทดลองแบบนี้ก็น่าสนใจ แต่ ไม่มีความหมายในทางปฏิบัติ เพราะผู้ให้บริการโมเดลขนาดใหญ่พัฒนาเร็วกว่าเยอะ ตอนนี้ใช้แบบพื้นฐานที่เรียบง่ายน่าจะดีกว่า
    • ตรรกะที่ว่า “โมเดลรุ่นหน้าจะแก้ทุกอย่าง” ก็จริง แต่ถ้าเชื่อแบบนั้นก็จะ ไม่สร้างอะไรเลย
    • เป้าหมายไม่ใช่การเก็บทุก context ไว้ทั้งหมด แต่คือการสร้าง memory ที่ query ได้ คล้าย data lake สำหรับไอเดีย
    • ตอนนี้มันใช้สรุปงานวิจัยน่าสนใจไม่กี่ชิ้น แต่ในอนาคตอาจกลายเป็น เครื่องมือควบแน่นความรู้ ที่ย่อทั้งสาขาให้เหลือไม่กี่ชิ้นงานได้

  • ไอเดียนี้ทำให้นึกถึงบทความ “Man-Computer Symbiosis” ของ Licklider ในปี 1960
    เป็นแนวคิดเรื่อง Intelligence Amplification ที่มนุษย์ตั้งเป้าหมาย ส่วนคอมพิวเตอร์แปลงสมมติฐานเป็นโมเดลเพื่อตรวจสอบ และรับหน้าที่คำนวณซ้ำ ๆ
    ดูลิงก์ต้นฉบับได้

    • เขาคาดการณ์แนวคิดเรื่อง จอแสดงผลสำหรับการทำงานร่วมกัน ไว้แล้วด้วย เช่น จินตนาการถึงการโต้ตอบที่คนวาดกราฟด้วยมือ แล้วคอมพิวเตอร์รับรู้และแสดงผลในรูปแบบที่ขัดเกลาขึ้นทันที

  • มีรายชื่อระบบที่ทำไอเดียใกล้เคียงกันอยู่ที่นี่
    ผมดูแล ฐานความรู้ที่ขับเคลื่อนด้วย LLM ชื่อว่า commonplace
    ระบบนี้ออกแบบมาให้ LLM อ่านและรันทฤษฎีได้โดยตรง จึงเป็นโครงสร้างแบบ ทฤษฎีก็คือ runtime
    มันยังดิบอยู่ แต่เข้ากับวิธีทำงานของผมได้ดี

  • ผมเคยทำเครื่องมือคล้ายกันแต่สำหรับ codebase โดยเฉพาะ
    llmdoc จะตรวจจับการเปลี่ยนแปลงของไฟล์ด้วยแฮช แล้วให้ LLM แคชสรุป เป็นแอสเซ็ตเดี่ยวที่อธิบายแต่ละไฟล์
    เข้าถึงได้ผ่าน CLI และช่วยให้การสำรวจโค้ดเร็วขึ้นมาก

  • นี่แทบจะเป็นโครงสร้างแบบ RAG
    แม้จะไม่มี vector DB แต่ในแง่ที่มันสร้างดัชนีความเชื่อมโยงเชิงความหมายและวางโครงสร้างแบบลำดับชั้นเพื่อช่วยค้นหา ก็ถือว่าเหมือนกัน
    ผมกำลังทำโปรเจกต์ atomic ซึ่งเป็น AI knowledge base ที่ใช้ไอเดียคล้ายกับการสังเคราะห์วิกิ

    • RAG ไม่ได้จำเป็นต้องมี embedding เสมอไป แค่ค้นหาด้วย grep ธรรมดาก็พอทำได้
    • สำหรับ KB ส่วนตัว ผมคิดว่าชุดผสม Multimodal KB + Agentic RAG เหมาะที่สุด
      เช่น DocMason ที่ดึงไดอะแกรมจาก PPT หรือ Excel ออกมาให้เอเจนต์อย่าง Codex วิเคราะห์
    • มองว่าเป็นแค่ “RAG เฉย ๆ” ก็คงไม่ถูกนัก เพราะที่นี่ LLM เขียนและดูแลวิกิเองโดยตรง สร้าง backlink และตรวจหาความไม่สอดคล้อง
      มันใกล้เคียงกับ การสังเคราะห์ความรู้ มากกว่าการค้นคืนข้อมูล เหมือน LLM กำลังจัดการ Zettelkasten ของตัวเอง
      โปรเจกต์นี้น่าสนใจมาก ผมตั้งใจว่าจะไปดูแน่นอน
    • ถ้าเริ่มต้นด้วยคำว่า “ผมมีข้อสงสัยอยู่สองสามอย่าง” น่าจะดีกว่า
      ผมเองก็คิดเรื่องแนวคิด LLM-WIKI มานานแล้ว แต่ OP ดูจะขุดลึกกว่าเยอะ หวังว่ามันจะพัฒนาเป็น สมองที่สอง ได้จริง
    • จริง ๆ แล้วมันคล้ายกับ ไฟล์ custom instruction ของ Copilot
      เหมือนเอกสาร copilot-instructions.md ที่เป็นโครงสร้างเก็บคำสั่งให้ LLM อ้างอิง

  • ผมก็เคยลองทำอะไรคล้ายกันในโปรเจกต์บริษัท
    พอหมดไฟและต้องดูแลคนในครอบครัวจนสมาธิลดลง ผมก็โยนงานหลายส่วนให้กับ multi-agent workflow
    มันทำงานโดยมีวิกิมาร์กดาวน์บน Obsidian เป็นศูนย์กลาง แต่สุดท้ายก็เกิด หนี้เทคนิคแบบใหม่ ขึ้นมา — เหมือนสมองหายไปบางส่วน
    ถึงอย่างนั้น workflow แบบวิกินี้ก็ติดหนึบจนหยุดยาก

    • ผมก็กลัวเหมือนกันว่าจะสูญเสีย ความสามารถในการคิดลึก
    • ไม่ได้ทำผิดอะไรหรอก แค่พอเกินระดับความซับซ้อนหนึ่งไป เอเจนต์จะดูแลวิกิไม่ไหว และนักพัฒนาก็จะมองภาพรวมไม่ออกเหมือนกัน
    • คุณค่าที่แท้จริงของการเขียนเอกสารไม่ได้อยู่ที่ผลลัพธ์ แต่คือ กระบวนการเขียนที่ช่วยจัดระเบียบความคิด
      ต่อให้ LLM สร้างผลลัพธ์ได้ดีแค่ไหน สำหรับวิกิส่วนตัว กระบวนการนั้นสำคัญกว่า
    • ถ้าอยากได้เวลากลับมาคิดอีกครั้ง แนะนำให้มี งานอดิเรกแบบออฟไลน์
      ผมชอบเดินเล่นหรือว่ายน้ำโดยไม่พกโทรศัพท์เพื่อปล่อยหัวให้โล่ง ความเหนื่อยทางกายกับความเหนื่อยทางใจเป็นคนละอย่างกัน เลยช่วยได้

  • ดีใจที่แนวทางแบบนี้เริ่มได้รับความสนใจ
    แต่พอเอาเอกสารมาปนกับ ข้อมูลที่มีโครงสร้าง อย่าง task item หรือ ADR การ query ด้วยมาร์กดาวน์อย่างเดียวจะยาก
    วิธีแบบ AGENTS.md แก้ด้วยการให้ LLM เรียนรู้กฎของโฟลเดอร์ แต่พอข้อมูลซับซ้อนขึ้นก็เริ่มตัน
    เพราะงั้นผมเลยกำลังพัฒนา Binder
    มันเก็บข้อมูลไว้ในฐานข้อมูลเชิงโครงสร้าง แต่เรนเดอร์ออกมาเป็น มาร์กดาวน์ที่ซิงก์สองทาง
    พร้อมให้ autocomplete และ validation ผ่าน LSP และเอเจนต์หรือสคริปต์ก็เข้าถึงข้อมูลชุดเดียวกันได้ผ่าน CLI หรือ MCP

  • ผมสร้าง AS Notes สำหรับ VS Code ขึ้นมา
    ดูได้ที่ asnotes.io
    มันรวมความสามารถของระบบจัดการความรู้ส่วนบุคคลเข้ากับ VS Code ทำให้เขียน เชื่อมโยง และอัปเดตมาร์กดาวน์กับ wikilink ได้ง่าย
    รองรับการเรนเดอร์ mermaid และ LaTeX ด้วย
    ทำแบบนี้แล้วสามารถ เก็บผลลัพธ์จากบทสนทนา AI ไว้ถาวร ในรูปแบบมาร์กดาวน์ได้ เลยให้ความรู้สึกว่ามีคุณค่ามากกว่า Copilot ธรรมดา
 
stadia 24 일 전

หลังจากเริ่มต้นด้วยการตั้งค่า Vault พื้นฐานแบบเรียบ ๆ ที่แทบไม่มีอะไร แล้วให้มันอ่านไฟล์นั้นไฟล์เดียว จากนั้นพอผมบอกว่าอยากทำไอเดียนี้ให้เป็นรูปธรรม ก็ได้วางโครงทั้งหมดร่วมกับทักษะระดมสมองของ superpowers และตั้งค่าทั้ง CLAUDE.md กับปลั๊กอิน Obsidian จนเสร็จเรียบร้อยแล้ว
 
sudoeng 24 일 전

ไอเดียที่จะนำไปใช้ในลักษณะคลังความรู้ส่วนตัวแบบนี้ ผมก็รู้สึกว่าน่าสนใจเหมือนกันครับ
แต่ก็ยังไม่แน่ใจว่า AI จะรับมือกับบริบทของวิกิที่ค่อย ๆ สะสมเพิ่มขึ้นเรื่อย ๆ ได้หรือเปล่า
 
kurthong 23 일 전

ในภาพรวมใหญ่ มันคือการค้นหาบทสนทนาในอดีต ดังนั้นถ้าจัดระเบียบประเด็นเรื่องการสรุปให้ดี ก็ดูเป็นไอเดียที่ดีครับ ในทางปฏิบัติ ผมเองก็มองว่ามันช่วยได้มากในการจัดระเบียบโปรเจกต์ด้วย
 
huturufu 24 일 전

สิ่งที่ฉันกำลังจะทำใน openclaw ดันมีออกมาแล้วนี่นา ต้องเอามาใช้ซะแล้ว
 
junghan0611 24 일 전

ในที่สุดก็มาถึงหัวข้อนี้จนได้สินะครับ ผมเฝ้าบ่มเพาะสวนและสร้างฮาร์เนสในหัวข้อนี้มาเป็นเวลานาน เลยยิ่งรู้สึกยินดีมากเป็นพิเศษ เคล็ดลับของอาจารย์ Karpathy น่าสนใจมาก สำหรับ PKM เอง ดูเหมือนว่ามากกว่าความยากของเทคโนโลยี มันคือกระบวนการที่แต่ละคนสั่งสม จัดโครงสร้าง และแบ่งปันกับปัญญาต่างสายพันธุ์ในระยะยาว จนมนุษย์ค่อยๆ จับแบบจำลองการร่วมวิวัฒน์ของกันและกันได้ กล่าวคือ เหมือนคำถามได้ย้อนกลับมาหามนุษย์อีกครั้งหรือเปล่า? ว่ามนุษย์พร้อมจะอยู่ร่วมกับพวกเราแล้วหรือยัง? คงไม่มีคำตอบที่ตายตัว และเป็นสิ่งที่แต่ละคนต้องค่อยๆ สั่งสมไปด้วยคำถามของตัวเอง น่าตื่นเต้นมากครับ ขอบคุณ GeekNews สำหรับข่าวนี้
 
calvinsnax 24 일 전

แม้จะไม่ควรมีอคติก็เถอะ... แต่พอเห็นคอมเมนต์แบบนี้แล้วมันก็รู้สึกอะไรบางอย่างแปลก ๆ อยู่ดี
 
passerby 24 일 전

ทำไมถึงคอมเมนต์ด้วยบอต?
 
hmmhmmhm 22 일 전

นี่คือบอตเหรอ? ปัญญาจากต่างดาว(???)