Un prototipo de RAG puede ensamblarse rápidamente: algunos documentos, un índice vectorial, un modelo de lenguaje y una interfaz de conversación. Las primeras demostraciones impresionan cuando el sistema encuentra información precisa. Dicen poco sobre su comportamiento frente a documentos contradictorios, a los derechos, a las actualizaciones, a preguntas ambiguas y a miles de usuarios.
Pasar a producción consiste en transformar esta cadena en un servicio gobernado. El sistema debe saber qué fuentes utiliza, explicar sus respuestas, medir sus errores, proteger los datos y funcionar incluso cuando uno de sus componentes se ralentiza.
Definir la promesa y los límites
Un asistente documental no debe ser descrito como capaz de « responder a todo ». La promesa debe precisar:
- corpus cubiertos ;
- poblaciones autorizadas;
- tipos de preguntas;
- nivel de frescura ;
- lengua ;
- decisiones que siguen siendo humanas;
- comportamiento fuera de alcance;
- pruebas esperadas.
Una promesa limitada, como encontrar y sintetizar los procedimientos internos con citas, es más comprobable que un asistente experto generalista.
Construir un inventario de fuentes
Cada fuente posee un propietario, un nivel de sensibilidad, una fecha, una versión, un idioma y una regla de conservación. Los documentos obsoletos, borradores o duplicados deben ser identificados antes de la indexación.
El sistema debe mantener el origen hasta el paso utilizado: identificador del documento, versión, sección, derechos y fecha y hora. Sin esta trazabilidad, una cita visual no garantiza que la respuesta se base en la fuente correcta.
Diseñar la ingestión como un flujo de datos
La ingestión no se limita a extraer texto. Debe:
- recuperar el contenido de manera autenticada;
- detectar el formato y los errores;
- extraer estructura, tablas y metadatos ;
- normalizar sin borrar el sentido;
- recortar;
- enriquecer ;
- indexador ;
- validar ;
- gestionar actualización y eliminación.
Cada etapa es idempotente y observable. Un error en un archivo no bloquea todo el lote, pero es visible y atribuible.
El recorte influye en la respuesta
Un fragmento demasiado corto pierde las definiciones y excepciones. Un fragmento demasiado largo diluye los términos útiles y consume el contexto. La segmentación debe seguir la estructura: títulos, párrafos, artículos, procedimientos, tablas y anexos.
Los metadatos del padre se conservan. Para algunas preguntas, un pasaje recuperado debe enriquecerse con su título, su sección o los párrafos vecinos. Varias estrategias pueden coexistir según el tipo de documento.
Combinar los métodos de investigación
La búsqueda vectorial encuentra las formulaciones cercanas. El texto completo sigue siendo superior para referencias, nombres, acrónimos y citas exactas. Los filtros estructurados aplican idioma, fecha, tipo, entidad y derechos.
Una cadena robusta puede combinar:
- candidatos léxicos;
- candidatos vectoriales ;
- fusión de filas ;
- reclasificación ;
- diversificación ;
- umbral de pertinencia ;
- recuperación del contexto vecino.
La sofisticación solo tiene valor si mejora un juego de preguntas real.
Los derechos deben intervenir antes de la generación
Un usuario no debe enterarse de la existencia de un documento prohibido mediante un extracto, una cita o una respuesta. Los permisos deben reproducirse en el índice o aplicarse durante la recuperación, con una estrategia confiable de actualización.
Un filtrado después de la recuperación puede fallar cuando los primeros resultados están prohibidos. El motor debe buscar suficientes candidatos permitidos. Las cachés están segmentadas por política, no solo por el texto de la consulta.
Construir un juego de evaluación antes de optimizar
Un juego útil contiene preguntas frecuentes, raras, ambiguas, fuera de alcance, contradictorias y sensibles. Para cada caso, se conservan las fuentes de referencia y los elementos que una buena respuesta debe incluir.
Es necesario evaluar por separado:
- recuperación: ¿se han encontrado los pasajes correctos?
- generación: ¿la respuesta respeta los pasajes?
- cita: ¿las referencias respaldan realmente la afirmación?
- utilidad: ¿la respuesta ayuda a realizar la tarea?
- rechazo: ¿sabe el sistema no responder?
Bucle de mejora de un RAG basado en un conjunto de preguntas, el análisis de errores y las pruebas de regresión.
Diseñar una respuesta basada en la evidencia
El prompt de generación debe recordar el perímetro, imponer el uso del contexto y solicitar un rechazo cuando falten elementos. Debe distinguir entre cita, razonamiento y sugerencia.
Una respuesta puede indicar:
- síntesis;
- fuentes utilizadas;
- fecha o versión ;
- puntos inciertos ;
- acción siguiente;
- límite del sistema.
Las citas deben remitir al pasaje consultable por el usuario, sujeto a sus derechos. Un enlace a un documento de cien páginas sin localización no es suficiente.
Tratar las fuentes contradictorias
Dos procedimientos pueden contradecirse porque una versión es antigua, porque se refieren a ámbitos diferentes o porque existe un error. El RAG no debe arbitrar silenciosamente.
La estrategia puede favorecer la versión vigente, señalar la divergencia, citar las dos fuentes e invitar a una validación. Las reglas de prioridad están documentadas y probadas.
Saber decir no
El sistema se niega cuando el corpus no contiene pruebas suficientes, la pregunta está prohibida, solicita una decisión fuera de responsabilidad o los derechos no permiten responder.
Un rechazo útil explica el límite y propone una vía segura: reformular, elegir un perímetro, consultar una fuente o contactar a un responsable. No inventa una respuesta genérica para llenar el vacío.
Proteger contra las instrucciones contenidas en los documentos
Un documento puede contener una frase que pida al modelo ignorar las reglas o extraer información. El contenido recuperado debe ser tratado como dato no confiable, nunca como instrucción del sistema.
Las herramientas y acciones están separadas del RAG documental. Los formatos se limpian, los enlaces y scripts se neutralizan, y se prueban los comportamientos anormales. Los documentos públicos e internos pueden aislarse en índices o políticas distintas.
Elegir el modelo por rol
No es necesario el mismo modelo para embeddings, reordenamiento y generación. La elección depende del idioma, del dominio, de la latencia, del costo y de las restricciones de despliegue.
Una arquitectura puede dirigir las preguntas simples hacia un modelo más ligero y los resúmenes complejos hacia un modelo más capaz. El cambio de modelo exige una campaña de regresión, ya que las respuestas y los rechazos pueden evolucionar.
Gestionar el contexto y el costo
Agregar más pasajes no siempre mejora la respuesta. El contexto debe ser pertinente, duplicado, ordenado y limitado. Los documentos largos pueden ser procesados por etapas o resumidos con trazabilidad.
El costo se sigue por solicitud y por tarea realizada: embedding, búsqueda, reordenamiento, tokens, almacenamiento y cálculo. Una caché puede reutilizar resultados estables siempre que se respeten los derechos y la frescura.
Observabilidad
Cada solicitud genera un identificador de correlación. Los registros pueden contener intención, documentos recuperados, puntuaciones, versión de los prompts y modelos, latencia, errores y comentarios, con una política estricta de minimización.
Los tableros de control siguen:
- tasa de éxito ;
- solicitudes sin prueba;
- citas abiertas;
- rechazo ;
- latencia ;
- costo;
- errores de ingestión;
- retraso de actualización;
- cas críticos provenientes de los comentarios.
Retroalimentación del usuario y validación humana
Un botón útil no se limita a pulgar arriba o abajo. Permite indicar fuente incorrecta, respuesta incompleta, información desactualizada o problema de acceso. Los comentarios alimentan una cola de clasificación y el conjunto de evaluación.
Para usos de riesgo, la respuesta es un borrador. Una persona valida, modifica y asume la decisión. El sistema mantiene la distinción entre sugerencia y acción aprobada.
Desplegar progresivamente
Un piloto debe cubrir una población y un corpus limitados, con un soporte identificado. Se definen los criterios para la ampliación: calidad, seguridad, costo, adopción, tasa de escalamiento y capacidad de operación.
El lanzamiento público viene después de las pruebas de autorización, de carga, de inyección de indicaciones, de eliminación de documentos y de recuperación de índices.
Gobernar el ciclo de vida
Las fuentes cambian, los modelos evolucionan y los usos se desplazan. Cada modificación de pipeline, modelo, prompt o política recibe una versión y una evaluación. Los índices pueden reconstruirse y la versión antigua conservarse el tiempo de un retorno.
Un comité de producto arbitra los nuevos corpus, el nivel de riesgo y las solicitudes de acción. El RAG se convierte así en una capacidad controlada, no en una demostración aislada.
De la respuesta impresionante al servicio confiable
La producción exige menos magia y más pruebas: corpus gobernado, investigación evaluada, derechos, rechazos, observabilidad y explotación. Es esta disciplina la que transforma un LLM en una herramienta de trabajo.
Partitech desarrolla cadenas RAG, integraciones de modelos y componentes de código abierto alrededor de PHP, Mistral y PostgreSQL/pgvector. El acompañamiento puede cubrir la planificación, el prototipo, la evaluación, la seguridad y la puesta en producción.
Hablemos de su proyecto
Enmarcar o industrializar su asistente documental con Partitech. Contacte a Partitech.