Google presenta Open Knowledge Format, un estándar para compartir conocimiento entre agentes de IA

 (cloud.google.com)
5 puntos por GN⁺ 4 시간 전 | 2 comentarios | Compartir por WhatsApp
  • Una especificación abierta y neutral respecto a proveedores que permite que varios agentes consuman wikis creadas por distintos productores sin necesidad de traducción, formalizando el patrón LLM-wiki en un formato portable e interoperable
  • OKF v0.1 representa el conocimiento como un directorio de archivos markdown con frontmatter YAML, y funciona sin métodos complejos de compresión, nuevos runtimes ni SDK obligatorios
  • El conocimiento interno de las organizaciones está disperso en sistemas fragmentados como catálogos de metadatos, wikis, comentarios en código o la cabeza de algunos ingenieros senior, por lo que los agentes deben resolver desde cero el mismo problema de ensamblar contexto cada vez
  • La respuesta no es un nuevo servicio de conocimiento, sino el formato en sí: cualquiera puede producirlo sin SDK, consumirlo sin integraciones y gestionarlo en control de versiones junto con el código
  • Se publica como estándar abierto, por lo que su valor depende de la expansión del ecosistema de productores y consumidores

Contexto: un entorno de contexto fragmentado

  • Aunque los modelos fundacionales sigan mejorando, su rendimiento sigue limitado por la falta de contexto relevante, especialmente al construir sistemas de agentes
    • Pueden escribir código, resumir documentación o analizar datasets, pero para producir resultados correctos y ejecutables necesitan la información adecuada
  • La información que usan los modelos dentro de una organización suele ser conocimiento interno, como esquemas de tablas, significado de métricas de negocio, runbooks de incidentes, rutas de join entre dos sistemas o avisos de deprecación de APIs antiguas
  • Ejemplos de sistemas donde esas unidades de conocimiento están dispersas
    • Catálogos de metadatos con su propia API
    • Wikis, sistemas de terceros y unidades compartidas
    • Comentarios en código, docstrings y celdas de notebooks
    • La cabeza de algunos ingenieros senior
  • Para responder una pregunta como “¿cómo se calcula WAU en el event stream?”, un agente tiene que ensamblar la respuesta desde superficies incompatibles entre sí
    • Cada proveedor ofrece su propio catálogo, su propio SDK y su propio esquema de knowledge graph, y el conocimiento no se puede portar entre productos u organizaciones
  • Como resultado, todos los constructores de agentes repiten el mismo problema de ensamblar contexto, los proveedores de catálogos reinventan el mismo modelo de datos y el conocimiento queda atrapado en la superficie donde se generó

El conocimiento como wiki viva

  • Los equipos de desarrollo están cambiando hacia un modelo en el que proporcionan a los agentes una biblioteca compartida en markdown que se vuelve más útil con el tiempo, en lugar de volver a buscar los mismos hechos en los mismos documentos
    • Los agentes se encargan del trabajo rutinario de leer y actualizar sus propios archivos, mientras el equipo cura el contenido y lo gestiona como si fuera código
  • Andrej Karpathy presentó esta idea en el gist de LLM Wiki
    • Escribió que “los LLM no se aburren, no olvidan actualizar referencias cruzadas y pueden manejar 15 archivos al mismo tiempo”
    • El trabajo de bookkeeping que hace que las personas abandonen su wiki personal es justo el tipo de tarea en el que los LLM destacan
  • El mismo patrón de conocimiento-como-wiki aparece repetidamente con distintos nombres
    • Un vault de Obsidian conectado a agentes de programación
    • Archivos de convención del tipo AGENTS.md / CLAUDE.md
    • Repositorios de artefactos como index.md y log.md que los agentes consultan antes de trabajar
    • Repositorios internos de equipos de datos basados en “metadata as code”
  • El patrón es poderoso, pero cada caso sigue siendo hecho a medida (bespoke)
    • Aunque markdown, frontmatter y enlaces cruzados se parecen, no están diseñados para colaborar entre sí
    • No hay acuerdo sobre qué campos debe tener cada documento ni qué significan ciertos nombres de archivo, por lo que el conocimiento sigue aislado dentro del equipo original y se duplica trabajo al crear nuevos agentes

Lo que hace falta no es un servicio, sino un formato

  • La respuesta no es otro servicio de conocimiento, sino un formato para representar conocimiento, que debe cumplir con estos requisitos
    • Cualquiera debe poder producirlo sin SDK
    • Cualquiera debe poder consumirlo sin integraciones
    • Debe preservarse al moverse entre sistemas, organizaciones y herramientas
    • Debe vivir en control de versiones junto al código que describe
    • Debe ser legible para humanos y parseable por agentes, usando los mismos archivos sin capas de traducción
  • OKF es un formato diseñado precisamente para cumplir esos requisitos

Cómo funciona OKF: diseño en una sola pantalla

  • Un bundle de OKF es un directorio de archivos markdown que representa conceptos, incluyendo cualquier cosa que se quiera capturar: tablas, datasets, métricas, playbooks, runbooks o APIs
    • Cada concepto corresponde a un archivo, y la ruta del archivo define la identidad del concepto
    • Ejemplo de estructura de directorios: dentro de sales, carpetas como datasets, tables y metrics, con archivos como orders.md, customers.md y weekly_active_users.md
  • Cada documento de concepto está compuesto por un bloque de YAML front matter para campos estructurados y un cuerpo en markdown para el resto
    • Ejemplos de campos en front matter: type (BigQuery Table), title (Orders), description, resource (URL de consola), tags ([sales, revenue]), timestamp (2026-05-28T14:30:00Z)
    • El cuerpo puede incluir secciones como Schema (columnas order_id, customer_id, con sus tipos y descripciones) y Joins (join con customers usando customer_id)
  • Los conceptos se conectan entre sí mediante enlaces markdown normales, convirtiendo el directorio en un grafo más rico que la simple relación padre/hijo del sistema de archivos
    • El bundle puede incluir opcionalmente archivos index.md (para divulgación progresiva durante la exploración del agente) y log.md (historial de cambios)
  • Toda la especificación de la v0.1 cabe en una página, incluyendo criterios de conformidad, reglas de enlaces cruzados y unos pocos nombres de archivo reservados

Tres principios de diseño

  • Mínimamente prescriptivo (Minimally opinionated)

    • Lo único que OKF exige para todos los conceptos es un solo campo: type
    • Qué tipos existen, qué campos adicionales se agregan y qué secciones aparecen en el cuerpo queda a criterio del productor
    • La especificación define la superficie de interoperabilidad, pero no impone un modelo de contenido

  • Independencia entre productor y consumidor (Producer/consumer independence)

    • Separa con claridad quién escribe el conocimiento y quién lo consume
    • Un agente de IA puede consumir bundles escritos a mano por personas, un visualizador puede explorar bundles generados por un pipeline de exportación de metadatos, y un LLM puede consultar bundles sintetizados por otro LLM
    • El formato es el contrato, y las herramientas en ambos extremos pueden sustituirse de forma independiente

  • Formato, no plataforma (Format, not platform)

    • No depende de una nube, base de datos, proveedor de modelos ni framework de agentes en particular
    • No exige cuentas propietarias ni SDK para leer, escribir o servir el contenido
    • El valor de un formato de conocimiento no viene de quién lo controla, sino de cuántos actores lo usan, por eso se publica como estándar abierto

Lo que acompaña a la especificación

  • Para concretar el formato, se publicaron implementaciones de referencia tanto del lado productor como del consumidor
  • Enrichment agent: recorre un dataset de BigQuery, redacta borradores de documentos de concepto OKF para todas las tablas y vistas, y luego usa una segunda pasada con LLM para rastrear documentación oficial y enriquecer cada concepto con citas, esquemas y rutas de join
  • Visualizador HTML estático: convierte cualquier bundle de OKF en una vista interactiva en forma de grafo contenida en un solo archivo, sin backend, sin instalación del lado del visor y sin que los datos salgan de la página
  • Tres bundles de ejemplo explorables al instante: datasets públicos de GA4 e-commerce, Stack Overflow y Bitcoin, generados por el agente de referencia y confirmados en el repositorio como ejemplos vivos de OKF válido
  • Todo esto es intencionalmente una prueba de concepto
    • El agente muestra una forma de producir OKF, pero no exige un framework ni un LLM específicos
    • El visualizador muestra una forma de consumirlo, pero no exige HTML ni una vista de grafo
    • La expectativa es que el ecosistema de productores y consumidores crezca mucho más allá de lo que hoy se entrega

Próximos pasos

  • OKF v0.1 no es un estándar terminado, sino un punto de partida que evolucionará a medida que aparezcan más productores y consumidores y se aprenda cómo representar el conocimiento que los agentes realmente necesitan
  • Ya sea que se construya un catálogo de conocimiento, un pipeline de enriquecimiento o una wiki para agentes de IA, debe publicarse como abierto desde el primer día para que el formato esté a la altura de su nombre
  • Acciones recomendadas
    • Leer la especificación (es corta)
    • Escribir productores (producers) para sistemas fuente, bases de datos y sitios de documentación
    • Escribir consumidores (consumers) como visores, índices de búsqueda o agentes que razonen sobre bundles
    • Probar la implementación de referencia con datos propios
    • Abrir issues, enviar PR y proponer extensiones (la especificación está versionada y diseñada para crecer con compatibilidad hacia atrás)
  • El repositorio, la especificación y los bundles de ejemplo están publicados en GitHub, y Knowledge Catalog de Google Cloud se actualizó para ingerir OKF y servirlo a agentes
  • La contribución principal es el formato en sí; las herramientas incluidas buscan materializarlo y reducir el costo de probarlo, y OKF está diseñado como una lingua franca para el intercambio de conocimiento en el futuro

Lecturas relacionadas

2 comentarios

 
leothelion 1 시간 전

Supongo que es lo mejor que se puede hacer para quien no logró aprovechar .claude ni .agent
 
GN⁺ 4 시간 전
Comentarios de Hacker News

  • Me gusta la simplicidad de esta especificación OKF, pero no estoy seguro de que todo pueda expresarse bien como “simplemente Markdown”
    Últimamente me ha interesado cómo expresar conceptos para que la IA pueda contribuir de forma efectiva y eficiente en tokens, y normalmente eso termina siendo buscar maneras de representar algo como texto secuencial semiestructurado. Pero en ese proceso no se debe sacrificar la experiencia de representación del conocimiento para humanos
    En particular, si también tienen que contribuir roles que tradicionalmente no son desarrolladores, es muy probable que “un formato de texto raro + git” se sienta mucho peor que las herramientas actuales de autoría y visualización
    Tengo curiosidad por ver cómo surgirán en los próximos años los estándares para expresar semánticamente distintos tipos de conocimiento
    Como ejemplos exitosos que vale la pena mirar están DBML para esquemas/E-R, LikeC4 para arquitectura y enfoques de diagramas-como-código como Mermaid. Los LLM también suelen entender bien estos formatos, y se les puede enseñar con prompts EBNF cortos. Lo importante es que también tienen una forma de visualización agradable para humanos, pueden insertarse de forma natural dentro de Markdown como code block junto al lenguaje natural, y los LLM pueden ayudar a escribir la sintaxis
    Lo más difícil son cosas como hojas de cálculo complejas o Miro, donde la disposición espacial y el color tienen significado implícito. Todavía no he encontrado una buena alternativa
    Algo que probé directamente en el área de ingeniería de datos para que IA y humanos trabajen juntos sobre mapeos source-target y transformaciones es https://equalexperts.github.io/satsuma-lang/. Es una representación textual estructurada y concisa que permite lenguaje natural, y además ofrece buena visualización y herramientas de gramática/LSP para que los agentes no tengan que recortar documentos grandes de forma ineficiente en tokens cuando intentan razonar sobre linaje, completitud o fuentes no definidas

    • OKF se ve bien, pero está atado a Markdown
      Un documento Markdown puede volverse un documento OKF agregando type al YAML del encabezado
      Me pregunto cómo sería un lenguaje de grafos de conocimiento que pudiera usarse dentro de prosa Markdown o bloques de código Markdown, y en cualquier lugar que tenga un campo de texto
      En el lenguaje minimalista https://ddot.it se pueden conectar archivos fuera del mundo Markdown, URLs e incluso etiquetas simples. Igual que OKF, es simplemente un formato
      Para dejarlo claro, yo escribí esa especificación corta
    • No se puede representar bien el conocimiento sin un formato de grafo que muestre relaciones etiquetadas entre entidades
    • Markdown es el formato de facto para la interoperabilidad entre LLM y humanos
      Estoy de acuerdo en que no puede expresar bien todo, pero eso pierde el punto principal. Markdown parece ganar porque es el mínimo común denominador tanto para humanos como para modelos de IA

  • Cada 10 años es divertido volver a mirar los formatos semánticos web de RDF/OWL
    Algún día, uno de esos años sí será el verdadero
    https://en.wikipedia.org/wiki/Semantic_Web

  • Había varios enlaces rotos en el original, así que dejo el repositorio
    https://github.com/GoogleCloudPlatform/knowledge-catalog
    Especificación: https://github.com/GoogleCloudPlatform/knowledge-catalog/blo...

  • Por como lo entendí, como no podemos ver más allá de tres dimensiones, esto es esencialmente más una base de apoyo para humanos
    Espero que, si lo organizamos razonablemente bien, los agentes puedan tomar el Markdown y construir una infraestructura de grafo en memoria o almacenarlo en Neo4j

  • ¿Se especifica alguna variante de Markdown, por ejemplo CommonMark?
    Al hojear las primeras páginas no vi nada al respecto, pero para una especificación eso parece una parte bastante importante

  • Lo que anunció Google al final es Markdown con YAML frontmatter. Un aplauso, por favor. Y 15 KB de especificación para esto
    Si todos pudieran dejar de usar YAML en modo “ah, se me pasó una sangría”, sería menos sarcástico

  • Habiendo visto muchos PDF que hubo que “traducir” a Markdown, esto me parece una elección extraña
    Entiendo que el objetivo principal es facilitar el acceso para la IA, pero si de todos modos van a entrenar modelos, me pregunto por qué no entrenarlos con un formato mejor
    Markdown es bastante limitado y, por ejemplo, ni siquiera puede renderizar tablas anidadas. Si el propósito del “conocimiento abierto” es la IA, tampoco sé si hace falta usar un formato que la gente en realidad no va a leer

  • Me gusta el enfoque. Soy muy fan de la organización jerárquica del conocimiento
    Actualmente, creo que la abstracción de gestión de conocimiento de Claude está casi toda rota. Eso se nota cuando haces correr varios coders al mismo tiempo o cuando tienes que crear más de 1,000 skills. Ejemplo: https://news.ycombinator.com/item?id=48407998

  • Vale la pena revisar barrasindustries.com/okfind/
    Es una idea para un registro de bundles de OKF