Delimitar el caso RAG, las preguntas y los límites

Un sistema RAG no empieza por elegir una base vectorial. Empieza por decidir qué trabajo de conocimiento debe resolver y qué evidencia sería necesaria para aceptar una respuesta. «Queremos un chat con todos nuestros documentos» describe una interfaz y una ambición de alcance; no describe todavía un sistema evaluable.

Retrieval-Augmented Generation, o RAG, combina recuperación de información externa con generación. El patrón permite proporcionar al modelo contexto que no depende únicamente de sus parámetros y conservar una relación entre la respuesta y las fuentes recuperadas. Esto no convierte automáticamente una colección documental en conocimiento fiable. Si el corpus está desactualizado, los permisos son incorrectos o la recuperación devuelve pasajes irrelevantes, la generación parte de una evidencia defectuosa.

Empieza por la tarea del usuario

Describe quién hace la pregunta, en qué situación, qué necesita resolver y qué hará después con la respuesta. No es lo mismo un empleado que busca un procedimiento interno que un técnico que compara versiones de una especificación o una persona de soporte que necesita citar la política aplicable a un cliente.

Para cada caso registra:

• rol del usuario;
• pregunta o familia de preguntas;
• decisión o tarea posterior;
• fuente que debería sostener la respuesta;
• tiempo aceptable;
• consecuencias de una respuesta incorrecta;
• necesidad de revisión humana;
• información que el sistema no debe revelar.

Esta definición permite juzgar si el sistema ayuda realmente a trabajar. Una respuesta lingüísticamente buena que no permite completar la tarea sigue siendo una mala respuesta.

Decide si RAG es el patrón correcto

RAG tiene sentido cuando la respuesta necesita sintetizar o localizar conocimiento externo, privado, versionado o cambiante y cuando conservar la procedencia aporta valor. Pero no toda consulta empresarial necesita generación.

Puede bastar una búsqueda si el usuario solo necesita encontrar el documento correcto. Puede ser mejor una consulta estructurada si el dato vive en una base de datos y requiere exactitud sobre campos concretos. Puede corresponder a extracción documental si el objetivo es obtener campos de cada archivo. Puede requerir un workflow si la necesidad principal es ejecutar pasos y reglas, no responder preguntas.

Una regla útil consiste en preguntar: «¿Qué aporta la generación después de haber recuperado los datos?». Si la respuesta es únicamente «hacer la interfaz más moderna», el patrón puede estar sobredimensionado.

Construye un inventario de preguntas antes del índice

Reúne preguntas reales siempre que sea posible. No selecciones solo preguntas que sabes que los documentos responden. El conjunto inicial debe contener distintas dificultades:

1. respuesta explícita en un pasaje;
2. síntesis de varias secciones;
3. términos o códigos exactos;
4. paráfrasis con vocabulario diferente;
5. pregunta ambigua;
6. información ausente;
7. fuentes contradictorias;
8. versión obsoleta frente a vigente;
9. usuario sin permisos;
10. pregunta fuera del alcance del sistema.

Para cada pregunta anota la fuente esperada, las condiciones relevantes y qué debería hacer el sistema si no existe evidencia suficiente. Este inventario se convertirá más adelante en parte del conjunto de evaluación.

Define el contrato de conocimiento

El sistema necesita un contrato que limite qué considera evidencia válida. No basta con «usar los documentos». Debes definir qué estados editoriales entran, qué versiones prevalecen, qué repositorios son autorizados y qué ocurre con borradores, copias o documentos sin propietario.

También debes decidir qué puede inferir el modelo. Una fuente que indica «30 días para clientes del plan X» no permite afirmar «todos los clientes tienen 30 días». El sistema debe preservar condiciones, excepciones y alcance.

Un contrato de respuesta inicial puede incluir:

• respuesta breve;
• condiciones y ámbito;
• citas por afirmación relevante;
• contradicciones detectadas;
• información que falta;
• nivel de revisión requerido;
• siguiente acción.

Diseña la abstención antes de la primera demo

Un sistema RAG fiable necesita una forma útil de no contestar. La abstención es adecuada cuando no se recupera evidencia suficiente, la evidencia no responde a la pregunta, falta un dato decisivo, existe un conflicto no resuelto o el usuario no tiene acceso a la fuente necesaria.

«No lo sé» puede ser demasiado poco. Una buena abstención explica qué falta y qué puede hacer el usuario: aportar un dato, consultar al propietario, abrir una fuente candidata o reformular la pregunta.

Tampoco debe rellenar silenciosamente los vacíos con conocimiento general si el contrato del caso exige responder únicamente con conocimiento interno.

Distingue alcance informativo de decisión profesional

RAG puede recuperar información para ayudar a una persona a decidir, pero recuperar políticas o documentos no convierte el sistema en sustituto automático del responsable competente. En materias sensibles, define qué respuestas son informativas, cuáles requieren confirmación y cuáles deben escalarse.

Esta separación es especialmente importante cuando la documentación describe reglas organizativas, seguridad, contratos, datos personales o decisiones con consecuencias materiales.

Ejemplo: procedimientos de soporte

Una empresa quiere que el equipo de soporte consulte procedimientos por producto y región. La pregunta «¿Cómo gestiono una devolución del PX-204 en España?» requiere recuperar la versión vigente del procedimiento, filtrar por producto y región y citar los pasos aplicables.

Si el usuario no indica el plan comercial y el procedimiento cambia según plan, el sistema debe pedir ese dato. Si no existe procedimiento vigente, debe abstenerse y dirigir al propietario de la política. Si el usuario pertenece a otra unidad sin acceso, la recuperación no debe entregar esos fragmentos al modelo.

Ejercicio: especificación del caso RAG

Elige un dominio real y crea una ficha con:

• usuarios y grupos;
• tareas que deben resolver;
• veinte preguntas representativas;
• fuentes esperadas;
• tipos de pregunta;
• decisiones posteriores;
• condiciones que no deben perderse;
• situaciones de abstención;
• contenidos fuera de alcance;
• consecuencias de error;
• revisión humana;
• latencia objetivo;
• criterios mínimos para considerar útil la respuesta.

Después intenta resolver cinco preguntas sin generación: solo con búsqueda o consulta estructurada. Si el valor añadido de la generación no queda claro, revisa el alcance.

Resultado de la lección

Debes terminar con un caso RAG definido por preguntas, usuarios, fuentes, límites y criterios de respuesta. Todavía no has seleccionado embeddings, motor ni modelo. Has definido algo más estable: qué problema de conocimiento existe y qué tendría que demostrar el sistema para considerarse útil y controlable.