EXCOIN / AI ENGINEERING

RAG para conocimiento empresarial con respuestas comprobables

La generación aumentada con recuperación combina búsqueda en fuentes internas y un modelo de lenguaje. Aporta valor cuando se puede inspeccionar la evidencia, respetar permisos y reconocer una respuesta desconocida.

01 / ENGINEERINGCS · EN · ES
01 / 08

Primero la fuente y después el modelo

El conocimiento empresarial está repartido entre documentos, wikis, contratos, bases de datos y personas. RAG puede ayudar cuando alguien necesita una respuesta fundamentada en esos materiales y abrir una lista de archivos no resuelve la tarea. Un modelo de lenguaje puede resumir el material encontrado según la pregunta. No garantiza que ese material sea correcto, actual o accesible para quien consulta. Comience con un inventario de fuentes y responsabilidades, no con un modelo elegido a partir de una demostración pública.

Para cada colección registre responsable, frecuencia de cambios, reglas de acceso y significado de las versiones archivadas. Un procedimiento aprobado puede tener autoridad diferente a la de una nota antigua de chat. Mezclarlos sin distinción en un índice puede producir una respuesta fluida pero incorrecta. La calidad del catálogo documental forma parte de la calidad de la respuesta. En ocasiones conviene ordenar primero los contenidos y sus nombres. Ninguna técnica de recuperación arregla por sí sola un conocimiento contradictorio y sin dueño.

02 / 08

Siga el recorrido de la pregunta a la respuesta

Un flujo habitual recibe una pregunta, recupera pasajes pertinentes, se los entrega al modelo con instrucciones de basarse en ellos y presenta la respuesta con enlaces. Cada paso puede fallar de manera distinta. La consulta quizá no coincida con el vocabulario del documento, la búsqueda puede escoger una versión vieja, un pasaje puede perder contexto y el modelo puede unir afirmaciones incompatibles. Microsoft describe RAG como recuperación, preparación de contexto y generación, y señala que el contexto del modelo tiene límites. Enviar todos los documentos no es útil ni económico.

Un diseño concreto debe establecer qué partes de la pregunta guían la búsqueda, cómo se filtran resultados por permisos y qué verá quien consulta. La respuesta puede incluir fuentes directas, fechas de vigencia y una advertencia cuando falte evidencia. Ante una pregunta compleja, mostrar documentos contradictorios puede ser más honesto que emitir una sola conclusión segura. Distinga una afirmación presente en la fuente de una recomendación inferida por el modelo. Esa separación facilita la revisión y la confianza.

03 / 08

Indexar no consiste en importar una vez

Un documento debe incorporarse, dividirse en partes útiles, recibir metadatos y representarse para su recuperación. Los fragmentos grandes aportan ruido; los muy pequeños pierden el contexto. Tablas, anexos y escaneos requieren tratamiento distinto del texto limpio. Conserve la relación de cada fragmento con archivo original, versión, ubicación y permisos. Sin ella no se pueden ofrecer citas fiables ni retirar contenido con seguridad tras un cambio de acceso. Prepare la eliminación y sustitución antes de la primera carga.

Compare búsqueda de texto completo, vectores semánticos y su combinación con preguntas reales. Un número exacto de contrato puede favorecer la coincidencia textual; una pregunta expresada de otra forma quizá requiera similitud semántica. Reordenar candidatos puede mejorar la relevancia, pero añade latencia y coste. El tamaño de los fragmentos y la cantidad de resultados deben decidirse con mediciones, no con una receta universal. Versione el proceso de indexación para poder explicar una caída repentina de calidad.

04 / 08

Los permisos deben sobrevivir al índice

Nadie debe recibir una respuesta basada en un documento que no puede abrir directamente. La revelación indirecta dentro de un resumen también cuenta. Un sistema seguro aplica el control al recuperar o antes de entregar el texto al modelo; ocultar el enlace final es insuficiente. Los cambios de rol tienen que afectar las búsquedas sin retrasos peligrosos. Retirar un documento exige además una ruta clara por índices y cachés. Son requisitos del producto, no simples opciones del motor de búsqueda.

Microsoft documenta el filtrado de seguridad por documento en escenarios RAG, aunque el mecanismo depende del producto y de la fuente de identidades. Una implementación propia necesita pruebas con varias funciones y accesos realmente diferentes. Compruebe cachés, conversaciones compartidas, registros analíticos y respuestas exportadas. Una comprobación de permisos sirve de poco si funciona en la primera consulta, pero un fragmento sensible sigue visible en el historial para otro grupo. Incluya la revocación en las pruebas.

05 / 08

Evalúe recuperación y generación por separado

Un buen modelo no puede fundamentar una respuesta cuando la búsqueda no entrega el documento necesario. Prepare preguntas representativas y marque fuentes esperadas, respuesta admisible y casos en los que conviene abstenerse. Mida si aparece la fuente correcta, si una versión obsoleta queda por delante y si se recupera el pasaje necesario. Microsoft Foundry separa la evaluación de la recuperación y la respuesta final. Así se descubre qué componente mejorará realmente un cambio propuesto.

Después valore precisión factual, completitud, citas, afirmaciones sin apoyo y claridad. Los indicadores automáticos ayudan a comparar versiones, pero los procesos importantes necesitan revisión humana. Incluya preguntas corrientes, ambiguas y adversarias en todos los idiomas de uso. No ajuste el sistema solo con los ejemplos que luego se emplearán para anunciar su éxito. Reserve casos para pruebas independientes después de cambiar modelo, índice o instrucciones. Guarde las versiones junto a los resultados.

06 / 08

Haga útiles las citas y la incertidumbre

Una cita debería llevar al pasaje concreto que sustenta una afirmación. El enlace a un documento completo es una prueba débil si tiene muchas páginas o versiones contradictorias. Las personas deben poder abrir la fuente y conocer su vigencia. Si el material encontrado no responde, el sistema debería reconocerlo y ofrecer los documentos disponibles o un contacto humano. Un tono seguro sin evidencia aumenta la posibilidad de actuar sobre una conclusión equivocada.

RAG ayuda a trabajar con conocimiento; no aprueba decisiones automáticamente. Para asuntos jurídicos, financieros, de seguridad o laborales, defina qué puede sugerir el sistema y qué debe confirmar una persona autorizada. La interfaz debe explicar ese límite en la tarea concreta. Una respuesta puede resumir bien un procedimiento interno aprobado y no resolver un caso nuevo. Permita informar de fuentes erróneas y retirar temporalmente una colección problemática mientras se corrige.

07 / 08

Proteja frente a instrucciones dentro de documentos

El texto recuperado es información, no un administrador de la aplicación. Un documento puede intentar cambiar instrucciones del modelo, pedir más datos o activar una acción indeseada. OWASP advierte que RAG por sí solo no elimina la inyección de instrucciones. La aplicación debe separar el contenido de las reglas del sistema, limitar herramientas y validar las acciones sensibles fuera del modelo. Es insuficiente añadir una frase que diga «ignore el texto malicioso».

Durante el piloto, incluya instrucciones sospechosas en documentos de prueba y compruebe que no adquieren autoridad ni provocan acciones. Considere también la manipulación de fuentes: ¿quién puede crear, cambiar y aprobar un documento? Las copias y el historial del índice deben permitir identificar un cambio que empeoró la calidad. La seguridad depende de la gestión editorial tanto como de la configuración del modelo. Los roles claros importan más que una interfaz de chat compleja.

08 / 08

Haga un piloto y mantenga el servicio

Limite el primer piloto a una colección útil y a personas que conozcan las respuestas correctas. Mida tiempo hasta hallar información, precisión de fuentes, respuestas sin apoyo, latencia y coste por pregunta realmente resuelta. Clasifique errores: documento desactualizado, recuperación deficiente, síntesis incorrecta o permiso mal aplicado. Esa clasificación indica si invertir en contenido, ajuste del índice, modelo o interfaz. Una puntuación general de satisfacción no explica lo que debe corregirse.

Después del lanzamiento, planifique reindexación, eliminación, actualización de permisos, revisión de fallos y pruebas regulares con preguntas estables. La gente debe saber dónde comunicar un error y cómo se corrige la fuente. Para algunas tareas, una buena búsqueda textual con navegación clara puede ser más barata y precisa. Es un resultado válido de la comparación. EXCOIN puede diseñar y evaluar un enfoque según documentos y límites operativos reales; esta página no promete cifras de precisión ni retorno sin pruebas.

Fuentes

Consultar proyecto