Google công bố Open Knowledge Format - tiêu chuẩn chia sẻ tri thức cho AI agent

 (cloud.google.com)
5 điểm bởi GN⁺ 4 giờ trước | 2 bình luận | Chia sẻ qua WhatsApp
  • Đây là một đặc tả mở, trung lập với nhà cung cấp cho phép nhiều agent tiêu thụ các wiki do những bên khác nhau tạo ra mà không cần lớp dịch thuật, đồng thời chuẩn hóa mẫu LLM-wiki thành một định dạng có thể di chuyển và tương tác liên thông
  • OKF v0.1 biểu diễn tri thức dưới dạng thư mục các tệp markdown có chứa YAML frontmatter, và hoạt động mà không cần cơ chế nén phức tạp, runtime mới hay SDK bắt buộc
  • Tri thức nội bộ trong tổ chức bị phân tán trên các hệ thống rời rạc như catalog metadata, wiki, chú thích mã nguồn, thậm chí trong đầu của một số kỹ sư kỳ cựu, khiến agent mỗi lần đều phải giải lại từ đầu bài toán lắp ghép cùng một ngữ cảnh
  • Câu trả lời không phải là một dịch vụ tri thức mới mà là chính định dạng này: ai cũng có thể tạo ra mà không cần SDK, tiêu thụ mà không cần tích hợp, và quản lý cùng mã nguồn trong hệ thống kiểm soát phiên bản
  • Được công bố như một tiêu chuẩn mở, giá trị của nó được quyết định thông qua sự mở rộng của hệ sinh thái nhà sản xuất và nhà tiêu thụ

Bối cảnh: môi trường ngữ cảnh bị phân mảnh

  • Dù các foundation model tiếp tục tiến bộ, hiệu năng vẫn bị giới hạn bởi thiếu ngữ cảnh liên quan, đặc biệt khi xây dựng hệ thống agent
    • Chúng có thể viết mã, tóm tắt tài liệu và phân tích tập dữ liệu, nhưng để đưa ra kết quả chính xác và có thể hành động thì cần đúng thông tin
  • Thông tin mà mô hình sử dụng trong tổ chức phần lớn là tri thức nội bộ, bao gồm schema bảng, ý nghĩa của các chỉ số kinh doanh, runbook sự cố, đường join giữa hai hệ thống, hay thông báo ngừng hỗ trợ của API cũ
  • Ví dụ về các hệ thống nơi những đơn vị tri thức này đang nằm rải rác
    • Catalog metadata với API riêng
    • Wiki, hệ thống bên thứ ba, ổ đĩa chia sẻ
    • Chú thích mã nguồn, docstring, ô notebook
    • Trong đầu của một vài kỹ sư kỳ cựu
  • Để trả lời câu hỏi “làm thế nào tính weekly active users (WAU) từ event stream”, agent phải ghép câu trả lời từ những bề mặt không tương thích với nhau
    • Mỗi nhà cung cấp đều đưa ra catalog riêng, SDK riêng, schema knowledge graph riêng, và tri thức không thể di chuyển giữa sản phẩm hay tổ chức
  • Kết quả là mọi người xây agent đều lặp lại cùng một bài toán lắp ghép ngữ cảnh, các nhà cung cấp catalog thì tái phát minh cùng một mô hình dữ liệu, còn tri thức bị khóa trong bề mặt đã tạo ra nó

Tri thức như một wiki sống

  • Các nhóm phát triển đang chuyển sang cách cung cấp cho agent một thư viện markdown dùng chung ngày càng hữu ích theo thời gian, thay vì lặp đi lặp lại việc tìm cùng một sự thật trong cùng một tài liệu
    • Agent đảm nhận phần việc lặt vặt như đọc và cập nhật tệp của chính nó, còn nhóm thì tuyển chọn nội dung và quản lý như mã nguồn
  • Andrej Karpathy đã nêu ý tưởng này trong LLM Wiki gist
    • Ông mô tả rằng “LLM không biết chán, không quên cập nhật các tham chiếu chéo, và có thể xử lý 15 tệp cùng lúc”
    • Chính công việc bookkeeping khiến con người từ bỏ wiki cá nhân lại là thứ LLM làm tốt
  • Cùng một mẫu tri thức-wiki này xuất hiện lặp lại dưới nhiều tên gọi
    • Obsidian vault kết nối với coding agent
    • Các tệp quy ước kiểu AGENTS.md / CLAUDE.md
    • Kho lưu trữ artifact như index.md, log.md mà agent tham chiếu trước khi làm việc
    • Kho “metadata as code” nội bộ của các nhóm dữ liệu
  • Mẫu này rất mạnh, nhưng mỗi trường hợp đều có hạn chế là được may đo riêng lẻ
    • Hình thức có thể giống nhau như markdown, frontmatter, liên kết chéo, nhưng không được thiết kế để cộng tác với nhau
    • Không có đồng thuận về các trường bắt buộc hay ý nghĩa của tên tệp, nên tri thức vẫn bị cô lập trong từng nhóm và phát sinh công việc trùng lặp khi xây agent mới

Điều cần thiết là định dạng, không phải dịch vụ

  • Câu trả lời không phải là thêm một dịch vụ tri thức nữa mà là một định dạng để biểu diễn tri thức, và nó phải đáp ứng các yêu cầu sau
    • Ai cũng có thể tạo ra mà không cần SDK
    • Ai cũng có thể tiêu thụ mà không cần tích hợp
    • Được bảo toàn khi di chuyển giữa hệ thống, tổ chức và công cụ
    • Tồn tại trong hệ thống quản lý phiên bản cùng với đoạn mã mà nó mô tả
    • Con người đọc được và agent phân tích được, dùng cùng một tệp mà không cần lớp dịch thuật
  • OKF là định dạng được thiết kế để đáp ứng các yêu cầu đó

Cách OKF hoạt động: thiết kế gói gọn trong một màn hình

  • Một bundle OKF là thư mục các tệp markdown biểu diễn các concept, bao gồm mọi đối tượng cần nắm bắt như bảng, tập dữ liệu, chỉ số, playbook, runbook, API
    • Mỗi concept là một tệp, và đường dẫn tệp chính là danh tính của concept đó
    • Ví dụ cấu trúc thư mục: dưới sales có các thư mục datasets, tables, metrics cùng các tệp orders.md, customers.md, weekly_active_users.md
  • Mỗi tài liệu concept gồm một khối YAML front matter cho các trường có cấu trúc và phần thân markdown chứa phần còn lại
    • Ví dụ trường front matter: type (BigQuery Table), title (Orders), description, resource (URL console), tags ([sales, revenue]), timestamp (2026-05-28T14:30:00Z)
    • Trong phần thân có thể có Schema (các cột order_id, customer_id cùng kiểu và mô tả), Joins (join với customers theo customer_id)
  • Các concept liên kết với nhau bằng liên kết markdown thông thường, biến thư mục thành một đồ thị phong phú hơn quan hệ cha/con của hệ thống tệp
    • Bundle cũng có thể tùy chọn chứa index.md (để agent khám phá theo kiểu tiết lộ dần) và log.md (lịch sử thay đổi)
  • Toàn bộ đặc tả v0.1, gồm tiêu chí tương thích, quy tắc liên kết chéo và một số tên tệp dành riêng, đều nằm trong một trang

Ba nguyên tắc thiết kế

  • Quy định tối thiểu (Minimally opinionated)

    • Điều duy nhất OKF yêu cầu ở mọi concept là trường type
    • Việc có những type nào, thêm trường gì, hay có những mục nào trong phần thân đều do bên sản xuất quyết định
    • Đặc tả chỉ định nghĩa bề mặt tương tác liên thông, chứ không áp đặt mô hình nội dung

  • Tính độc lập giữa nhà sản xuất và nhà tiêu thụ (Producer/consumer independence)

    • Tách bạch rõ ràng giữa bên viết tri thức và bên tiêu thụ tri thức
    • Bundle do con người viết tay có thể được AI agent tiêu thụ; bundle do pipeline xuất metadata tạo ra có thể được trình trực quan hóa duyệt; bundle do một LLM tổng hợp có thể được LLM khác truy vấn
    • Định dạng là hợp đồng, còn công cụ ở hai đầu có thể được thay thế độc lập

  • Định dạng, không phải nền tảng (Format, not platform)

    • Không phụ thuộc vào nhà cung cấp cloud, cơ sở dữ liệu, nhà cung cấp mô hình hay framework agent cụ thể nào
    • Không yêu cầu tài khoản độc quyền hay SDK riêng để đọc, ghi hoặc phục vụ
    • Giá trị của một định dạng tri thức không đến từ chủ sở hữu mà từ có bao nhiêu bên sử dụng định dạng đó, vì vậy nó được công bố như một tiêu chuẩn mở

Những gì được cung cấp cùng đặc tả

  • Để cụ thể hóa định dạng, Google công bố các triển khai tham chiếu cho cả hai phía sản xuất và tiêu thụ
  • Enrichment agent: duyệt qua các tập dữ liệu BigQuery, tạo bản nháp tài liệu concept OKF cho mọi bảng và view, sau đó dùng lượt LLM thứ hai để thu thập tài liệu chính thức và bổ sung trích dẫn, schema, đường join cho từng concept
  • Trình trực quan hóa HTML tĩnh: chuyển bất kỳ bundle OKF nào thành chế độ xem đồ thị tương tác trong một tệp đơn tự chứa, không cần backend, không cần cài đặt ở phía người xem, và dữ liệu không rời khỏi trang
  • Ba bundle mẫu có thể khám phá ngay: bộ dữ liệu công khai GA4 e-commerce, Stack Overflow và Bitcoin, do agent tham chiếu tạo ra rồi commit vào kho lưu trữ như những ví dụ sống về OKF phù hợp
  • Chúng được cố ý xây dựng như proof of concept
    • Agent chỉ minh họa một cách tạo ra OKF, không yêu cầu framework hay LLM cụ thể nào
    • Trình trực quan hóa chỉ minh họa một cách tiêu thụ, không bắt buộc phải dùng HTML hay chế độ xem đồ thị
    • Kỳ vọng hệ sinh thái producer và consumer sẽ phát triển vượt xa những gì đang được cung cấp

Hướng đi tiếp theo

  • OKF v0.1 không phải một tiêu chuẩn hoàn chỉnh mà là điểm khởi đầu, và sẽ tiếp tục tiến hóa khi có thêm producer, consumer và khi người ta hiểu rõ hơn cách biểu diễn tri thức mà agent thực sự cần
  • Dù đang xây catalog tri thức, pipeline làm giàu hay wiki cho AI agent, thì cần công bố mở ngay từ ngày đầu để định dạng thực sự xứng với tên gọi của nó
  • Hành động được khuyến nghị
    • Đọc đặc tả (ngắn)
    • Viết producer cho hệ thống nguồn, cơ sở dữ liệu, trang tài liệu
    • Viết consumer như trình xem, chỉ mục tìm kiếm, hay agent suy luận trên bundle
    • Áp dụng triển khai tham chiếu lên dữ liệu của chính mình
    • Tạo issue, gửi PR, đề xuất mở rộng (đặc tả được quản lý bằng phiên bản và được thiết kế để phát triển tương thích ngược)
  • Kho lưu trữ, đặc tả và các bundle mẫu đều đã được công bố trên GitHub, và Knowledge Catalog của Google Cloud đã được cập nhật để thu thập OKF và phục vụ nó cho agent
  • Bản thân phần đóng góp là định dạng; các công cụ đi kèm chỉ nhằm biến định dạng thành hiện thực và hạ thấp chi phí thử nghiệm, còn OKF được thiết kế như lingua franca cho trao đổi tri thức trong tương lai

Bài viết liên quan

2 bình luận

 
leothelion 1 giờ trước

Chắc là lựa chọn tốt nhất cho những ai không nuốt nổi .claude và .agent.
 
GN⁺ 4 giờ trước
Ý kiến trên Hacker News

  • Tôi thích sự đơn giản của đặc tả OKF này, nhưng không chắc mọi thứ có thể được biểu đạt tốt chỉ bằng “Markdown” hay không
    Gần đây tôi quan tâm đến cách biểu đạt khái niệm để AI có thể cùng đóng góp một cách hiệu quả và tiết kiệm token, và thường là tìm cách diễn đạt thứ gì đó bằng văn bản tuần tự bán cấu trúc. Nhưng trong quá trình đó, không nên hy sinh trải nghiệm biểu đạt tri thức dành cho con người
    Đặc biệt nếu cả những vai trò vốn không phải nhà phát triển cũng cần tham gia đóng góp, thì “định dạng văn bản kỳ lạ + git” rất có thể sẽ bị cảm nhận là tệ hơn nhiều so với các công cụ soạn thảo và trực quan hóa đang dùng hiện nay
    Tôi mong chờ xem trong vài năm tới sẽ xuất hiện ra sao các tiêu chuẩn biểu đạt ngữ nghĩa cho nhiều loại tri thức khác nhau
    Một số ví dụ thành công đáng tham khảo là DBML cho schema/E-R, LikeC4 cho kiến trúc, và các cách tiếp cận diagram-as-code như Mermaid. LLM cũng hiểu khá tốt các định dạng như vậy, và còn có thể được hướng dẫn bằng prompt EBNF ngắn. Điều quan trọng là chúng cũng có dạng trực quan hóa dễ xem với con người, có thể được đặt ngay trong code block bên trong Markdown cạnh ngôn ngữ tự nhiên, và LLM cũng có thể hỗ trợ viết cú pháp
    Phần khó hơn là những thứ như bảng tính phức tạp hoặc Miro, nơi bố cục không gian và màu sắc mang ý nghĩa ngầm. Tôi vẫn chưa tìm ra giải pháp thay thế tốt
    Thứ tôi đã trực tiếp thử trong lĩnh vực data engineering là https://equalexperts.github.io/satsuma-lang/ để AI và con người cùng xử lý ánh xạ source-target và chuyển đổi. Đây là một cách biểu đạt văn bản có cấu trúc ngắn gọn, cho phép dùng ngôn ngữ tự nhiên, đồng thời cung cấp trực quan hóa tốt và công cụ LSP/ngữ pháp, để agent không phải cắt nhỏ tài liệu lớn một cách kém hiệu quả về token chỉ để suy luận về lineage, tính đầy đủ hay các source chưa được định nghĩa

    • OKF trông ổn, nhưng bị ràng buộc vào Markdown
      Một tài liệu Markdown chỉ cần thêm type vào YAML ở phần đầu là có thể trở thành tài liệu OKF
      Tôi tự hỏi liệu có thể có một ngôn ngữ đồ thị tri thức dùng được cả trong văn xuôi Markdown, trong code block Markdown, và ở bất kỳ đâu có trường văn bản hay không
      Trong ngôn ngữ tối giản https://ddot.it, có thể liên kết cả file ngoài thế giới Markdown, URL và nhãn đơn giản. Cũng giống OKF, nó chỉ là một định dạng duy nhất
      Nói trước cho rõ, chính tôi là người viết đặc tả ngắn đó
    • Không có định dạng đồ thị nào cho thấy các quan hệ có gắn nhãn giữa các thực thể thì khó mà biểu đạt tri thức tốt được
    • Markdown là định dạng thực tế để LLM và con người cùng tương tác
      Tôi đồng ý rằng không thể biểu đạt tốt mọi thứ, nhưng đó lại không phải trọng tâm. Markdown có vẻ thắng vì nó là mẫu số chung thấp nhất cho cả con người lẫn mô hình AI

  • Cứ mỗi 10 năm lại xem lại các định dạng Semantic Web như RDF/OWL là một niềm vui
    Rồi sẽ có một năm mà điều đó thực sự thành hiện thực
    https://en.wikipedia.org/wiki/Semantic_Web

  • Bản gốc có nhiều liên kết bị hỏng nên tôi để lại kho lưu trữ ở đây
    https://github.com/GoogleCloudPlatform/knowledge-catalog
    Đặc tả: https://github.com/GoogleCloudPlatform/knowledge-catalog/blo...

  • Theo cách tôi hiểu thì vì chúng ta không thể nhìn vượt quá 3 chiều, nên về bản chất đây gần giống một bệ đỡ cho con người
    Nếu chúng ta sắp xếp tương đối tốt, thì có thể kỳ vọng agent nhận Markdown rồi dựng hạ tầng đồ thị trong bộ nhớ hoặc lưu vào Neo4j

  • Có chỉ định một biến thể của Markdown, ví dụ như CommonMark, hay không?
    Khi lướt qua vài trang đầu tôi không thấy nội dung liên quan, nhưng với một đặc tả thì điều đó có vẻ khá quan trọng

  • Thứ Google công bố rốt cuộc chỉ là Markdown kèm YAML frontmatter. Xin mọi người một tràng pháo tay. Hẳn cả một đặc tả 15KB là để làm việc này
    Nếu ai cũng có thể ngừng dùng YAML kiểu “ôi, lại thiếu một dấu thụt lề rồi” thì tôi đã bớt mỉa mai hơn

  • Với tư cách là người đã thấy rất nhiều PDF phải được “dịch” sang Markdown, tôi thấy đây là một lựa chọn kỳ lạ
    Tôi hiểu mục tiêu lớn là để AI dễ tiếp cận, nhưng nếu đằng nào cũng sẽ huấn luyện mô hình thì tại sao không huấn luyện bằng một định dạng tốt hơn?
    Markdown khá hạn chế, ví dụ còn không render được bảng lồng nhau. Nếu mục đích của “tri thức mở” là AI, thì tôi cũng không rõ có cần nhất thiết dùng một định dạng mà con người thật ra sẽ không đọc hay không

  • Tôi thích cách tiếp cận này. Tôi rất thích tổ chức tri thức theo thứ bậc
    Theo tôi, các lớp trừu tượng quản lý tri thức hiện tại của Claude gần như đều hỏng. Điều đó lộ ra khi bạn chạy nhiều coder cùng lúc hoặc phải tạo hơn 1.000 skill. Ví dụ: https://news.ycombinator.com/item?id=48407998

  • Nên xem barrasindustries.com/okfind/
    Đây là một ý tưởng về registry cho bundle OKF