Cómo Claix responde preguntas sobre tus documentos, sin una base de datos vectorial

Los espacios no son un paso de subida aparte. Cualquiera de los endpoints de extracción acepta un space_id opcional en la petición. Pasa el mismo space_id en tantas extracciones como quieras y cada una se une a ese grupo. No hay una llamada de «añadir documento al espacio» que recordar por separado: la agrupación ocurre en el momento en que se procesa el documento, un detalle pequeño que evita documentos extraídos y luego olvidados antes de que nadie los agrupe.

Esta es la parte fácil de pasar por alto y la que más importa. Un espacio de conocimiento puede crecer sin límite por tu lado, pero una llamada a space-context no puede entregar todo eso a un modelo: deja de ser precisa (y deja de ser asequible) bastante antes de «ilimitado».

Hay un tope: los 50 documentos añadidos más recientemente, y un presupuesto compartido de 200.000 caracteres entre los que se seleccionan. Si un documento se recorta para caber, al modelo se le dice de forma explícita que no vio el documento entero: no responde en silencio como si tuviera la información completa cuando no la tiene. Los documentos caducados (si has puesto una ventana de retención) no cuentan en el espacio, así que una factura vieja que ya no debería considerarse no desvía un total sin que se note.

Nada de esto es recuperación por similitud. Se parece más a «estos son los datos que están de verdad en alcance, acotados por recencia y tamaño, y esto es lo que quedó fuera»: un problema de presupuesto, no de búsqueda.

Si la verificación de fuente está activa en un espacio, la respuesta no es solo el valor: es { value, source }. En una respuesta que cruza documentos, el campo source nombra de qué documentos salió, por document_id y nombre de archivo, y dice de forma explícita cuándo se cruzó más de uno para producir el número. Si en los documentos no hay nada que sostenga una respuesta, source vuelve como requires_human_revision, en lugar de una conjetura vestida de hecho.

Es el mismo mecanismo tanto si preguntas por un documento como por cincuenta: document-context y space-context comparten la forma de la respuesta a propósito. No es una función especial del «modo espacio». Es lo que hacen los dos endpoints.

Respuesta corta: porque las preguntas que la gente hace de verdad sobre un espacio suelen ser del tipo «esta factura coincide con su contrato» o «suma los totales de estos tres archivos», y eso no son preguntas de similitud. La distancia del coseno no te dice si 48.320€ es la suma correcta de tres líneas. Una coincidencia de texto y un modelo que puede leer los documentos relevantes enteros llega ahí con más fiabilidad, y la respuesta a «qué miró de verdad» es un nombre de archivo y un document_id, no una conjetura sobre qué fragmento eligió el recuperador.

Esto no es decir que nadie debería usar una base de datos vectorial. Si buscas en una biblioteca grande y casi estática, y la pregunta es «encuéntrame cosas relacionadas conceptualmente con X» y no «cuadra estos números concretos», los embeddings resuelven un problema real que la coincidencia exacta no resuelve. Claix está hecho para el segundo tipo de pregunta, no como sustituto del primero.

Dos facturas y un contrato, agrupados en el mismo espacio en el momento de la extracción. Una llamada, y la respuesta que vuelve. Ese es todo el mecanismo. Tres endpoints, una forma de respuesta compartida y un presupuesto que dice con honestidad qué miró y qué no.