ลองทำ LLM Wiki ที่นำโครงสร้าง “กองบรรณาธิการหนังสือพิมพ์” มาใช้ เพราะมัลติเอเจนต์กินโทเคนเยอะและมักหลุดบริบท

• มัลติเอเจนต์แบบอัตโนมัติกำลังออกมากันเยอะในช่วงนี้ แต่พอลองรันจริงก็มักกินโทเคนมากขึ้น 5–10 เท่า แถมหลุดบริบทอยู่บ่อย ๆ ดังนั้นจึงจัดโครงสร้างมัลติเอเจนต์โดยอิงจากกองบรรณาธิการของหนังสือพิมพ์
• มีบทบาทเอเจนต์อยู่ห้าแบบ แต่เอเจนต์ที่ให้ LLM ตัดสินใจเองมีเพียงบทบาทเดียวคือ desk (ตรวจทาน) ที่เหลือเป็นงานเขียน, การตรวจด้วย Python ตามกฎ (lint) ไม่ใช่ LLM, และการประสานงาน (orchestration)
• ตามแนวคิด LLM Wiki ระบบจะอ่านเอกสารต้นฉบับเพื่อสร้างหน้าซอร์ส จากนั้นดึงร่างของบุคคลและแนวคิดออกมา แล้วรวบรวมต่อยอดเป็นหน้า overview ตามหัวข้อ, สรุปความขัดแย้ง และหน้าสังเคราะห์ การจัดเก็บเป็นแค่ไฟล์ Markdown กับ git และเครื่องมือ Python ทั้งหมดรันในเครื่อง local แค่ clone ก็ลองรันกราฟตัวอย่างได้ทันทีโดยไม่ต้องมี API key
• ตัวอย่างที่อยู่ใน GitHub ตอนนี้พูดถึงข้อถกเถียงว่า “โอเพนซอร์สใน AI คืออะไร” แต่ตัว framework เองไม่ได้จำกัดหัวข้อ

---

ทำไมถึงไม่ปล่อยเอเจนต์หลายตัวให้ทำงานกันเองไปเลย

• ประสบการณ์ของคนที่ลองรันจริงโดยเสียเงินเป็นพัน ๆ ดอลลาร์มักสรุปออกมาเหมือนกัน คือใช้โทเคนมหาศาล, เอเจนต์คุยกันไปมาแล้วหลุดบริบท, และทำเครื่องหมายว่างานเสร็จทั้งที่ยังไม่เสร็จ
• ดังนั้นแทนที่จะปล่อยให้ตัดสินใจเอง จึงให้น้ำหนักกับกฎที่กำหนดไว้และการแยกบริบทมากกว่า แม้จะใช้ภาพเปรียบเทียบว่าเป็นกองบรรณาธิการ แต่ LLM ที่ตัดสินใจได้อย่างอิสระจริง ๆ มีแค่ desk เท่านั้น ส่วนที่เหลือทำเฉพาะงานที่กำหนดไว้

ขอตอบข้อโต้แย้งที่น่าจะมีไว้ก่อน

• เอกสารจะพองขึ้นเรื่อย ๆ จนสุดท้ายใช้ไม่ได้: มองว่านี่เป็นความกังวลที่เป็นจริงที่สุด จึงแยกบทบาทคนเขียนกับ desk ที่ตัดสินว่าจะให้ผ่านหรือไม่ออกจากกันอย่างชัดเจน ให้ desk เห็นเฉพาะผลลัพธ์กับเกณฑ์การให้คะแนน และไม่เห็นว่าคนเขียนตั้งใจเขียนด้วยเจตนาอะไร นอกจากนี้ lint แบบ rule-based จะกรองเชิงกลเมื่อเอกสารพองตัว, ซ้ำซ้อน หรือยืดยาวแบบไร้ทิศทาง แต่ก็ยังพูดไม่ได้เต็มปากว่าสามารถ “ป้องกัน” การพองตัวได้แล้ว
• ถ้าแก้ไขซ้ำ ๆ ข้อผิดพลาดจะสะสม และถ้าแก้ตัวเองด้วย feedback ที่ตัวเองสร้าง สุดท้ายก็จะทำซ้ำแต่แพตเทิร์นเดิม: ความสงสัยนี้มักตามมากับเรื่องการปรับปรุงตัวเองเสมอ และผมก็คิดว่าสมเหตุสมผล ดังนั้นเมื่อสะท้อนข้อบกพร่องที่ desk จับได้ซ้ำ ๆ กลับเข้าไปใน guideline จะสลับกรณีล้มเหลวสำหรับตรวจสอบให้เป็นชุดใหม่ทุกครั้ง เพื่อกันไม่ให้คุ้นชินกับโจทย์ทดสอบเดิม ๆ เท่านั้น (overfit) เท่ากับตรวจด้วยเคสที่ไม่เคยเห็นมาก่อนเสมอ ฝั่งหน้าสังเคราะห์ก็ใส่การตรวจสอบเพื่อเทียบว่ามีการเหมารวมเนื้อหาจากแหล่งที่มาต่างกันเข้าด้วยกันหรือไม่
• สุดท้ายก็เป็น RAG ที่เปลี่ยน embedding ด้วยมือไม่ใช่หรือ: ถ้าเป้าหมายคือการค้นหา ก็พูดได้ว่าถูก ความต่างคือผลลัพธ์ไม่ใช่ vector index แต่เป็นเอกสารที่เชื่อมโยงกันและมนุษย์อ่านได้โดยตรง อีกทั้งส่วนที่แหล่งข้อมูลขัดกันจะไม่ถูกกลบไว้ แต่แยกออกมาเป็นหน้า contradiction ให้เห็น เป้าหมายคือไม่ต้องรวบรวมต้นฉบับใหม่ทุกครั้งที่ถาม แต่ให้การตัดสินที่สะสมไว้ยังคงอยู่

แนวคิดเก่าแก่: Memex

• ทำขึ้นโดยนึกถึงสายธารแนวคิดอย่าง Memex ของ Vannevar Bush (เครื่องสารสนเทศแบบเชื่อมโยงที่เสนอไว้ในปี 1945) และ “Man-Computer Symbiosis” ของ Licklider
• ดังนั้นจึงใส่ trail (เส้นทางเชื่อมโยงเชิงนึกสัมพันธ์) ที่เชื่อมหน้าต่าง ๆ เข้าด้วยกัน และฟีเจอร์ discover ที่ช่วยค้นหาความเชื่อมโยงที่คาดไม่ถึง เป้าหมายไม่ใช่การดึงดัชนีอัตโนมัติ แต่เป็นการทิ้งเส้นทางที่มนุษย์สามารถเดินตามได้ด้วยตัวเอง

ข้อควรพิจารณาในการใช้งาน

• คำว่า “ไม่ต้องมี API key” ถูกแค่ครึ่งเดียว: Python ใน tools รันบนเครื่อง local จึงไม่ต้องใช้คีย์ภายนอก แต่ตัวเอเจนต์เองรันด้วย Claude Code ดังนั้นแต่ละคนต้องผูกคีย์ของตัวเองมาใช้ (BYOK)
• repo สาธารณะเป็นเพียงไอเดียกับตัวอย่างเล็ก ๆ: มีตัวอย่างภาษาอังกฤษขนาด 15 โหนดอยู่ในนั้น แค่ clone ใคร ๆ ก็สร้างกราฟเดียวกันซ้ำได้ ส่วน instance จริงที่ผมรันทุกวันมีประมาณ 2,300 โหนดและแยกไว้เป็น private จึงขอให้ดูแยกจาก repo สาธารณะ
• โหมดภาษาเกาหลี (WIKI_LANG=ko): จะเปลี่ยนเฉพาะเนื้อหาและ metadata ด้านบนของเอกสาร (frontmatter) เป็นภาษาเกาหลี ส่วนสัญลักษณ์ที่แสดงโครงสร้างเอกสาร เช่น ## Summary, [fact] จะจงใจคงไว้เป็นภาษาอังกฤษ หมายความว่าไม่ใช่ “ภาษาเกาหลีทั้งหมด”

ที่มาในการทำและสถานะตอนนี้

• จุดเริ่มต้นคือการลองต่อ implementation เข้ากับ LLM Wiki gist ที่ Karpathy แชร์ แนวคิดนี้เองเคยถูกแนะนำใน GeekNews มาก่อนแล้ว: https://th.news.hada.io/topic?id=28208
• การแยกฝั่งเขียนกับฝั่งตรวจทานจะช่วยลดการปล่อยผ่านแบบลวก ๆ ได้จริงหรือไม่ และ loop ที่ปรับปรุงตัวเองช่วยได้จริงหรือไม่ ยังไม่ใช่ผลลัพธ์ที่วัดอย่างเป็นระบบแล้ว แต่เป็นสมมติฐานที่กำลังทดลองอยู่