Respuesta directa: elija una empresa de RAG por su capacidad de demostrar una cadena de conocimiento confiable de extremo a extremo. Debe identificar fuentes oficiales, mantener contenido actualizado, preservar permisos, recuperar evidencia relevante, evaluar respuestas y operar fallos en producción. Una demo que responde cinco preguntas sobre un PDF no demuestra esa capacidad. Antes de contratar, exija preguntas reales, respuestas esperadas, citas, pruebas de acceso, métricas, registros y un plan específico de actualización y soporte.
RAG, o generación aumentada por recuperación, conecta un modelo de lenguaje con información externa. Puede mejorar respuestas sobre políticas, productos, contratos, atención y conocimiento interno. Pero RAG no convierte automáticamente documentos desordenados en verdad. La calidad depende de cada eslabón entre la fuente original y la respuesta. Por eso, la selección debe empezar por el riesgo de la decisión y el gobierno del conocimiento, no por el modelo o la base vectorial.
La Cadena de Confiabilidad del Conocimiento MAKINAI
Compare propuestas mediante seis eslabones: autoridad, actualización, permiso, recuperación, respuesta y operación. La nota final no es un promedio simple; el eslabón más débil limita el sistema. Para cada uno, pida evidencia reproducible en su entorno y ejecute una prueba de ruptura. Un proveedor maduro muestra cómo falla de forma segura cuando desaparece una fuente, cambia un permiso, una pregunta es ambigua o un documento intenta manipular el modelo.
1. Autoridad: ¿quién decide qué fuente vale?
Empiece con un inventario de fuentes y responsables. El proveedor debe distinguir registro oficial, copia, borrador, mensaje, contenido externo y conocimiento informal. Pida reglas de prioridad, vigencia, jurisdicción, idioma, duplicación y conflicto. NIST recomienda documentar cómo se adaptan los sistemas generativos, incluida la recuperación y procedencia de datos. Sin linaje, una respuesta segura puede mezclar versiones incompatibles de una política.
- Evidencias mínimas: catálogo de fuentes; propietario por dominio; versión y vigencia; regla de conflicto; metadatos obligatorios; proceso para aprobar o retirar contenido. Prueba de ruptura: incorpore dos políticas contradictorias y compruebe si el sistema identifica la vigente o comunica incertidumbre.
2. Actualización: ¿cuándo el índice deja de representar la realidad?
Pregunte cómo los documentos ingresan, se transforman, dividen, indexan y eliminan. La propuesta debe indicar frecuencia, latencia, detección de cambios, tratamiento de borrado y reconciliación entre repositorio e índice. Un proceso que solo agrega crea conocimiento fantasma: fragmentos revocados siguen disponibles. Exija un indicador de actualización por fuente y un procedimiento para correcciones urgentes.
El proveedor también debe explicar tablas, imágenes, adjuntos, hojas de cálculo y páginas escaneadas. Una pipeline que funciona con texto limpio puede perder condiciones, encabezados o notas críticas. Pruebe con material representativo y no con una muestra preparada por el proveedor.
3. Permiso: ¿la respuesta respeta a quien pregunta?
El control de acceso debe acompañar documento, fragmento recuperado y respuesta. Pregunte si los permisos se aplican antes de recuperar, cómo se sincronizan grupos e identidades y cómo se propagan cambios. Un filtro aplicado después de buscar puede exponer títulos, fragmentos o la existencia de documentos restringidos. Incluya pruebas entre áreas, jerarquías, clientes y países.
- Evidencias: modelo de identidad; herencia de permisos; aislamiento entre tenants; registros de consulta; retención; pruebas negativas; proceso de baja de usuarios. Prueba de ruptura: retire el acceso a un documento y mida cuánto tarda en dejar de influir en cualquier respuesta.
4. Recuperación: ¿el sistema encuentra la evidencia correcta?
Microsoft describe RAG como una pipeline donde la consulta pasa por búsqueda, montaje de contexto y generación. Cada etapa requiere evaluación. Pida métricas de recuperación como cobertura de documentos relevantes y precisión de fragmentos, segmentadas por dominio, idioma y tipo de consulta. Compare búsqueda léxica, vectorial e híbrida cuando corresponda. No acepte una sola tasa agregada que oculte áreas débiles.
Pruebe siglas, nombres similares, preguntas largas, fechas, negación, tablas, consultas multilingües y solicitudes sin respuesta. Si existe RAG agéntico, evalúe selección de herramientas, cantidad de llamadas, latencia y límites de autonomía. La complejidad adicional solo se justifica si mejora una tarea medida.
5. Respuesta: ¿la conclusión está sustentada y sabe detenerse?
Evalúe corrección, relevancia, completitud, uso del contexto y groundedness, dimensiones destacadas por la guía de Microsoft. Cada afirmación importante debe señalar una cita que el usuario autorizado pueda abrir. Defina cuándo el sistema responde, pide aclaración, presenta alternativas o se niega. En contextos legales, financieros, clínicos u operativos, una negativa calibrada puede ser mejor que una tasa alta de respuestas.
Construya un dataset con preguntas reales, respuestas esperadas, fuentes aceptadas, preguntas imposibles y casos adversariales. Reserve un conjunto que el proveedor no use en desarrollo. Registre modelo, prompt, índice y configuración porque las salidas no son deterministas y cambios pequeños pueden modificar resultados.
6. Operación: ¿quién detecta degradación después del lanzamiento?
La arquitectura de referencia de Google Cloud muestra que una aplicación RAG productiva abarca ingestión, almacenamiento, recuperación, modelo e infraestructura. Alguien debe monitorear cada parte: retrasos, conectores, calidad, costo, latencia, acceso indebido y cambios del modelo. Exija dashboards, alertas, responsables, severidades, SLAs, rollback y una cadencia recurrente de evaluación.
La seguridad debe llegar a los documentos recuperados. OWASP describe prompt injection indirecta cuando contenido malicioso en un repositorio influye en la salida. El proveedor debe tratar las fuentes como datos no confiables, separar instrucciones de contenido, limitar herramientas, filtrar entradas y salidas y probar documentos adversariales. RAG reduce algunos errores, pero crea su propia superficie de ataque.
Cómo puntuar proveedores: seis notas y una prueba de ruptura
Asigne de cero a cuatro puntos por eslabón: cero, ausente; uno, promesa; dos, proceso documentado; tres, evidencia de piloto; cuatro, capacidad productiva reproducible. Exija al menos tres en Autoridad, Permiso, Respuesta y Operación. Después ejecute una prueba de ruptura por eslabón. No compense permisos débiles con buena interfaz ni evaluación débil con arquitectura sofisticada. La propuesta ganadora debe reducir riesgo verificable y no solo acelerar la primera demo.
Cómo estructurar un piloto que permita decidir
Elija un dominio con fuentes identificables, responsables disponibles y valor observable. Prepare entre cincuenta y cien preguntas, incluidos casos sin respuesta y con acceso restringido. Defina criterios antes de probar: calidad de recuperación, soporte de fuentes, negativa, latencia, costo y tiempo de actualización. Trabaje con usuarios reales, documente fallos y estime esfuerzo operativo. El piloto termina con una decisión sobre alcance, controles, economía y propiedad, no con un video de demostración.
- Entregables mínimos: inventario; arquitectura; mapa de identidad; pipeline de actualización; dataset de evaluación; resultados segmentados; registro de riesgos; soporte; costos unitarios; documentación y transferencia.
Señales de alerta y próximo paso
- El proveedor empieza por el modelo y no por las fuentes; promete eliminar alucinaciones; omite preguntas sin respuesta; deja permisos para después; las citas no abren la fuente; no existe dataset de evaluación; contenido revocado sigue indexado; seguridad cubre solo login; costos sin volumen; producción depende de trabajo manual no declarado.
Use esta cadena para comparar propuestas y combínela con el scorecard general en https://makinai.co/insights/es/como-elegir-empresa-implementar-ia-brasil-scorecard-30-puntos. Formalice requisitos con https://makinai.co/insights/es/como-crear-rfp-servicios-ia. Si el desafío es convertir datos y contenido en un sistema de inteligencia operable, visite https://makinai.co/services/es/datos-contenido-inteligencia-artificial.