Open Knowledge Format ฟอร์แมตกลางของ Knowledge/Dataset สำหรับ AI จาก Google Cloud

ช่วงนี้ผมสนใจเรื่อง knowledge base สำหรับ AI agent มากขึ้น อาจจะต้องใช้ในเรื่องส่วนตัว และใช้เอาไปทำงานด้วย โดยเฉพาะปัญหาที่เอามาคิดว่า ถ้าองค์กรมีข้อมูล business condition, schema, document, changelog และเอกสารกระจัดกระจายอยู่เต็มไปหมด เราจะทำให้ AI เข้าใจ context เหล่านี้ได้อย่างไร

หนึ่งในแนวคิดที่น่าสนใจคือ Open Knowledge Format หรือ OKF จาก Google Cloud ที่เพิ่งเผยแพร่เป็นบทความเมื่อ 13 มิ.ย. ที่ผ่านมานี่เองครับ ซึ่งผมมองว่าแก่นของมันไม่ใช่การสร้าง LLM Wiki ตัวใหม่ แบบของ Karpathy แต่คือการเสนอ ฟอร์แมตกลางสำหรับชุด knowledge/context ให้ AI, agent, data catalog และเครื่องมืออื่นๆ อ่านร่วมกันได้

หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพูช่วยกันเรียบเรียงจากเรื่อง Introducing the Open Knowledge Format ของ Google Cloud Blog ที่เล่าถึงหลักการและมุมมองการนำ OKF ไปใช้กับงาน AI / knowledge base

สรุปสั้นๆ ก่อน: OKF คืออะไร

OKF หรือ Open Knowledge Format คือ รูปแบบ specification ที่ Google Cloud เสนอให้ใช้จัดเก็บ “knowledge” ให้อยู่ในรูปที่ทั้งคนและ AI อ่านได้ง่าย โดยใช้หลักการง่ายๆ และวิธีง่ายๆ คือ:

• เก็บข้อมูลความรู้เป็น Markdown file
• กำหนดรูปแบบด้วย YAML frontmatter
• จัดการโครงสร้าง Directory structure
• จัดทำ Markdown links หาเรื่องที่เกี่ยวข้อง
• และมีไฟล์เสริมอย่าง index.md และ log.md เพื่อบันทึกการทำงาน

ถ้าอธิบายแบบบ้านๆ OKF คือการบอกว่า “ถ้าเราจะส่ง knowledge ก้อนหนึ่งให้ AI หรือระบบอื่นเอาไปอ่านต่อ เราควรแพ็กมันเป็นไฟล์แบบไหนดี”

และคำตอบของ Google คือ ไม่ต้องสร้างฐานข้อมูลใหม่ ไม่ต้องมี SDK เฉพาะ ไม่ต้องบีบอัดเป็น format แปลกๆ แต่ให้ใช้ markdown + YAML + link + folder แบบที่คนอ่านก็ได้ เครื่องอ่านก็ดี

ถ้าสังเกตให้ดี LLM Wiki ของ Karpathy ก็ใช้หลักการแบบนี้เช่นกัน แต่แค่มันไม่เคยมีใคร (แม้แต่ Andrej Karpathy) ออกมาบอกว่ามันเป็นสิ่งที่ดีหรือควรเป็นมาตรฐานนะ และคราวนี้ Google เลยออกมาบอกแทน ว่า เออ ทำแบบนี้ก็ดีแล้ว ง่ายๆ ได้ใจความ และขอเสนอเพิ่มเติมนิดหน่อยเพื่อให้มันดีขึ้น ประมาณนั้นครับ

จุดที่ต้องแยกให้ชัด: OKF กับ LLM Wiki ไม่ใช่สิ่งเดียวกัน

เพื่อความกระจ่างขึ้น ขอชี้แจงเพิ่มเติมอีกนิดว่า OKF กับ LLM Wiki มีหน้าตาคล้ายกันมาก เพราะทั้งคู่ใช้ markdown, มี link, มี index, มี log และให้ AI อ่านความรู้ที่คนหรือ agent รวบรวมไว้ แต่บทบาทของสองอย่างนี้ไม่เหมือนกัน

แต่พอคิดดีๆ แล้วมันคนละระดับกัน

LLM Wiki คือ แนวทางหรือระบบการสะสมความรู้ระยะยาว
OKF คือ ฟอร์แมตกลางสำหรับแลกเปลี่ยน knowledge/context บางชนิด

พูดอีกแบบคือ LLM Wiki เป็นเหมือน “คลังความรู้ที่ AI ช่วยดูแล” ส่วน OKF เป็นเหมือน “กล่องมาตรฐานสำหรับแพ็กความรู้บางส่วนให้ส่งต่อได้” และเอาจริงๆ ส่วนตัวผมคิดว่า Google เน้นให้ใช้ในเชิงการเก็บชุดข้อมูล (dateset) และความสัมพันธ์ด้วยซ้ำ เดี๋ยวลองดูจากตัวอย่างด้านล่างได้

ดังนั้น OKF ไม่ได้เกิดมาเพื่อแทน Notion, Obsidian, Wiki หรือ LLM Wiki ทั้งระบบ แต่มันเกิดมาเพื่อแก้ปัญหาว่า dateset หรือ knowledge ที่กระจัดกระจายอยู่ตาม data catalog, schema, runbook, doc, wiki, notebook หรือในหัว senior engineer จะถูกแพ็กให้อยู่ในรูปที่ AI ใช้ได้อย่างไร

ที่มาของ OKF: ปัญหาไม่ใช่ model ไม่เก่ง แต่ context กระจัดกระจาย

ในบทความ Google Cloud เขาเปิดด้วยประเด็นที่ผมเห็นด้วยมาก คือ foundation model เก่งขึ้นเรื่อยๆ แต่พอใช้งานจริง โดยเฉพาะงานแบบ agentic system ปัญหามักไม่ใช่ model ทำไม่ได้ แต่เป็น model ไม่มี context ที่ถูกต้องพอ

ตัวอย่างเช่น ถ้า AI agent ต้องตอบคำถามว่า “จะคำนวณ weekly active users จาก event stream ยังไง” มันไม่ได้ต้องการแค่ SQL syntax แต่มันต้องรู้หลายอย่างพร้อมกัน:

• table ไหนเก็บ event
• field ไหนคือ user id จริง
• business definition ของ active user คืออะไร
• join กับ table ไหนได้บ้าง
• metric นี้เคยเปลี่ยนนิยามหรือไม่
• มี runbook หรือ caveat อะไร
• ข้อมูลนี้ deprecated หรือยัง

ข้อมูลพวกนี้ในองค์กรจริงมักกระจายอยู่หลายที่มาก บางส่วนอยู่ใน data catalog บางส่วนอยู่ใน wiki บางส่วนอยู่ใน code comment บางส่วนอยู่ใน dashboard บางส่วนอยู่ใน ticket และบางส่วนอยู่ในหัวคน

OKF จึงพยายามเสนอ format กลางให้ knowledge เหล่านี้กลายเป็นก้อนที่ส่งต่อได้ อ่านได้ และเชื่อมโยงกันได้

ภาพที่เข้าใจง่าย: producer กับ consumer

ภาพที่เข้าใจง่ายคือ OKF คล้ายกับ NotebookLM, Notion หรือ Obsidian ที่ช่วงหลังเริ่มเชื่อม AI เข้ามาอ่านและสรุปเนื้อหา

ประเด็นสำคัญคือโลกเริ่มแยกเป็นสองฝั่ง:

• Producer คือ คนหรือระบบที่สร้างและเก็บ knowledge
• Consumer คือ AI, agent, app หรือเครื่องมือที่อ่าน knowledge นั้นไปใช้งานต่อ

ปัญหาคือแต่ละแอพมีวิธีเก็บของตัวเอง พอจะย้ายข้ามแอพหรือให้ agent คนละตัวอ่านร่วมกัน ก็ต้องแปลงไปแปลงมา ดังนั้น OKF จึงเข้ามาเสนอว่าอย่างน้อยเราควรมีฟอร์แมตไฟล์กลางที่ทุกฝ่ายเข้าใจร่วมกันได้

OKF หน้าตาเป็นอย่างไร

Google บอกว่า OKF v0.1 แทน knowledge เป็น directory ของ markdown files ที่มี YAML frontmatter กำกับรูปแบบการเก็บ และข้อมูลแต่ละไฟล์คือ concept document หนึ่งเรื่อง

ตัวอย่างแบบง่ายๆ อาจเป็นแบบนี้:

knowledge-bundle/
├── index.md
├── log.md
├── datasets/
│   └── ecommerce.md
├── tables/
│   ├── orders.md
│   └── customers.md
└── metrics/
    └── weekly-active-users.md

และในไฟล์หนึ่งอาจมี frontmatter ประมาณนี้:

---
type: table
title: orders
description: Orders table for ecommerce transactions
resource: bigquery://project.dataset.orders
tags: [ecommerce, transaction, order]
timestamp: 2026-06-13
---

# orders

ตารางนี้เก็บ order transaction ของลูกค้า

## Important fields

| Field | Meaning |
|---|---|
| order_id | unique order identifier |
| customer_id | reference to customers |
| status | order lifecycle status |

## Relationships

- Join with [customers](../tables/customers.md) by `customer_id`
- Used by [weekly-active-users](../metrics/weekly-active-users.md)

สิ่งที่น่าสนใจคือ OKF ไม่ได้บังคับ schema ลึกมาก เขาบังคับพื้นฐานน้อยมาก โดย Google บอกว่าทุก concept ต้องมีอย่างน้อย type ส่วน field อื่นๆ เช่น title, description, resource, tags, timestamp เป็นส่วนที่ช่วยให้ query และ consume ได้ง่ายขึ้น

จากตัวอย่าง ถ้าใครเป็นโปรแกรมเมอร์และทำเรื่อง database มาก่อน จะพอมองภาพออกได้ไม่ยาก

สามหลักการสำคัญของ OKF

1. Minimally opinionated

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

2. Producer กับ Consumer แยกจากกัน

ความรู้ก้อนหนึ่งอาจถูกเขียนโดยคน, export จาก metadata catalog, generate จาก LLM, หรือสรุปจากเอกสารเดิม ส่วนคนอ่านอาจเป็น AI agent, search index, visualizer หรือระบบ catalog คนละตัวกัน OKF ทำหน้าที่เป็น contract ระหว่างสองฝั่งนี้

3. Format ไม่ใช่ platform

OKF ไม่ผูกกับ Google Cloud, database, model provider หรือ agent framework ใดๆ สิ่งนี้สำคัญมาก เพราะถ้าจะเป็นฟอร์แมตกลางจริง มันต้องอ่านเขียนได้โดยไม่ต้องมีบัญชีเฉพาะหรือ SDK เฉพาะ

แล้ว OKF เกี่ยวอะไรกับ LLM Wiki

ผมคิดว่า OKF เกี่ยวกับ LLM Wiki ในฐานะ “หยิบ pattern บางอย่างมา formalize” ไม่ใช่ “เอา LLM Wiki ทั้งระบบมาทำเป็นมาตรฐาน”

LLM Wiki ของ Karpathy เน้นแนวคิดว่าเราควรให้ LLM ช่วย build knowledge base แบบสะสมไปเรื่อยๆ จาก source ต่างๆ แล้วเชื่อมโยงเป็น wiki ที่ query ได้ ไม่ต้อง RAG จากศูนย์ทุกครั้ง ผมเคยเขียนเรื่องนี้ไว้ในบทความ LLM Wiki: คลังความรู้ส่วนตัว ตามแบบฉบับของ Karpathy

ส่วน OKF เอารูปแบบที่คล้ายกัน เช่น markdown, frontmatter, link, directory, index, log มาใช้เป็นฟอร์แมตกลางสำหรับ knowledge bundle โดยเฉพาะสำหรับเรื่อง metadata, data catalog, dataset context และความรู้ที่ต้องส่งต่อข้าม tool หรือข้าม agent

OKF เหมาะกับ knowledge แบบไหน

จากที่อ่าน ผมว่า use case ที่ตรงที่สุดของ OKF คือ knowledge ที่มีลักษณะ “เป็น context ให้ AI ใช้ reasoning ต่อ” โดยเฉพาะ knowledge ที่มาเป็นชุด data เช่น

• dataset description
• table schema
• field meaning
• business metric definition
• join path
• runbook
• API deprecation note
• data lineage
• usage guide ของ table หรือ report
• context สำหรับ agent ที่ต้องทำงานกับข้อมูล

ตัวอย่างที่ Google ปล่อยมาก็ไปทางนี้ชัดเจน เช่น enrichment agent ที่เดิน BigQuery dataset แล้วร่าง OKF concept document สำหรับ table และ view จากนั้นใช้ LLM อีกส่วน ไปหา documentation มา enrich ด้วย citation, schema และ join path

เขายังมี static HTML visualizer ที่เปลี่ยน OKF bundle เป็น graph view ได้ในไฟล์เดียว และมี sample bundle เช่น GA4 e-commerce, Stack Overflow, และ Bitcoin public datasets

ตัวอย่างการใช้ในองค์กร

สมมติองค์กรมี data warehouse และมี table ชื่อ orders, customers, events อยู่แล้ว ปัญหาคือคนรู้จริงว่า table ไหนใช้ทำอะไรอาจมีไม่กี่คน และนิยาม business metric อาจอยู่กระจัดกระจาย

ถ้าใช้แนว OKF เราอาจ export หรือเขียน knowledge bundle แบบนี้:

company-data-context/
├── index.md
├── log.md
├── datasets/
│   └── ecommerce.md
├── tables/
│   ├── orders.md
│   ├── customers.md
│   └── events.md
├── metrics/
│   ├── gross-merchandise-value.md
│   └── weekly-active-users.md
└── runbooks/
    └── data-quality-incident.md

พอ agent ต้องเขียน SQL, ตรวจ data quality, อธิบาย dashboard หรือช่วย analyst หา join path มันก็ไม่ได้อ่านแค่ schema ดิบ แต่ได้อ่าน business context ที่ curated แล้วด้วย

นี่คือจุดที่ผมคิดว่า OKF มีประโยชน์มาก เพราะมันไม่ได้พยายามเป็น app ใหม่ แต่มันเป็น format ที่อยู่ตรงกลางระหว่าง data source, documentation, catalog และ AI agent

ถ้าจะเอา OKF มาใช้กับ LLM Wiki ควรทำยังไง

ความเห็นผมตอนนี้คือ ไม่ควรเอา OKF ไปครอบ LLM Wiki ทั้งหมด แต่ควรใช้ OKF เป็น subset หรือ format สำหรับ knowledge บางกลุ่ม

ตัวอย่างเช่น LLM Wiki ส่วนตัวหรือของทีมอาจมีหลายเรื่องมาก:

• บทความที่อ่าน
• paper summary
• project notes
• decision log
• people/company/entity
• research synthesis
• requirement spec
• API/database/UX knowledge

ส่วนที่ควรทำให้ OKF-compatible อาจเป็นเฉพาะส่วนที่ต้องแลกเปลี่ยนกับระบบอื่น เช่น:

• dataset catalog
• API catalog
• data dictionary
• business metric glossary
• requirement knowledge graph
• runbook ที่ agent ต้องใช้ทำงาน

พูดง่ายๆ คือ LLM Wiki เป็นระบบใหญ่ ส่วน OKF เป็น format ที่ช่วยให้บางส่วนของระบบใหญ่ส่งต่อได้ง่ายขึ้น

แล้ว Requirement Spec Center ใช้แนวนี้ได้ไหม

ผมว่าตรงนี้น่าสนใจมาก เพราะช่วงนี้ผมกำลังคิดเรื่อง requirement/spec center ที่ให้ AI ช่วย maintain ความรู้ของระบบ เช่น product, change, API, database, table, field, UX/UI, test case, approval และ release

สำหรับงานแบบนี้ ผมไม่คิดว่า OKF คือคำตอบทั้งหมด แต่แนวคิด OKF เอามาใช้ได้เยอะมาก โดยเฉพาะการทำให้แต่ละ entity เป็น markdown file ที่มี frontmatter และ link ถึงกัน

เช่น change หนึ่งอาจเชื่อมไปหา API, table, field, UX screen, test case และ approval record:

product-change-kb/
├── changes/
│   └── HOME-25Q3-FEA-01.md
├── apis/
│   └── API-HOME-POST-BOOKINGS.md
├── databases/
│   └── HOME/tables/bookings.md
├── ux-ui/
│   └── HOME/booking-form.md
└── tests/
    └── HOME-25Q3-FEA-01-test-case.md

สิ่งนี้ไม่ใช่ OKF ตาม Google ตรงๆ ทั้งหมด แต่มันใช้แนวเดียวกัน คือ knowledge เป็น file, มี metadata, มี link, มี graph และ AI อ่านความสัมพันธ์ได้

และจากที่ผมเอา LLM Wiki มาดัดแปลงเพื่อลองทำ Requirement Spec Center ก็พบว่าคล้ายกับสิ่งที่ OKF กำหนดมาก แต่ก็ยังพบว่าต้องปรับอะไรอีกหลายอย่าง ถ้าจะใช้งานจริงๆ ซึ่ง OKF พอมาเสริมไอเดียได้

ความเห็นส่วนตัวของผม

สิ่งที่ทำให้ OKF น่าสนใจไม่ใช่เพราะมันมีเทคนิคซับซ้อน แต่เพราะมันเรียบง่ายมากจนมีโอกาสถูกใช้จริง

โลก AI ตอนนี้มีปัญหาใหญ่คือทุกคนพยายามสร้าง agent แต่ context ที่ agent ต้องใช้กลับกระจัดกระจายและไม่ portable เท่าไร ถ้าแต่ละองค์กรเริ่มมีวิธีแพ็ก context เป็น markdown bundle ที่มี metadata และ link ชัดเจน AI จะทำงานกับ knowledge ได้ดีขึ้นมาก

แต่ผมก็ยังคิดว่า OKF v0.1 ยังเป็นจุดเริ่มต้นมากๆ ต้องดูต่อว่าจะมี tool, producer, consumer และ adoption จริงแค่ไหน โดยเฉพาะนอก Google Cloud

สำหรับผม takeaway ที่สำคัญที่สุดคือ:

OKF ไม่ได้มาแทน LLM Wiki แต่มาช่วยให้ knowledge บางส่วนของ LLM Wiki หรือ data catalog ถูกแลกเปลี่ยนและใช้งานโดย AI ได้ง่ายขึ้น

ถ้าจะใช้จริง ผมจะเริ่มจาก use case ที่ชัดก่อน เช่น data dictionary, metric glossary, API catalog หรือ requirement traceability แล้วค่อยดูว่าควร เชื่อมโยงกันอย่างไร และนำไปปลั๊กกับ AI อย่างไรต่อ

แหล่งอ้างอิง

• Google Cloud: How the Open Knowledge Format can improve data sharing
• Blognone: กูเกิลเปิดตัว Open Knowledge Format (OKF)
• โพสต์อธิบาย OKF จาก AI กับ Peesamac
• บทความเดิมของผมเรื่อง LLM Wiki ของ Andrej Karpathy