Aceptar una base de conocimiento con IA: pruebas del piloto

Esta guía está pensada para quien ya evalúa una entrega. Si todavía estás decidiendo arquitectura, empezá por RAG para empresas. Si necesitás ordenar las fases del proyecto, consultá cómo crear una base de conocimiento con IA.

Escribí el área, las fuentes incluidas, sus versiones, los usuarios habilitados y las tareas que el sistema puede resolver. Una base para consultar procedimientos internos no tiene por qué redactar contratos, modificar el ERP ni responder preguntas de cualquier departamento. Acordá también quién valida el contenido y quién autoriza el paso a operación.

El alcance de aceptación debe coincidir con el alcance contratado. Si durante el piloto aparece otra fuente o una tarea nueva, registrala como ampliación. Separá esa ampliación de la corrección de un comportamiento que ya se había acordado.

Proponemos registrar cada caso con pregunta, usuario o rol, documentos autorizados, evidencia esperada, respuesta obtenida, resultado y responsable del siguiente paso. Para cada prueba fijá de antemano qué cuenta como aprobación. La matriz siguiente propone situaciones a incluir; sus resultados dependen de las reglas de tu empresa.

Ejemplo ficticio: una empresa permite a operaciones consultar su política de devoluciones, pero reserva los acuerdos comerciales individuales a un grupo específico. Probá tanto «¿cuál es el procedimiento de devolución?» como una pregunta sobre el acuerdo reservado. Que la primera funcione no demuestra que la segunda respete permisos.

Usá consultas que el equipo hace en su trabajo y asociá cada una con la fuente que permite resolverla. Incluí formas distintas de preguntar, información ausente y excepciones relevantes. Una persona que conoce el proceso debe validar las respuestas esperadas; el proveedor no debería ser el único juez de su entrega.

Separá las preguntas usadas para ajustar el sistema de las reservadas para aceptar la versión. Registrá qué cambió entre pruebas: documentos, configuración, modelo o reglas. Así podés repetir la evaluación y comprobar una corrección sin depender de una conversación improvisada.

La guía de evaluaciones de Anthropic recomienda definir criterios específicos y medibles ligados a la tarea, incluyendo casos límite. Los porcentajes de sus ejemplos no son umbrales universales para tu base de conocimiento: los objetivos deben corresponder al uso acordado.

Una respuesta puede sonar correcta y citar un documento que no respalda su afirmación. Pedí poder abrir la fuente, ubicar el fragmento y comprobar su versión. Distinguí tres fallos: no se recuperó la evidencia necesaria, la respuesta agregó algo que la evidencia no sostiene o la cita apunta al lugar equivocado. La corrección puede ser diferente en cada caso.

Amazon Bedrock distingue fidelidad, precisión y cobertura de citas en su evaluación RAG. Es una distinción útil para revisar la entrega; un promedio de calidad no sustituye la comprobación de un caso crítico ni concede permiso para divulgar información.

Preguntá cómo se propagan las actualizaciones, qué intervalo se espera y quién verifica un fallo de sincronización. Repetí las pruebas después de una revocación de acceso o una sustitución de documentos, considerando también conversaciones ya iniciadas y enlaces a fuentes. Registrar que alguien tenía acceso ayer no resuelve si debe seguir viéndolo hoy.

Como ejemplo técnico, Microsoft documenta control de acceso en consulta y requisitos de actualización de metadatos. Esa funcionalidad se describe como preview y tiene limitaciones; no es una garantía de permisos automática para cualquier sistema. Exigí que el proveedor explique el comportamiento de la arquitectura que realmente entrega.

Proponemos que una exposición de información no autorizada frene la ampliación del piloto hasta corregirse y volver a probarse. Definí junto a IT otros fallos que deben bloquear el uso, sin esconderlos dentro de un porcentaje general.

El acta de aceptación debe identificar la versión probada, las fuentes y roles incluidos, los casos ejecutados y la evidencia. Registrá pendientes con responsable y condición de cierre. El equipo puede aceptar el alcance, pedir correcciones o limitar el uso a las tareas verificadas; aprobar una consulta interna no aprueba acciones sobre sistemas externos.

Acordá qué cambios requieren repetir pruebas y quién mantiene los documentos después de la entrega. Si el sistema falla, el registro debería permitir distinguir un defecto del alcance original de una petición nueva. La evaluación sigue siendo útil después del piloto, como referencia para revisar cambios.

En Duotach implementamos bases de conocimiento y agentes de consulta por fuentes, permisos y flujos concretos. El relevamiento, el conjunto de pruebas y la implementación forman parte del alcance contratado. La propuesta define qué se entrega, qué queda fuera y cómo se comprueba, según los sistemas y documentos disponibles.

Para conversar sobre el alcance, contanos el área que querés cubrir, las fuentes disponibles y quién aprobaría las respuestas. El servicio de agentes de IA es la entrada para ese trabajo; no envíes credenciales ni documentos sensibles por el formulario.