TL;DR

Google Cloud vừa phát hành Open Knowledge Format (OKF) v0.1 - một open specification cho phép AI agent lưu trữ, chia sẻ và duy trì tri thức tổ chức theo dạng file markdown thuần. Spec chỉ có 451 dòng, không cần SDK, không cần platform độc quyền, và chính thức hóa ý tưởng "LLM Wiki" mà Andrej Karpathy mô tả vào tháng 4/2026. Nếu bạn đọc được file text và clone được git repo, bạn đã có thể dùng OKF.

Bài toán Karpathy đặt ra từ tháng 4

Hồi tháng 4/2026, Andrej Karpathy - cựu OpenAI researcher và người có tiếng nói ảnh hưởng nhất về AI thực tế - publish một GitHub Gist mô tả khái niệm LLM Wiki: một folder toàn file markdown mà AI agent tự đọc, tự viết, và tự duy trì theo kiểu Wikipedia.

Ý tưởng cốt lõi: khác với RAG tìm kiếm tài liệu thô mỗi lần query, LLM Wiki pre-compile tri thức thành các entity page có cấu trúc và liên kết nhau. Tri thức tích lũy theo thời gian thay vì bị xóa sau mỗi session.

Nhưng có một vấn đề Karpathy chưa giải quyết được: nếu mỗi team, mỗi tool, mỗi agent đều tự chế format riêng cho LLM Wiki của họ - thì không ai nói chuyện được với nhau.

Vì sao tri thức nội bộ luôn bị phân tán

Trong hầu hết tổ chức, thứ AI agent cần nhất không phải là dữ liệu public - mà là internal knowledge: schema database, định nghĩa business metric, runbook xử lý sự cố, notice API deprecated, doc onboarding. Những thứ này đang nằm rải rác ở:

  • Wiki nội bộ đã outdated từ quý trước
  • Code comment mà chỉ senior engineer mới biết
  • Metadata catalog với proprietary API riêng
  • Google Drive folder không ai còn nhớ đường dẫn
  • Trong đầu của 2-3 người vừa nghỉ việc

Kết quả: khi agent cần trả lời câu hỏi nội bộ, nó phải tự lắp ghép context từ nhiều nguồn không tương thích. Và khi bạn muốn migrate sang tool mới hoặc model mới, bạn xây lại từ đầu.

Đây là vấn đề format, không phải vấn đề model.

OKF giải quyết vấn đề này như thế nào

Google Cloud phát hành OKF v0.1 vào ngày 12/6/2026 trên knowledge-catalog. Về kỹ thuật, OKF cực kỳ đơn giản:

  • Format: Directory gồm các file markdown với YAML frontmatter
  • Trường bắt buộc duy nhất: type - một chuỗi mô tả loại khái niệm (ví dụ: "BigQuery Table", "Runbook", "API Endpoint")
  • Trường khuyến nghị: title, description, resource (URI), tags, timestamp (ISO 8601)
  • Liên kết: Standard markdown links - semantics nằm trong prose xung quanh, không phải typed edge
  • Citations: Heading # Citations với numbered references
Cấu trúc thư mục OKF và knowledge graph
Cấu trúc OKF: markdown files với YAML frontmatter liên kết nhau như knowledge graph

Một bundle OKF có thể phân phối qua git repo, tarball, hoặc mount vào filesystem. Không cần schema registry. Không cần central authority. Không cần bất kỳ SDK nào - nếu bạn đọc được file text là dùng được.

Spec đầy đủ chỉ có 451 dòng và fit trên một trang GitHub duy nhất. Đây là design có chủ đích.

Triết lý thiết kế: tối thiểu để tối đa khả năng tương thích

OKF không cố gắng định nghĩa mọi thứ. Nó không chuẩn hóa:

  • Taxonomy của type (mỗi team tự định nghĩa)
  • Governance workflows hay access controls
  • Storage hay serving infrastructure
  • Domain-specific schemas như Avro, Protobuf, OpenAPI (OKF complement chứ không thay thế)

Thay vào đó, OKF chỉ chuẩn hóa đủ để một bundle viết bởi team A có thể đọc được bởi agent của team B - mà không cần translation layer ở giữa. Đây là "format, not platform".

Conformance rule cũng permissive: bundle vẫn hợp lệ dù thiếu optional fields, có unknown types, hay broken links. Điều này cho phép OKF bundles phát triển dần theo thời gian mà không cần migration.

Ai nên quan tâm ngay bây giờ

Google đi kèm với 3 sample bundles và 2 reference implementations:

  • Enrichment Agent: Tự động walk BigQuery datasets, draft OKF documents, enrich với citations và join paths
  • Static HTML Visualizer: Biến OKF bundle thành interactive graph view - không cần backend
  • Sample bundles: GA4 e-commerce, Stack Overflow, Bitcoin public datasets

Google Cloud Knowledge Catalog cũng đã được update để ingest OKF và serve cho agents.

Các use case phù hợp nhất hiện tại:

  • Team data engineering muốn document table schemas và business metrics để agent trả lời nội bộ chính xác hơn
  • Platform team muốn lưu runbook và API docs ở format mà cả người và agent đều đọc được
  • Organization muốn portable knowledge base không bị lock vào một AI platform cụ thể

Giới hạn cần lưu ý

OKF v0.1 là early-stage, và một số quyết định thiết kế tạo ra trade-off thực tế:

Không có central type registry - Mỗi team tự định nghĩa type values. Trong một tổ chức lớn, điều này có thể dẫn đến fragmentation (team A dùng "BigQuery Table", team B dùng "BQ_Table", team C dùng "Database.Table"). Không có tooling nào enforce consistency.

Không có link integrity checking - Broken links vẫn valid per spec. Với bundle lớn được maintain bởi nhiều agent, drift theo thời gian là khó tránh.

Semantic ambiguity - Relationships giữa concepts nằm trong prose text, không phải typed edges. Agent phải đọc hiểu ngữ nghĩa thay vì query structured graph. Với knowledge base phức tạp, điều này có thể là bottleneck.

Khi format quan trọng hơn model

Có một điểm thú vị trong bài blog Google Cloud khi announce OKF: họ dẫn lại quan sát của Karpathy rằng mỗi thế hệ AI mới thường đi kèm với việc xây lại toàn bộ context management từ đầu. OKF được thiết kế để phá vỡ cycle đó.

Nếu AI agents ngày càng chịu trách nhiệm duy trì documentation và organizational memory, thì cái quyết định chất lượng output không chỉ là model mạnh đến đâu - mà còn là knowledge được cấu trúc tốt đến đâu. Một format chuẩn, portable, không bị lock vendor, có thể có giá trị dài hạn vượt xa bất kỳ model release nào.

OKF còn ở v0.1 và roadmap hoàn toàn do community. Nhưng đây là loại standardization effort mà nếu thành công, sẽ thay đổi cách AI agents hoạt động trong tổ chức - không phải theo kiểu dramatic, mà theo kiểu infrastructure: ai cũng dùng, không ai để ý đến khi nó chạy tốt.

Tham khảo

Google Cloud Blog · knowledge-catalog