Es el tercer día de un proyecto con un corredor de seguros de tamaño mediano, y el responsable de operaciones de siniestros solicita una herramienta de chat capaz de responder rápidamente a los ajustadores. Quieren que cite las normas de póliza más recientes, explique las excepciones y señale la página exacta en el manual correspondiente. En esa misma reunión, el departamento legal añade una restricción más: la herramienta nunca debe mostrar contenido de un contrato de cliente a menos que el ajustador esté asignado a esa cuenta.
Aquí es donde entra en juego la generación aumentada por recuperación (RAG) específica para el cliente en el trabajo de despliegue avanzado (FDE). El RAG específico para el cliente es una configuración en la que el sistema de IA responde extrayendo primero datos de las fuentes propias de ese cliente y, a continuación, redactando la respuesta a partir de dichos datos. Se denomina “específico para el cliente” porque las fuentes cambian con el tiempo y porque es el cliente —y no nosotros— quien decide qué constituye una respuesta aceptable.
En la práctica, no estamos entregando un chatbot genérico, sino un flujo de trabajo de respuesta vinculado a documentos reales, permisos reales y resultados empresariales reales. Para el corredor, “correcto” significa que la respuesta coincide con la versión actual del manual, la cita y respeta las normas de acceso a nivel de cuenta, incluso cuando la pregunta es ambigua.
La clave del enfoque FDE es tratar el RAG como un sistema integral (de extremo a extremo), no como una simple funcionalidad. Si nos limitamos a pensar en los prompts del modelo, pasamos por alto los elementos que garantizan su seguridad y fiabilidad en producción. El resto de esta lección se centra en el caso de este corredor, ya que cada decisión que se tome repercutirá directamente en lo que vea el ajustador en el momento en que necesite una respuesta.
Los fallos de producción en sistemas RAG rara vez son espectaculares; suelen ser silenciosos, plausibles y costosos. El ajustador recibe una respuesta que parece correcta, actúa en consecuencia y solo más tarde alguien se percata de que el siniestro se gestionó aplicando una norma errónea.
Consideremos la siguiente situación: el corredor sube un nuevo boletín sobre “Excepciones por daños causados por agua” el lunes. El miércoles, la herramienta de chat sigue respondiendo con información del manual del mes anterior porque la canalización de contenido no volvió a procesar el nuevo archivo. No se produce ningún error y el sistema puede incluso citar un número de página real; simplemente, no es el número de página correcto para el conjunto de pólizas vigente.
Otro fallo habitual tiene que ver con los límites de acceso. Si la fase de recuperación tiene acceso a un documento, el sistema de IA podría acabar resumiéndolo, incluso cuando el usuario final no debería tener acceso a dicha información. Por este motivo, los permisos no son un mero detalle de la interfaz de usuario en los sistemas RAG. Forman parte del diseño de recuperación de información y deben aplicarse antes de que se envíe cualquier texto al modelo.
Las omisiones silenciosas son otro problema crítico. Una pregunta como «¿Podemos prescindir de la inspección si los daños son inferiores a 2000?» podría requerir una cláusula de excepción específica. Si el sistema de recuperación no la encuentra, el modelo a menudo intentará ser útil de todos modos, cubriendo el vacío con una regla de apariencia genérica. Sin mediciones, no se detectará esta desviación hasta que el negocio presente una queja.
Analice las principales formas en que estos fallos repercuten en el negocio.
Asume la deriva, demuestra la calidad Si no estás monitoreando la calidad a lo largo del tiempo, esta ya está cambiando sin que aún puedas percibirlo.
Estos modos de fallo plantean la verdadera pregunta sobre FDE (Desarrollo y Evaluación de Funcionalidades). ¿Qué debemos decidir, y en qué orden, para que el sistema siga siendo correcto a medida que cambian los documentos, los usuarios y las reglas?
El trabajo de RAG (Generación Aumentada por Recuperación) específico para un cliente es una cadena de decisiones en la que cada eslabón modifica lo que el siguiente puede hacer de forma segura. Si pasamos directamente a los embeddings o a los tamaños de los fragmentos (chunks), terminaremos reescribiendo el sistema más adelante cuando surja una regla de negocio que debería haber sido un requisito fundamental desde el principio.
Comienza con requisitos lo suficientemente específicos como para poder probarlos. Para el caso de la correduría de seguros, redactamos criterios de aceptación como “debe citar la sección exacta del manual” y “debe rechazar la solicitud cuando el usuario carezca de acceso”. No son objetivos vagos; son comprobaciones de aprobado/suspendido que podemos convertir en un conjunto de evaluación.
Lo siguiente son los datos. Mapeamos las fuentes que alimentarán la recuperación y cómo cambian: manuales en SharePoint, boletines por correo electrónico, contratos de cuentas en una exportación de CRM. También mapeamos quién tiene permiso para ver qué, ya que ese modelo de permisos determinará la indexación y el filtrado en el momento de la consulta.
Luego viene el diseño de la recuperación. La recuperación es el proceso mediante el cual el sistema selecciona qué fragmentos de documentos mostrar al modelo. La gran decisión es si podemos filtrar por permisos en el momento de la consulta o si necesitamos índices separados por segmento para evitar fugas de información. En el caso de la correduría, los contratos de cuentas a menudo obligan a aplicar un filtrado estricto, ya que un solo error constituye un incidente grave.
El grounding (anclaje o fundamentación) es lo que hacemos para mantener al modelo vinculado al texto recuperado. Por lo general, incluye reglas como “responder únicamente basándose en el contexto proporcionado” e “incluir citas”. También abarca cómo debe actuar el sistema cuando falta contexto, por ejemplo, formulando una pregunta aclaratoria o respondiendo: “No encuentro esa información en los documentos de póliza actuales”.
La evaluación es la etapa donde hacemos que la fiabilidad sea medible. Una evaluación consiste en un conjunto repetible de preguntas de prueba con comportamientos esperados, que se ejecutan antes y después de realizar cambios. Para esta correduría, nos importa la precisión de las citas, la corrección de las negativas de acceso a documentos restringidos y la cobertura en escenarios de reclamaciones de alto riesgo.
Las decisiones de despliegue convierten todo esto en un sistema operativo. Decidimos cómo se ejecuta la ingesta, con qué frecuencia se actualizan los índices, cómo registramos las solicitudes de forma segura y cómo implementamos las actualizaciones. La iteración se convierte entonces en un ciclo con salvaguardas. Cuando los ajustadores de siniestros reportan un fallo, determinamos si se debió a una carencia de datos, a un problema de recuperación o a una instrucción deficiente, y corregimos la capa correspondiente.
Considera las etapas como un sistema interconectado de decisiones.