Dev.to · 10 min read

¿Cómo sabe Claude si una cita de una base de conocimiento de osFoundry sigue vigente?

¿Cómo sabe Claude si una cita de una base de conocimiento de osFoundry sigue vigente?

Estas son las herramientas de base de conocimiento que recibe un chat de Claude o Claude Code desde el servidor MCP de osFoundry. Se obtuvieron con un tools/list sin autenticar el 2026-11-08 y se recortaron a lo que importa aquí: {"name": "search_knowledge_base", "description": "Search current published articles in one granted knowledge base. Results cite the article ID and updated time; this is a live database read.", "inputSchema": {"required": ["knowledge_base_id", "query"], "properties": {"query": {"type": "string", "minLength": 2, "maxLength": 200}, "limit": {"type": "integer", "minimum": 1, "maximum": 20}}}, "annotations": {"readOnlyHint": true}} {"name": "read_knowledge_article", "description": "Read one current published article by ID from a granted knowledge base and return a stable citation.", "inputSchema": {"required": ["knowledge_base_id", "article_id"]}, "annotations": {"readOnlyHint": true}} {"name": "edit_knowledge_article", "description": "Replace article content and optionally its title. Supply the version from read_knowledge_article; concurrent changes are rejected.", "inputSchema": {"required": ["knowledge_base_id", "article_id", "content", "expected_version", "idempotency_key"]}, "annotations": {"readOnlyHint": false, "destructiveHint": true, "openWorldHint": true}} {"name": "poll_resource_events", "description": "Resume from an event sequence for one granted channel, Note, knowledge base, record, or session.", "inputSchema": {"required": ["resource_type", "resource_id"], "properties": {"after_sequence": {"type": "integer", "minimum": 0}, "limit": {"type": "integer", "minimum": 1, "maximum": 100}}}, "annotations": {"readOnlyHint": true}} Si lees las descripciones juntas, el diseño sale solo. Un resultado de búsqueda trae un ID de artículo y una hora de actualización. Una lectura devuelve "a stable citation" (una cita estable). Una edición necesita "the version from read_knowledge_article" (la versión de read_knowledge_article). Y hay un log de eventos por base de conocimiento que se puede retomar desde un número de secuencia. La hora de actualización de la cita y la versión que debe indicar una edición son, en la práctica, el mismo tipo de valor: el propio cliente de osFoundry para estas herramientas, connected-cloud-tools.ts en la app de escritorio, tipa expected_version de edit_knowledge_article como format: date-time. Así que una cita no es solo una referencia para el lector. Es un sello de versión que el agente puede comprobar más tarde y, justo después de leer, devolver como token de compare-and-swap. Abajo está lo que eso aporta, medido sobre una reconstrucción. ¿Qué debe contener una cita? Tres candidatas: Cita Sobrevive a un cambio de título Muestra que el contenido cambió Sirve como versión para editar Título del artículo no no no ID del artículo sí no no ID del artículo + hora de actualización sí sí sí, si es reciente El título es lo que quiere ver un lector humano, así que tienta citar solo por título y volver a buscarlo después. Eso solo detecta un artículo que se renombró o se eliminó. Un artículo cuyo texto cambió con el mismo título parece correcto. El ID resuelve los renombrados. La hora es lo que permite comprobar si la cita está obsoleta. La reconstrucción Aquí no se ejecuta ningún binario de Claude. kb_store.py implementa las cuatro herramientas sobre sqlite con los nombres reales, los argumentos obligatorios y los límites (query de 2–200 caracteres, limit hasta 20 para la búsqueda y hasta 100 para los eventos). Solo los artículos publicados se pueden buscar o leer. Las formas del JSON son propias de la reconstrucción, porque el servidor real solo las devuelve a un cliente autenticado. La cita es {knowledge_base_id, article_id, updated_at}. Cada guardado escribe un evento {sequence, type, article_id, updated_at}, y edit_knowledge_article es un compare-and-swap sobre updated_at con una tabla de idempotencia, en una sola transacción BEGIN IMMEDIATE. sim.py simula una jornada de soporte: 400 artículos, 120 preguntas y 300 guardados hechos por personas a lo largo de 8 horas. La popularidad sigue una curva de Zipf (s = 0.9). Los 10 artículos principales reciben el 36.7% de las preguntas y el 36.7% de los guardados, porque los artículos sobre los que la gente pregunta son los que la gente sigue corrigiendo. De los guardados, el 85% cambia el contenido, el 10% además cambia el título y el 5% despublica. Para cada pregunta, un "Claude" con guion llama a search_knowledge_base, lee los dos primeros resultados con read_knowledge_article y se queda con ambas citas. Cada hora comprueba de tres maneras todas las citas dadas hasta ese momento. Semillas 1–5, Python 3.9.6 en un Apple M1, solo stdlib. La ejecución completa tarda 25.7 s. ¿Qué tan rápido quedan obsoletas las citas? Cinco semillas, 120 respuestas cada una, dos citas por respuesta: Hora Citas hasta ahora Obsoletas Respuestas con una cita obsoleta Detectadas solo por título 1 152 24 (15.8%) 56.6% 5 de 24 2 298 61 (20.5%) 61.7% 17 de 61 4 580 165 (28.4%) 72.1% 56 de 165 6 914 250 (27.4%) 69.4% 84 de 250 8 1,200 369 (30.8%) 80.2% 152 de 369 Al final del día, casi un tercio de todas las citas apunta a un artículo que cambió desde que Claude lo leyó, y cuatro de cada cinco respuestas tienen al menos una cita así. "Cambiado" no significa "incorrecto": una edición puede tocar un párrafo que la respuesta nunca usó. Pero nadie puede saber cuál sin mirar, y la hora de la cita es lo que le dice a Claude dónde mirar. La popularidad explica la mayor parte. La ejecución de control reparte los mismos 300 guardados de forma uniforme entre los 400 artículos: queda obsoleto el 13.9% de las citas (167 de 1,200) y el 46.7% de las respuestas (280 de 600). Cuanto más se usa tu base de conocimiento, más coinciden los artículos que cita Claude con los que se están editando. La comprobación solo por título encontró 152 de las 369 citas obsoletas, un 41.2%. Todas eran cambios de título o despublicaciones. Nunca ve una edición de contenido. ¿Volver a leer cada artículo citado o consultar el log? Coste de las comprobaciones horarias a lo largo del día, sumado sobre las cinco semillas (40 comprobaciones): Estrategia Llamadas Datos devueltos Por comprobación Volver a buscar cada título citado 2,426 3,342 KiB 60.6 llamadas, 83.5 KiB Volver a leer cada artículo citado 2,264 3,445 KiB 56.6 llamadas, 86.1 KiB poll_resource_events desde un cursor 40 153 KiB 1.0 llamada, 3.8 KiB Las dos estrategias basadas en ID encontraron exactamente las mismas 369 citas obsoletas que la verdad de referencia. El script lo verifica con un assert en cada comprobación. La diferencia es el coste. Volver a leer escala con cuántos artículos has citado y paga su texto completo cada vez. Consultar el log escala con cuántos cambios hubo. Menos de 100 cambios por hora caben en una página, así que cada comprobación fue una sola llamada, y Claude vuelve a leer solo los artículos que se movieron. El cursor es un único entero que hay que guardar entre turnos. Antes de la primera consulta, el agente necesita una secuencia desde la que empezar: 0 o la última secuencia que guardó junto con sus citas. ¿Qué pasa cuando Claude edita con la versión de una cita? El segundo experimento usa la misma jornada. Después de cada respuesta, Claude edita el primer artículo que citó, pasando el updated_at de la cita como expected_version, tras un retraso. Cinco semillas, 150 ediciones por retraso: Retraso tras la lectura Rechazadas, la versión cambió Rechazadas, despublicado Reintento tras una lectura nueva 20 s 0 (0.0%) 0 — 15 min 30 (20.0%) 2 30 de 30 guardadas 1 h 57 (38.0%) 3 57 de 57 guardadas 4 h 85 (56.7%) 14 85 de 85 guardadas Una cita es una buena versión para editar durante unos segundos y una mala al cabo de una hora. Los rechazos son el sistema funcionando: cada una de esas escrituras habría reemplazado el texto más reciente de una persona con contenido construido a partir de una lectura anterior. La solución es mecánica. Leer otra vez, volver a aplicar el cambio sobre lo que hay y escribir con la nueva versión. Todos los reintentos tuvieron éxito. También se comprobó la clave de idempotencia. Después de cada edición correcta, se volvió a enviar la misma llamada con la misma clave. 409 de 409 devolvieron el primer resultado marcado como replay y no escribieron ningún evento nuevo. ¿Por qué osFoundry responde solo desde artículos publicados? Porque una cita debería apuntar a algo que una persona decidió que es una respuesta. En la app de escritorio, la pestaña Publishing de un artículo dice "Published articles are used by this workspace's AI assistant and search. They are not visible outside the workspace." (los artículos publicados los usan el asistente de IA y la búsqueda de este workspace, y no son visibles fuera de él). Los borradores son invisibles para search_knowledge_base y read_knowledge_article, y un artículo despublicado desaparece de ambos en la siguiente llamada. En la reconstrucción, despublicar escribe un evento como cualquier otro guardado. 19 de las 600 ediciones con retraso de arriba dieron con un artículo que se había despublicado, y la comprobación informa de esa cita como desaparecida, no como cambiada. ¿Por qué la herramienta de edición está marcada como open-world? edit_knowledge_article es la única herramienta de base de conocimiento con openWorldHint: true. Su efecto no se queda en la conversación. El artículo guardado es de lo que responden a continuación todos los demás asistentes y búsquedas del workspace. Las anotaciones le indican al cliente que esta llamada cambia un estado compartido, y Claude Code pide confirmación antes de ejecutarla salvo que la hayas permitido. osFoundry añade su propio control cuando un chat vinculado trabaja desde la pantalla Knowledge Base dentro de la app: connected-browser-run.ts pide aprobación para cada escritura en la nube y no ofrece un permiso para toda la sesión. Si lo montas tú mismo Pon una versión en la cita, no solo un ID. Usa el mismo valor que tu herramienta de edición acepta como expected_version, para que una sola lectura te dé ambas cosas. Mantén un log de eventos por base de conocimiento con una secuencia monótona y deja que el agente retome desde un número. Un entero de estado en el cliente sustituye a volver a leer todo lo que haya citado. Responde solo desde contenido publicado y registra la despublicación como un evento, para que una cita pueda volver como "desaparecida" y no solo como "distinta". Haz que las ediciones sean compare-and-swap de contenido completo con una clave de idempotencia obligatoria. Indícale al modelo en la descripción de la herramienta que vuelva a leer antes de editar, porque una versión sacada de una cita de hace una hora falla aproximadamente cuatro de cada diez veces. Marca la herramienta de escritura como destructive y open-world, y mantén también en tu lado una aprobación por llamada. Qué entiende osFoundry por recuperación y grounding está en su entrada del glosario sobre RAG. Cómo se organizan sus bases de conocimiento está en la página de bases de conocimiento.

This is a summary aggregated from Dev.to. Read the complete article on the original site:

Read full article at Dev.to

More AI & Machine Learning News