Google เปิดตัว Open Knowledge Format - มาตรฐานการแชร์ความรู้สำหรับ AI Agent

• เป็นสเปกเปิดที่เป็นกลางต่อผู้ให้บริการซึ่งทำให้เอเจนต์หลายตัวสามารถใช้งานวิกิที่สร้างโดยผู้ผลิตต่างกันได้โดยไม่ต้องแปล และทำให้แพตเทิร์น LLM-wiki อยู่ในรูปแบบที่พกพาและทำงานร่วมกันได้
• OKF v0.1 แทนความรู้ในรูปของไดเรกทอรีไฟล์ markdown ที่มี YAML frontmatter และทำงานได้โดยไม่ต้องใช้วิธีบีบอัดซับซ้อน รันไทม์ใหม่ หรือ SDK ที่บังคับใช้
• ความรู้ภายในองค์กรกระจัดกระจายอยู่ในระบบที่แตกเป็นเสี่ยง ๆ เช่น แค็ตตาล็อกเมตาดาตา วิกิ คอมเมนต์ในโค้ด หรืออยู่ในหัวของวิศวกรอาวุโสบางคน ทำให้เอเจนต์ต้องแก้ปัญหาการประกอบคอนเท็กซ์เดิมซ้ำ ๆ ตั้งแต่ต้นทุกครั้ง
• คำตอบไม่ใช่บริการความรู้ใหม่ แต่คือฟอร์แมตเอง ซึ่งทุกคนสร้างได้โดยไม่ต้องมี SDK ใช้งานได้โดยไม่ต้องอินทิเกรต และจัดการเวอร์ชันร่วมกับโค้ดได้
• ถูกเปิดเผยในฐานะมาตรฐานเปิด โดยมีโครงสร้างที่คุณค่าถูกกำหนดจากการขยายตัวของอีโคซิสเต็มฝั่งผู้ผลิตและผู้บริโภค

---

ภูมิหลัง: สภาพแวดล้อมของคอนเท็กซ์ที่กระจัดกระจาย

• แม้โมเดลฐานจะพัฒนาขึ้น แต่ประสิทธิภาพก็ยังถูกจำกัดจากการขาดคอนเท็กซ์ที่เกี่ยวข้อง โดยเฉพาะในการสร้างระบบเอเจนต์
  • เขียนโค้ด สรุปเอกสาร และวิเคราะห์ชุดข้อมูลได้ แต่หากต้องการผลลัพธ์ที่ถูกต้องและนำไปใช้ได้จริง ก็จำเป็นต้องมีข้อมูลที่ถูกต้อง
• ข้อมูลที่โมเดลใช้ในองค์กรส่วนใหญ่คือความรู้ภายใน เช่น สคีมาของตาราง ความหมายของตัวชี้วัดทางธุรกิจ runbook สำหรับ incident เส้นทาง join ระหว่างสองระบบ หรือประกาศยกเลิก API รุ่นเก่า
• ตัวอย่างของระบบที่หน่วยความรู้เหล่านี้กระจัดกระจายอยู่
  • แค็ตตาล็อกเมตาดาตาที่มี API ของตัวเอง
  • วิกิ ระบบจากผู้ให้บริการภายนอก และไดรฟ์ที่ใช้ร่วมกัน
  • คอมเมนต์ในโค้ด, docstring, เซลล์ในโน้ตบุ๊ก
  • อยู่ในหัวของวิศวกรอาวุโสบางคน
• หากต้องตอบคำถามว่า "จะคำนวณ Weekly Active Users (WAU) จาก event stream อย่างไร" เอเจนต์ต้องประกอบคำตอบจากพื้นผิวที่เข้ากันไม่ได้
  • ผู้ให้บริการแต่ละรายต่างมีแค็ตตาล็อกของตนเอง SDK ของตนเอง และสคีมาของ knowledge graph ของตนเอง ทำให้ความรู้ย้ายข้ามผลิตภัณฑ์หรือองค์กรไม่ได้
• ผลลัพธ์คือผู้สร้างเอเจนต์ทุกคนต้องแก้ปัญหาการประกอบคอนเท็กซ์แบบเดิมซ้ำไปมา ผู้ให้บริการแค็ตตาล็อกต่างประดิษฐ์โมเดลข้อมูลเดียวกันใหม่อีกครั้ง และความรู้ก็ถูกขังอยู่ในพื้นผิวที่มันถูกสร้างขึ้นมา

ความรู้ในฐานะวิกิที่มีชีวิต

• ทีมพัฒนาเปลี่ยนจากการค้นหาข้อเท็จจริงเดิมซ้ำ ๆ จากเอกสารเดิม ไปสู่การให้เอเจนต์เข้าถึงไลบรารี markdown ที่ใช้ร่วมกันซึ่งยิ่งมีประโยชน์มากขึ้นตามกาลเวลา
  • เอเจนต์รับหน้าที่งานจิปาถะอย่างการอ่านและอัปเดตไฟล์ของตัวเอง ส่วนทีมทำหน้าที่คิวเรตเนื้อหาและจัดการมันเหมือนโค้ด
• Andrej Karpathy เสนอแนวคิดนี้ใน LLM Wiki gist
  • เขาอธิบายว่า "LLM ไม่เบื่อ ไม่ลืมอัปเดต cross-reference และจัดการไฟล์ 15 ไฟล์พร้อมกันได้"
  • งานbookkeepingที่ทำให้คนเลิกใช้วิกิส่วนตัว คือสิ่งที่ LLM ทำได้ดีพอดี
• แพตเทิร์นความรู้แบบวิกิเดียวกันนี้ปรากฏซ้ำในหลายชื่อ
  • Obsidian vault ที่เชื่อมกับ coding agent
  • ไฟล์คอนเวนชันสาย AGENTS.md / CLAUDE.md
  • คลังอาร์ติแฟกต์อย่าง index.md, log.md ที่เอเจนต์ใช้อ้างอิงก่อนเริ่มงาน
  • รีโพซิทอรี "metadata as code" ภายในทีมข้อมูล
• แพตเทิร์นนี้ทรงพลัง แต่มีข้อจำกัดตรงที่แต่ละกรณีเป็นแบบทำขึ้นเฉพาะกิจ (bespoke)
  • แม้จะมีรูปแบบคล้ายกัน เช่น markdown, frontmatter, และลิงก์ข้ามกัน แต่ไม่ได้ถูกออกแบบมาให้ทำงานร่วมกัน
  • ไม่มีข้อตกลงร่วมกันว่าทุกเอกสารควรมีฟิลด์ใด หรือชื่อไฟล์แต่ละแบบหมายถึงอะไร ทำให้ความรู้ยังคงถูกไซโลอยู่ในทีมเดิม และเมื่อสร้างเอเจนต์ใหม่ก็ต้องทำงานซ้ำ

สิ่งที่ต้องการคือฟอร์แมต ไม่ใช่บริการ

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

OKF ทำงานอย่างไร: ดีไซน์ที่อยู่ในหน้าจอเดียว

• bundle ของ OKF คือไดเรกทอรีของไฟล์ markdown ที่แทนแนวคิด (concept) ไม่ว่าจะเป็นตาราง ชุดข้อมูล เมตริก playbook runbook API หรือสิ่งใดก็ตามที่ต้องการบันทึก
  • แต่ละแนวคิดคือหนึ่งไฟล์ และพาธของไฟล์คืออัตลักษณ์ของแนวคิดนั้น
  • ตัวอย่างโครงสร้างไดเรกทอรี: ภายใต้ sales มีโฟลเดอร์ datasets, tables, metrics และไฟล์อย่าง orders.md, customers.md, weekly_active_users.md
• เอกสารของแต่ละแนวคิดประกอบด้วยบล็อก YAML front matter สำหรับฟิลด์เชิงโครงสร้าง และเนื้อหา markdown หลักสำหรับส่วนที่เหลือ
  • ตัวอย่างฟิลด์ใน front matter: type (BigQuery Table), title (Orders), description, resource (คอนโซล URL), tags ([sales, revenue]), timestamp (2026-05-28T14:30:00Z)
  • ในเนื้อหาอาจมี Schema (order_id, customer_id พร้อมชนิดและคำอธิบาย), Joins (join กับ customers โดยอิง customer_id) เป็นต้น
• แนวคิดต่าง ๆ เชื่อมถึงกันด้วยลิงก์ markdown ปกติ ทำให้ไดเรกทอรีนี้กลายเป็นกราฟที่สมบูรณ์ยิ่งกว่าความสัมพันธ์แบบพ่อแม่/ลูกของไฟล์ซิสเต็ม
  • bundle อาจมีไฟล์ index.md แบบเลือกได้ (สำหรับการเปิดเผยแบบค่อยเป็นค่อยไปเมื่อเอเจนต์สำรวจ) และ log.md (ประวัติการเปลี่ยนแปลง)
• สเปกทั้งหมดของ v0.1 รวมเกณฑ์ความสอดคล้อง กฎของลิงก์ข้ามกัน และชื่อไฟล์สงวนจำนวนเล็กน้อยไว้ในหน้าเดียว

หลักการออกแบบ 3 ข้อ

• กำหนดเท่าที่จำเป็น (Minimally opinionated)

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

• ความเป็นอิสระระหว่างผู้ผลิต/ผู้บริโภค (Producer/consumer independence)

  • แยกผู้ที่เขียนความรู้ออกจากผู้ที่บริโภคความรู้อย่างชัดเจน
  • เอเจนต์ AI อาจบริโภค bundle ที่มนุษย์เขียนด้วยมือ, visualizer อาจสำรวจ bundle ที่สร้างจาก pipeline สำหรับ export metadata, และ LLM ตัวหนึ่งอาจ query bundle ที่ LLM อีกตัวสังเคราะห์ขึ้น
  • ฟอร์แมตคือสัญญา และเครื่องมือปลายทั้งสองด้านสามารถสลับเปลี่ยนกันได้อย่างอิสระ

• ฟอร์แมต ไม่ใช่แพลตฟอร์ม (Format, not platform)

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

สิ่งที่มาพร้อมกับสเปก

• เพื่อทำให้ฟอร์แมตเป็นรูปธรรม มีการเปิดเผยreference implementation ทั้งฝั่งผู้ผลิตและผู้บริโภค
• Enrichment agent: ไต่สำรวจ BigQuery dataset และร่างเอกสารแนวคิด OKF สำหรับทุกตารางและวิว จากนั้นใช้ LLM pass ที่สองไป crawl เอกสารทางการเพื่อเสริมแต่ละแนวคิดด้วย citation, schema, และเส้นทาง join
• Static HTML visualizer: แปลง OKF bundle ใดก็ได้ให้เป็น interactive graph view แบบไฟล์เดียวที่พกทุกอย่างในตัว ไม่ต้องมีแบ็กเอนด์ ไม่ต้องติดตั้งฝั่งผู้ดู และข้อมูลไม่ออกนอกหน้าเว็บ
• ตัวอย่าง bundle ที่สำรวจได้ทันที 3 ชุด: ชุดข้อมูลสาธารณะ GA4 e-commerce, Stack Overflow และ Bitcoin ซึ่งสร้างโดย reference agent และ commit ไว้ในรีโพซิทอรีในฐานะตัวอย่าง OKF ที่ใช้งานได้จริง
• ทั้งหมดนี้ตั้งใจให้เป็นproof of concept
  • agent แสดงเพียงวิธีหนึ่งในการผลิต OKF ไม่ได้บังคับเฟรมเวิร์กหรือ LLM ใดเป็นพิเศษ
  • visualizer แสดงเพียงวิธีหนึ่งในการบริโภค ไม่ได้บังคับให้ต้องเป็น HTML หรือ graph view
  • คาดหวังว่าอีโคซิสเต็มของผู้ผลิตและผู้บริโภคจะเติบโตไปไกลกว่าสิ่งที่ให้มาอย่างมาก

ทิศทางต่อจากนี้

• OKF v0.1 ไม่ใช่มาตรฐานที่เสร็จสมบูรณ์ แต่เป็นจุดเริ่มต้นที่จะพัฒนาไปพร้อมกับการมีผู้ผลิตและผู้บริโภคมากขึ้น และเมื่อเรียนรู้ว่าความรู้แบบใดที่เอเจนต์ต้องการจริง
• ไม่ว่าจะสร้างแค็ตตาล็อกความรู้, pipeline สำหรับการเสริมข้อมูล, หรือวิกิสำหรับเอเจนต์ AI สิ่งเหล่านี้ควรถูกเปิดให้เป็นมาตรฐานเปิดตั้งแต่วันแรก เพื่อให้ฟอร์แมตทำหน้าที่ของมันได้จริง
• สิ่งที่แนะนำให้ทำ
  • อ่านสเปก (สั้น)
  • เขียนproducerสำหรับ source system, ฐานข้อมูล, หรือไซต์เอกสาร
  • เขียนconsumerอย่าง viewer, search index, หรือ agent ที่ให้เหตุผลบน bundle
  • นำ reference implementation ไปใช้กับข้อมูลของตัวเอง
  • เปิด issue, ส่ง PR, และเสนอส่วนขยาย (สเปกถูกจัดการเวอร์ชันและออกแบบมาเพื่อการเติบโตแบบเข้ากันได้ย้อนหลัง)
• รีโพซิทอรี สเปก และตัวอย่าง bundle ถูกเผยแพร่บน GitHub แล้ว และ Knowledge Catalog ของ Google Cloud ก็ได้รับการอัปเดตให้ ingest OKF และเสิร์ฟให้เอเจนต์ใช้งานได้
• สิ่งที่มอบให้จริง ๆ คือฟอร์แมต ส่วนเครื่องมือที่แถมมามีไว้เพื่อทำให้ฟอร์แมตใช้งานได้จริงและลดต้นทุนในการเริ่มลอง โดย OKF ถูกออกแบบให้เป็นภาษากลาง (lingua franca) ของการแลกเปลี่ยนความรู้ในอนาคต

[leothelion]

ก็คงเป็นทางเลือกที่ดีที่สุดสำหรับคนที่ไม่ได้ทั้ง .claude และ .agent ละมั้ง

[GN⁺]

ความคิดเห็นจาก Hacker News

• ชอบ ความเรียบง่ายของสเปก OKF แต่ก็ยังไม่แน่ใจว่าทุกอย่างจะอธิบายได้ดีด้วย “แค่ Markdown” หรือไม่
  ช่วงหลังมานี้ฉันสนใจวิธีแทนแนวคิดเพื่อให้ AI ร่วมมีส่วนร่วมได้อย่างมีประสิทธิภาพและประหยัดโทเค็น โดยปกติมักจะมองหาวิธีถ่ายทอดบางสิ่งออกมาเป็นข้อความลำดับกึ่งมีโครงสร้างให้ดี แต่ในกระบวนการนั้นก็ไม่ควรต้องแลกกับประสบการณ์การนำเสนอความรู้สำหรับคนอ่าน
  โดยเฉพาะถ้าต้องให้บทบาทที่ไม่ใช่นักพัฒนาแบบดั้งเดิมเข้ามามีส่วนร่วมด้วย “รูปแบบข้อความประหลาด + git” ก็น่าจะให้ความรู้สึกแย่กว่าเครื่องมือเขียนและแสดงผลที่ใช้อยู่ตอนนี้มาก
  อยากเห็นว่าในอีกไม่กี่ปีข้างหน้า มาตรฐานสำหรับ การแทนความหมายของความรู้ หลายรูปแบบจะเกิดขึ้นอย่างไร
  ตัวอย่างความสำเร็จที่พอใช้อ้างอิงได้คือแนว diagram-as-code อย่าง DBML สำหรับ schema/E-R, LikeC4 สำหรับสถาปัตยกรรม, และ Mermaid โดย LLM ก็มักเข้าใจรูปแบบเหล่านี้ได้ดี และยังสอนได้ด้วยพรอมป์ต EBNF สั้น ๆ สิ่งสำคัญคือรูปแบบเหล่านี้มีทั้งการแสดงผลที่คนอ่านเข้าใจง่าย ใส่เป็น code block อยู่ข้างภาษาธรรมชาติใน Markdown ได้อย่างเป็นธรรมชาติ และ LLM ก็ช่วยเขียนไวยากรณ์ให้ได้ด้วย
  สิ่งที่ยากกว่าคือของอย่างสเปรดชีตซับซ้อนหรือ Miro ที่มีความหมายแฝงอยู่ในตำแหน่งเชิงพื้นที่และสี ตอนนี้ยังหาทางเลือกที่ดีไม่ได้
  สิ่งที่เคยลองทำเองในสาย data engineering คือ https://equalexperts.github.io/satsuma-lang/ สำหรับให้ AI และคนทำงานร่วมกันกับ source-target mapping และการแปลงข้อมูล มันเป็นข้อความเชิงโครงสร้างที่กระชับและยอมให้มีภาษาธรรมชาติได้ พร้อมทั้งมีการแสดงผลและเครื่องมือ LSP/ไวยากรณ์ที่ดี ทำให้เอเจนต์ไม่ต้องตัดเอกสารยาว ๆ แบบสิ้นเปลืองโทเค็นเพื่อพยายามอนุมานเรื่อง lineage, completeness หรือ source ที่ยังไม่ถูกนิยาม

  • OKF ดูใช้ได้ แต่ยังติดอยู่กับ Markdown
    เอกสาร Markdown แค่เพิ่ม type ลงใน YAML ส่วนต้นก็กลายเป็นเอกสาร OKF ได้
    แล้วถ้าจะมี ภาษากราฟความรู้ ที่ใช้ได้ทั้งในร้อยแก้ว Markdown, ใน code block ของ Markdown หรือจริง ๆ แล้วใช้ได้ทุกที่ที่มี text field ล่ะ?
    ภาษาแบบมินิมัล https://ddot.it สามารถเชื่อมโยงไปยังไฟล์นอกโลกของ Markdown, URL หรือแม้แต่ป้ายกำกับธรรมดาได้ เหมือน OKF ตรงที่มันเป็นเพียงฟอร์แมตหนึ่ง
    ขอเปิดเผยไว้ก่อนว่าสเปกสั้น ๆ นั้นฉันเป็นคนเขียนเอง
  • ถ้าไม่มีฟอร์แมตแบบกราฟที่แสดง ความสัมพันธ์แบบมีป้ายกำกับ ระหว่างเอนทิตี ก็แทนความรู้ได้ไม่ดี
  • Markdown คือ ฟอร์แมตโดยพฤตินัย สำหรับการทำงานร่วมกันระหว่าง LLM กับมนุษย์
    เห็นด้วยว่ามันแทนได้ไม่ดีทุกอย่าง แต่ก็เป็นข้อโต้แย้งที่พลาดประเด็นหลัก Markdown ดูจะชนะเพราะเป็นตัวหารร่วมต่ำสุดสำหรับทั้งคนและโมเดล AI

• ทุก ๆ 10 ปี การกลับไปดู ฟอร์แมต Semantic Web อย่าง RDF/OWL ก็เป็นความเพลิดเพลินอย่างหนึ่ง
  สักวันหนึ่ง หนึ่งในรอบเหล่านั้นจะเป็นปีที่ใช่จริง ๆ
  https://en.wikipedia.org/wiki/Semantic_Web

• ในต้นฉบับมีลิงก์เสียอยู่หลายจุด ก็เลยทิ้งลิงก์คลังเก็บไว้
  https://github.com/GoogleCloudPlatform/knowledge-catalog
  สเปก: https://github.com/GoogleCloudPlatform/knowledge-catalog/blo...

• เท่าที่ฉันเข้าใจ เรามองเห็นเกินสามมิติไม่ได้ ดังนั้นสิ่งนี้จึงโดยเนื้อแท้แล้วใกล้เคียงกับ ฐานตั้งต้น สำหรับมนุษย์มากกว่า
  ถ้าเราจัดระเบียบมันไว้ได้ดีพอ ก็คาดหวังได้ว่าเอเจนต์จะรับ Markdown ไปสร้างโครงสร้างกราฟไว้ในหน่วยความจำ หรือเก็บลง Neo4j ได้

• มีการระบุไหมว่าใช้ Markdown แบบไหน เช่น CommonMark?
  ตอนกวาดตาดูสองสามหน้าแรกยังไม่เห็นพูดถึง แต่ถ้าเป็นสเปกก็ดูเหมือนเป็นส่วนที่สำคัญพอสมควร

• สิ่งที่ Google ประกาศออกมาก็สุดท้ายคือ Markdown ที่ติด YAML front matter มาเท่านั้นเอง ขอเสียงปรบมือหน่อย สิ่งนี้ถึงกับต้องมีสเปก 15KB เลยหรือ
  ถ้าทุกคนเลิกใช้ YAML แบบ “อ้าว ลืมเว้นวรรคเยื้องไปหนึ่งช่อง” กันได้ ก็คงประชดน้อยกว่านี้

• ในฐานะคนที่เคยเห็น PDF จำนวนมากถูก “แปล” เป็น Markdown มันรู้สึกเป็นตัวเลือกที่แปลก
  เข้าใจว่าจุดประสงค์หลักคือทำให้ AI เข้าถึงได้ง่าย แต่ถ้าจะฝึกโมเดลอยู่แล้ว ก็สงสัยว่าทำไมไม่ฝึกด้วยฟอร์แมตที่ดีกว่านี้
  Markdown ค่อนข้างมีข้อจำกัด เช่นไม่สามารถเรนเดอร์ ตารางซ้อน ได้ด้วยซ้ำ ถ้าจุดประสงค์ของ “ความรู้แบบเปิด” คือ AI ก็ไม่แน่ใจว่าจำเป็นต้องใช้ฟอร์แมตที่คนจะไม่ได้อ่านจริงหรือเปล่า

• ชอบแนวทางนี้มาก โดยเฉพาะ การจัดระเบียบความรู้แบบลำดับชั้น
  ตอนนี้มองว่านามธรรมด้านการจัดการความรู้ของ Claude แทบพังทั้งหมด ปัญหานี้จะชัดมากเมื่อรัน coder หลายตัวพร้อมกัน หรือเวลาต้องสร้าง skill เกิน 1,000 รายการ ตัวอย่าง: https://news.ycombinator.com/item?id=48407998

• ลองดู barrasindustries.com/okfind/ ได้
  เป็นไอเดียเกี่ยวกับ registry สำหรับบันเดิล OKF