AKB - โครงสร้างพื้นฐานความรู้ของทีมที่คนและ AI อ่านเขียนร่วมกัน พร้อมระบบจัดการสิทธิ์การเข้าถึง
(github.com/dnotitia)สวัสดีครับ/ค่ะ ตอนนี้ที่ Dnotitia ซึ่งผม/ฉันสังกัดอยู่ กำลังพัฒนา AKB(Agent Knowledge Base) ฐานความรู้ของทีมที่ AI agent สามารถอ่านและเขียนได้โดยตรงระหว่างทำงาน
ทำไมถึงสร้างมันขึ้นมา?
วิกิสำหรับคนใช้งานอย่าง Confluence·Notion มีอยู่มากแล้ว ฝั่ง agent เองก็มีเครื่องมือคล้ายกัน mem0 จะสะสมเนื้อหาที่ดึงมาจากบทสนทนาเป็นหน่วยความจำส่วนบุคคล ส่วน LLM Wiki จะสร้างฐานความรู้ส่วนบุคคลที่ agent อ่านและเขียนได้ แต่โดยมากยังหยุดอยู่ในระดับบุคคล จึงยากจะบอกได้ว่าออกแบบมาเป็นฐานกลางที่หลายคนอ่านและเขียนร่วมกันได้จริง
Open Knowledge Format(OKF) ของ Google ก็ชี้ปัญหาคล้ายกัน ความรู้กระจัดกระจายอยู่ตามวิกิ แคตตาล็อก และโค้ด ทำให้ agent ต้องรวบรวมบริบทใหม่ทุกครั้ง ดังนั้นสิ่งที่จำเป็นไม่ใช่บริการปิดตัวหนึ่งเพิ่มขึ้นมาอีก แต่เป็นฟอร์แมตร่วมที่หลายเครื่องมือสามารถอ่านและเขียนร่วมกันได้ ฟอร์แมตที่ OKF เสนอนั้นเรียบง่าย แค่รวบรวมไฟล์ Markdown ไว้ในโฟลเดอร์ และใส่ YAML ไม่กี่บรรทัดไว้ด้านบนสุดของแต่ละไฟล์ จากนั้นก็เปิดให้แต่ละ implementation เป็นผู้กำหนดเองว่าจะสร้าง อ่าน และขยายฟอร์แมตนี้อย่างไร
AKB ทำอะไรบ้าง?
AKB คือโครงสร้างพื้นฐานที่นำฟอร์แมตนั้นมาสร้างเป็นฐานความรู้ร่วมของทีม vault เป็นชุด Markdown ที่เข้ากันได้กับ OKF แต่ไม่ใช่แค่ดัชนีสำหรับค้นหาและอ่านเท่านั้น มันคือที่เก็บข้อมูลร่วมที่คนและ agent อ่านและเขียนจากต้นฉบับเดียวกัน คนเข้าถึงผ่านเว็บ UI ส่วน agent เข้าถึงผ่าน MCP แต่ต้นฉบับที่แตะต้องยังมีเพียงชุดเดียว เมื่อ agent เริ่มเขียน สิ่งที่สำคัญก็คือ “อะไรเปลี่ยนไปอย่างไร” ด้วย เพราะ vault เป็น Git repository การเปลี่ยนแปลงทั้งหมดจึงถูกบันทึกไว้เป็น commit และ diff
สิ่งที่เก็บก็ไม่ได้มีแค่เอกสารเท่านั้น ถ้า OKF เป็นฟอร์แมตที่เขียนความรู้เป็น Markdown, AKB จะเพิ่มตารางที่ query ได้และ file storage เข้าไปใน vault เดียวกัน พร้อมเชื่อมเอกสารเข้าหากันด้วย knowledge graph เอกสารถูกใช้เป็นความรู้ที่คนอ่านและ agent อ้างอิง ส่วนข้อมูลที่ต้องจัดการแบบมีโครงสร้าง เช่น รายการ สถานะ หรือสถิติ สามารถเก็บแยกในตารางและ query ได้ ดังนั้นสิ่งที่ทำได้ยากด้วยวิกิสำหรับคนหรือการค้นหาเพียงอย่างเดียว เช่น การใช้ AKB เป็นชั้นข้อมูลและประวัติการเปลี่ยนแปลง แล้วพัฒนาและรันแอปงานบนชั้นนั้น ก็เป็นไปได้เช่นกัน
อย่างไรก็ตาม หากจะเป็นฐานความรู้ร่วมของทีมจริง แค่ข้อมูลและประวัติยังไม่พอ ฟอร์แมตอย่าง OKF ไม่ได้กำหนดว่าใครดูอะไรได้บ้าง ส่วนที่ AKB ใส่ใจมากที่สุดคือสิทธิ์การเข้าถึงนี้เอง agent จะยืนยันตัวตนในฐานะคนที่ออก token ให้มัน และรับสิทธิ์ของคนนั้นใน vault ไปตรง ๆ ขอบเขตการเข้าถึงที่ใช้กับคนจึงถูกใช้กับ agent แบบเดียวกัน และขอบเขตนี้ถูกบังคับใช้สองชั้น การเข้าถึงทั่วไปอย่างเอกสาร ไฟล์ หรือการค้นหา จะตรวจสิทธิ์ในชั้นแอป ส่วนเส้นทางที่รัน SQL เพื่อสรุปผลหรือวิเคราะห์บนตาราง จะถูกป้องกันซ้ำอีกครั้งในชั้นฐานข้อมูล ด้วยวิธี PG ACL ที่ทำให้ query รันด้วย PostgreSQL role ของผู้ใช้นั้นเอง ดังนั้นถ้าอ้างอิง vault ที่อยู่นอกสิทธิ์ ไม่ใช่แอปแต่ PostgreSQL จะเป็นฝ่ายปฏิเสธโดยตรง
ทีมของเราใช้งาน issue tracker reef บนโครงสร้างพื้นฐาน AKB อยู่ด้วย issue หนึ่งรายการเป็นทั้งเอกสาร Markdown ใน vault และเป็นแถวในตารางที่ query ได้ นักพัฒนาใช้ coding agent อย่าง Claude Code·Codex ส่วน PM ใช้ agent เฉพาะของ reef เพื่อทำงานจากเอกสารเดียวกันใน vault PM สามารถสร้าง issue ได้โดยอิงบริบทที่สะสมอยู่ใน AKB โดยไม่จำเป็นต้องรู้ไวยากรณ์สเปกสำหรับนักพัฒนา ขณะที่นักพัฒนาก็สามารถดึงข้อมูลผ่าน MCP ไปพัฒนาได้โดยไม่ต้องขุดคำอธิบายพื้นหลังที่กระจัดกระจายอีก เรากำลังสัมผัสได้โดยตรงในทีมว่า agent ช่วยลดกำแพงด้านเทคนิคและภาษาระหว่างนักพัฒนาและ PM ลง
ลองดูได้ทันที
ถ้าอยากลองดูทันทีโดยไม่ต้องติดตั้ง สามารถเข้าเดโมสาธารณะได้ที่ akb-demo.agent.seahorse.dnotitia.ai (ต้องสมัครใช้งาน แต่เป็นเดโม ดังนั้นข้อมูลทั้งหมดจะถูกรีเซ็ตทุกสัปดาห์)
หากอยากลองรันเอง สามารถเปิดด้วย Docker compose ตามด้านล่าง แล้วเข้าใช้งานที่ localhost:3000 ได้เลย ต่อให้ไม่มี embedding key การค้นหาด้วยคีย์เวิร์ด (BM25) ก็ยังทำงานได้
git clone https://github.com/dnotitia/akb && cd akb
cp config/app.yaml.example config/app.yaml
cp config/secret.yaml.example config/secret.yaml
docker compose up -d
ตอนนี้ยังมีส่วนที่ต้องปรับปรุงอีกมาก หากลองเปิดใช้งานดูแล้วพบ bug จุดแปลก ๆ หรือมีความเห็นใด ๆ ฝากคอมเมนต์ได้ตามสบายเลย ขอบคุณครับ/ค่ะ
ยังไม่มีความคิดเห็น