Published khoảng 15 giờ trước 14 min read

Open Knowledge Format (OKF): Chuẩn hóa tri thức đầu vào cho RAG và AI Agent

1. Mở đầu

Nếu bạn từng ngồi xây một hệ thống RAG (Retrieval-Augmented Generation) hay một AI Agent nội bộ, chắc hẳn bạn đã gặp cảnh này: dữ liệu "kiến thức" cần đưa vào hệ thống nằm rải rác khắp nơi — tài liệu nội bộ, wiki team, catalog database, file FAQ, PDF chính sách, docs API của bên thứ ba...

Mỗi nguồn lại có một format riêng. Metadata thì mỗi nơi gọi một kiểu: chỗ dùng title, chỗ dùng name; chỗ đánh dấu còn hiệu lực bằng status, chỗ khác lại dùng is_active hay valid. Kết quả là:

Parser để đọc dữ liệu đầu vào ngày càng phình to, phải viết riêng cho từng nguồn.
Không biết tài liệu này có còn đáng tin hay đã lỗi thời (stale) hay chưa.
Không rõ nguồn gốc (provenance): tài liệu này ai viết, viết từ đâu, agent nào sinh ra.
Việc filter, rerank, audit dữ liệu trong pipeline RAG trở nên khó khăn vì metadata không đồng nhất.

Open Knowledge Format (OKF) ra đời để giải quyết các vấn đề đó. Cần nói rõ ngay từ đầu ba điều OKF không phải:

OKF không phải là một database.
OKF không phải là một vector store.
OKF không phải là một framework agent hay chatbot.

OKF đơn giản là một định dạng (format) để biểu diễn tri thức, dựa trên hai công nghệ quen thuộc: Markdown + YAML frontmatter.

2. OKF là gì

OKF = Open Knowledge Format — một đặc tả mở, trung lập về vendor, do Google Cloud công bố như một phần của repo knowledge-catalog.

Mục tiêu thiết kế của OKF gói gọn trong bốn tính chất:

Human-readable — con người mở file lên đọc trực tiếp được, không cần công cụ đặc biệt.
Agent-readable — LLM hoặc AI agent parse được ngay, không cần SDK riêng.
Git-friendly — vì là file text thuần, việc diff, review, blame, version control diễn ra tự nhiên như với code.
Vendor-neutral — không phụ thuộc vào LangChain, Gemini, OpenAI, Google Cloud hay Milvus. Bạn có thể sinh ra OKF bằng bất kỳ công cụ nào, và tiêu thụ nó bằng bất kỳ công cụ nào khác.

Cấu trúc cơ bản nhất của một file OKF trông như sau:

---
type: Policy
title: Chính sách bảo hành
tags: [warranty, customer-care]
---

# Chính sách bảo hành

Nội dung tài liệu...

Một khối YAML ở đầu file mô tả metadata có cấu trúc, và phần thân là markdown tự do để viết nội dung.

3. Vì sao cần chuẩn hóa knowledge

Khi không chuẩn hóa, một hệ thống RAG/Agent thường rơi vào các vấn đề sau:

Mỗi nguồn dữ liệu một kiểu cấu trúc khác nhau.
Parser phải viết riêng cho từng loại nguồn, code ingest ngày càng cồng kềnh.
Metadata lộn xộn, không có quy ước chung.
Search và filter theo metadata (ví dụ: chỉ lấy tài liệu đã verify, chỉ lấy tài liệu thuộc phòng ban X) trở nên khó chính xác.
Không có cách nào biết một tài liệu còn đáng tin hay đã lỗi thời.

Khi có chuẩn hóa như OKF, mọi thứ thay đổi:

Toàn bộ tri thức có cùng "hình dạng" — cùng cấu trúc frontmatter + body.
Metadata rõ ràng, có ngữ nghĩa thống nhất.
Dễ dàng ingest vào pipeline RAG vì logic parse chỉ cần viết một lần.
Dễ review nội dung bằng các công cụ Git quen thuộc (pull request, diff, blame).
Cùng một bundle dữ liệu có thể phục vụ nhiều consumer khác nhau: search index, LLM, graph viewer, hay một giao diện docs nội bộ.

4. Cấu trúc một OKF bundle

Đơn vị phân phối của OKF gọi là bundle — về bản chất chỉ là một thư mục chứa nhiều file Markdown, tổ chức theo cây thư mục thông thường.

Mỗi file .md trong bundle là một concept — một đơn vị tri thức độc lập (một chính sách, một bảng dữ liệu, một sản phẩm, một câu hỏi FAQ...). Ví dụ một bundle cho một hệ thống telco/ISP có thể tổ chức như sau:

knowledge-bundle/
  index.md
  policies/
    warranty.md
    refund.md
  products/
    internet-79.md
    internet-99.md
  faqs/
    billing.md

Trong đó:

index.md đóng vai trò điều hướng — liệt kê và mô tả các nhánh con của bundle.
log.md (nếu cần) ghi lại lịch sử cập nhật của bundle theo thời gian.
Các file .md còn lại chính là các concept — đơn vị tri thức thực sự.

Vì các concept có thể trỏ tới nhau bằng link markdown thông thường ([refund](../policies/refund.md)), toàn bộ thư mục không chỉ là một danh sách file phẳng mà trở thành một đồ thị tri thức (knowledge graph) — nơi một concept có thể tham chiếu, mở rộng, hoặc phụ thuộc vào concept khác.

5. Concept document trong OKF

Mỗi concept document gồm đúng hai phần, đúng như ví dụ ở mục 2:

YAML frontmatter — phần metadata có cấu trúc, nằm giữa hai dấu ---.
Markdown body — phần nội dung tự do, dành cho người đọc và cho LLM.

Về mặt field, OKF chỉ bắt buộc đúng một trường:

Field bắt buộc: type — xác định loại concept (Policy, Table, Product, FAQ...).

Ngoài ra còn có nhóm field nên có, giúp concept trở nên "giàu" thông tin hơn và dễ khai thác hơn trong một pipeline RAG:

title — tên hiển thị.
description — tóm tắt một dòng.
resource — URI hoặc đường dẫn tới tài nguyên gốc (ví dụ bảng BigQuery, trang docs gốc).
tags — danh sách nhãn phân loại.
sources — nguồn dữ liệu mà concept này được tạo ra từ đó.
generated — đánh dấu concept này có phải do máy/agent sinh ra hay không.
verified — trạng thái đã được xác minh bởi con người hay chưa.
status — trạng thái hiện tại của concept (active, deprecated...).
stale_after — mốc thời gian mà sau đó nội dung được coi là có khả năng lỗi thời.

Chính nhóm field này (generated, verified, status, stale_after) là điểm giúp OKF hữu ích hơn hẳn một file markdown thông thường: nó cho phép hệ thống biết được độ tin cậy và tính thời sự của từng mẩu tri thức, thay vì coi mọi tài liệu là ngang hàng nhau.

6. Field thiếu thì xử lý thế nào

Trong thực tế, không phải nguồn dữ liệu nào cũng có đầy đủ metadata ngay từ đầu — nhất là khi bạn đang chuyển đổi (convert) từ một nguồn cũ (wiki, PDF, doc nội bộ) sang OKF. Vì vậy, khi thiết kế pipeline chuyển đổi, nên phân loại rõ field theo ba mức:

Required — bắt buộc phải có, thiếu là coi như không hợp lệ.
Recommended — nên có để concept đủ chất lượng, nhưng thiếu vẫn chấp nhận được.
Optional — có thì tốt, không có cũng không sao.

Một số default gợi ý khi field bị thiếu:

Field thiếu	Xử lý gợi ý
`type`	Gán mặc định `"Document"`, hoặc reject tùy theo policy của hệ thống
`title`	Lấy từ tên file, hoặc từ heading H1 đầu tiên trong body
`tags`	Gán mảng rỗng `[]`
`resource`	Gán `null`
`verified`	Gán mảng rỗng `[]`
`status`	Gán `"unknown"` hoặc `"active"`

Cách tiếp cận permissive này khá quan trọng: nếu ép quá nhiều field bắt buộc, những nguồn dữ liệu nghèo thông tin sẽ rất khó ingest vào hệ thống. OKF chủ đích giữ số field bắt buộc ở mức tối thiểu (chỉ type) để việc bắt đầu sử dụng luôn dễ dàng, và để nhiều mức độ dữ liệu "thô" khác nhau vẫn có thể tồn tại chung trong một bundle.

7. OKF liên quan gì đến RAG

Một pipeline RAG về cơ bản cần hai thứ từ mỗi tài liệu đầu vào:

Content — phần nội dung để chunk và embedding.
Metadata — phần thông tin dùng để filter, rerank, và audit trong quá trình truy vấn.

OKF cung cấp sẵn cả hai, tách bạch rõ ràng ngay trong cấu trúc file:

Phần markdown body → đưa thẳng vào bước chunking.
Phần YAML frontmatter → đưa vào metadata của document.

Việc mapping từ OKF sang một document trong hệ RAG có thể hình dung đơn giản như sau:

OKF frontmatter.title       -> Document title
OKF frontmatter.resource    -> Document url
OKF body                    -> Document content
OKF frontmatter.*           -> Document metadata

Nói cách khác, OKF đóng vai trò như một contract đầu vào chuẩn hóa, giúp bước ingest của pipeline RAG không phải viết logic riêng cho từng loại nguồn dữ liệu nữa — chỉ cần một bộ parser OKF duy nhất.

8. Ví dụ áp dụng với backend RAG

Giả sử pipeline RAG hiện tại có luồng xử lý dạng:

Markdown
  -> chunk
  -> embedding
  -> Postgres
  -> Milvus

Khi đưa OKF vào làm tầng chuẩn hóa đầu vào, luồng sẽ mở rộng thành:

OKF bundle
  -> parse YAML frontmatter + Markdown body
  -> convert thành DocumentCreateRequest
  -> ingest vào backend
  -> lưu metadata vào Postgres
  -> lưu vector vào Milvus

Điểm khác biệt then chốt là bước parse + convert ở đầu: thay vì mỗi loại nguồn dữ liệu cần một adapter riêng để biến thành DocumentCreateRequest, giờ đây chỉ cần một converter OKF duy nhất — miễn dữ liệu đầu vào tuân theo cấu trúc frontmatter + body đã thống nhất. Các bước phía sau (ingest, lưu Postgres, lưu Milvus) không cần thay đổi gì.

9. OKF không thay thế những gì

Để tránh hiểu nhầm về phạm vi của OKF, cần nhấn mạnh rõ những gì nó không thay thế:

Không thay PostgreSQL.
Không thay Milvus (hay bất kỳ vector store nào khác).
Không thay embedding model.
Không thay FastAPI backend hay bất kỳ backend service nào.
Không phải là chatbot.
Không phải là framework agent (LangChain, Google ADK...).

OKF chỉ đóng vai trò là format/contract cho tri thức, ở tầng trước khi dữ liệu được đưa vào các hệ thống kể trên. Nó là lớp chuẩn hóa đầu vào, không phải là một thành phần thay thế cho hạ tầng RAG sẵn có.

10. Lợi ích thực tế

Tổng hợp lại, việc áp dụng OKF cho một hệ thống RAG/Agent mang lại các lợi ích cụ thể:

Dễ chuẩn hóa tri thức đến từ nhiều nguồn khác nhau về cùng một cấu trúc.
Dễ review nội dung bằng quy trình Git quen thuộc (pull request, diff, blame).
Dễ truy vết (trace) nguồn gốc của từng tài liệu.
Dễ biết một tài liệu đã được verify hay chưa.
Dễ phát hiện tài liệu đã stale/outdated nhờ các field như stale_after, status.
Dễ để LLM hoặc agent đọc trực tiếp mà không cần lớp trung gian phức tạp.
Dễ dùng chung dữ liệu giữa nhiều hệ thống khác nhau (search index, LLM, graph viewer, docs UI...) mà không cần convert lại từ đầu.

11. Hạn chế và lưu ý

OKF không phải là "viên đạn bạc" giải quyết mọi vấn đề. Một vài điểm cần cân nhắc trước khi áp dụng:

Cần có discipline (kỷ luật) khi tạo metadata — nếu đội ngũ không tuân thủ nghiêm túc, chuẩn sẽ dần bị phá vỡ.
Nếu ép quá nhiều required field, các nguồn dữ liệu vốn nghèo thông tin sẽ rất khó ingest.
Ngược lại, nếu để quá tự do (gần như không field nào bắt buộc), metadata lại dễ mất chuẩn, quay về tình trạng lộn xộn ban đầu.
Cần tự xây dựng converter/importer riêng nếu muốn tích hợp OKF vào backend hiện có — bản thân OKF không đi kèm SDK bắt buộc.
OKF không tự đảm bảo chất lượng nội dung — nó chỉ chuẩn hóa hình thức và metadata; việc review, verification nội dung vẫn là trách nhiệm của con người/quy trình vận hành.

12. Kết luận

Nên hiểu OKF đơn giản là "chuẩn đóng gói knowledge" — một quy ước tối giản kết hợp Markdown và YAML frontmatter để biểu diễn tri thức theo cách vừa con người đọc được, vừa agent parse được.

Với một hệ thống RAG, OKF không thay đổi vai trò của các thành phần cốt lõi:

Backend vẫn giữ vai trò ingest và search.
Milvus (hay vector store khác) vẫn giữ vai trò vector search.
PostgreSQL vẫn giữ vai trò source of truth cho metadata có cấu trúc.

Điều OKF mang lại là một tầng chuẩn hóa nằm trước toàn bộ pipeline đó — giúp dữ liệu đầu vào từ nhiều nguồn khác nhau trở nên nhất quán, có provenance rõ ràng, và dễ kiểm soát chất lượng hơn trước khi bước vào quá trình chunk – embed – lưu trữ – truy vấn.

Nguồn tham khảo