Preguntas y respuestas sobre documentos que sí funcionan: patrones y trampas
Hacer preguntas sobre tus propios documentos es la demo de IA más útil y una de las más fáciles de arruinar en silencio. Estos son los patrones que sobreviven al uso real.
"Déjame hacerle una pregunta a mis documentos" es el caso de uso que vende toda la idea de la IA empresarial. Apuntas un modelo a tus contratos, tus políticas, tus manuales, y responde en lenguaje sencillo. La demo es magnética, y la primera versión es genuinamente fácil de construir. El problema es que la versión fácil funciona con las preguntas que probaste y falla con las preguntas que tus usuarios realmente hacen. Este artículo trata sobre esa diferencia: los patrones que hacen que las preguntas y respuestas sobre documentos sean fiables, y las trampas que hacen que parezcan funcionar mientras se equivocan en silencio.
La mayoría de los fallos son fallos de recuperación
El modelo mental que importa: las preguntas y respuestas sobre documentos son dos sistemas, no uno. Primero, la recuperación (retrieval) encuentra los pasajes que probablemente contienen la respuesta. Segundo, el modelo lee esos pasajes y redacta una respuesta. Casi todo el mundo se obsesiona con la segunda parte, pero en la práctica la primera es donde las cosas se rompen. Si el pasaje relevante nunca se pone delante del modelo, ninguna cantidad de generación fluida recuperará la respuesta correcta: el modelo improvisará, con soltura y equivocadamente. Antes de culpar al modelo por una mala respuesta, comprueba si siquiera se recuperó el texto correcto. Normalmente no fue así.
La fragmentación decide qué se puede encontrar
No puedes meter toda una biblioteca de documentos en el modelo para cada pregunta, así que los documentos se dividen en fragmentos, y esos fragmentos son lo que busca la recuperación. Cómo divides es, por tanto, una decisión de diseño silenciosa pero decisiva. Fragmenta demasiado pequeño y una sola respuesta queda partida entre piezas, de modo que ningún fragmento es suficiente. Fragmenta demasiado grande y cada pieza diluye su propia relevancia, enterrando la frase clave en ruido que la recuperación puntúa mal. Peor aún, la división ingenua corta las tablas por la mitad, separa un encabezado de su sección o despoja una cláusula de las condiciones que la rigen. Una buena fragmentación respeta la estructura del documento —secciones, encabezados, elementos de lista— en lugar de cortar cada N caracteres y cruzar los dedos.
La palabra clave y el significado importan ambos
Los primeros sistemas coincidían solo en el significado, usando embeddings para encontrar pasajes semánticamente similares a la pregunta. Esto es potente pero tiene un punto ciego: los términos exactos. Un usuario que busca un número de pieza específico, un código de error, una referencia de cláusula o un nombre propio necesita una coincidencia exacta, y la búsqueda puramente semántica puede desviarse hacia pasajes que tratan "del mismo tema" mientras se pierde la cadena literal. El patrón duradero es combinar enfoques —búsqueda semántica para el significado, búsqueda por palabra clave para la precisión— de modo que tanto "¿cuál es nuestra política sobre el trabajo remoto?" como "sección 4.2(b)" aterricen en el pasaje correcto. Las herramientas para embeddings y recuperación están bien documentadas en recursos como la documentación de Hugging Face; el criterio de diseño es tuyo.
La instrucción de "responder solo a partir del documento"
Una vez recuperados los pasajes correctos, el paso de generación tiene un trabajo que importa por encima de todos los demás: responder a partir del texto recuperado, y solo del texto recuperado. Los modelos llevan consigo una enorme cantidad de conocimiento del mundo, y sin restricciones mezclarán lo que dice tu documento con lo que generalmente creen, que es como un sistema de preguntas y respuestas afirma con seguridad una política que tu empresa nunca escribió. Indica al modelo explícitamente que fundamente su respuesta en los pasajes proporcionados, que cite o referencie la fuente, y que diga con claridad cuando los pasajes no contienen la respuesta. Ese último comportamiento —"los documentos no abordan esto"— es una virtud. Un sistema que siempre responde es un sistema que a veces miente.
Las citas no son opcionales
Una respuesta de preguntas sobre documentos sin un puntero a la fuente es apenas mejor que una conjetura, porque el usuario no tiene forma de verificarla. El patrón que genera confianza es devolver la respuesta junto al pasaje específico del que proviene, para que el humano pueda pulsar y confirmar. Esto hace tres cosas: permite que los usuarios detecten ellos mismos los errores de recuperación, hace el sistema auditable, y desplaza el comportamiento del modelo hacia respuestas fundamentadas porque ahora tiene que señalar evidencia. Para cualquier cosa de consecuencia —legal, médica, financiera, de cumplimiento—, las citas no son un detalle agradable. Son el mecanismo por el cual un humano sigue siendo responsable de la decisión, que es exactamente el tipo de control que marcos como el NIST AI Risk Management Framework esperan cuando las consecuencias son reales.
Las preguntas que lo rompen
Incluso un sistema bien construido tiene modos de fallo predecibles que vale la pena anticipar en el diseño. Las preguntas que requieren sintetizar muchos documentos ("cómo ha cambiado esta política a lo largo de los años") tensan la recuperación simple, que está afinada para encontrar unos pocos pasajes relevantes, no para agregar a través de todos ellos. Las preguntas que dependen de lo que los documentos no dicen son casi imposibles, porque la recuperación no puede sacar a la luz una ausencia. Las preguntas comparativas y de conteo ("qué contratos mencionan X") necesitan un enfoque distinto al de la recuperación de pasajes. Y las tablas, figuras e imágenes escaneadas a menudo llevan la respuesta real siendo invisibles para la recuperación basada en texto. Conocer estos límites te permite acotar el sistema con honestidad en lugar de prometer respuestas que estructuralmente no puede dar.
Mide la recuperación y las respuestas por separado
El patrón final es el que los equipos se saltan, y luego lamentan. Construye un conjunto de preguntas reales con respuestas correctas conocidas y pasajes de origen conocidos, y mide dos cosas de forma independiente: ¿sacó la recuperación a la luz el pasaje correcto, y respondió el modelo correctamente dado ese pasaje? Fundir ambas en una sola puntuación de "¿es buena la respuesta?" oculta dónde falla el sistema, así que afinas a ciegas. Cuando las separas, el diagnóstico es inmediato: un fallo de recuperación y un fallo de generación exigen arreglos completamente distintos. Vuelve a ejecutar esta evaluación cada vez que cambies la fragmentación, la recuperación o los prompts, porque cada uno de esos cambios puede romper en silencio preguntas que antes funcionaban.
Mantén el conocimiento al día y observa lo que preguntan los usuarios
Dos realidades operativas deciden si un sistema de preguntas y respuestas sobre documentos sigue siendo bueno tras el lanzamiento, y ambas son fáciles de descuidar porque no forman parte de la construcción. La primera es la actualidad. En el momento en que tus documentos subyacentes cambian —se revisa una política, se actualiza un manual, se sustituye un contrato—, tu índice queda desfasado, y un índice desfasado produce respuestas obsoletas con seguridad. Necesitas un proceso que reingiera los documentos cambiados y elimine los retirados, porque el sistema no tiene forma de saber que el pasaje que recuperó describe una regla que fue reemplazada el trimestre pasado. Una respuesta que era correcta en el lanzamiento y hoy es errónea está entre los fallos más dañinos, precisamente porque una vez funcionó y todos han dejado de comprobar.
La segunda realidad es que tus usuarios preguntarán cosas que nunca anticipaste, y el registro de preguntas reales es el artefacto más valioso que produce el sistema. Léelo. Las preguntas que reciben malas respuestas te dicen exactamente dónde está fallando la recuperación, dónde tiene huecos la documentación y dónde los usuarios esperan capacidades que el sistema estructuralmente no puede ofrecer. Muchas quejas de "la IA se equivoca" resultan ser "los documentos nunca cubrieron esto", que es un problema de contenido, no de modelo, y uno que solo el registro de preguntas revelará. Trata el sistema en funcionamiento como un instrumento para descubrir qué le falta a tu documentación, y la capa de preguntas y respuestas mejora la base de conocimiento subyacente en lugar de limitarse a tapar sus agujeros.
En resumen
Las preguntas y respuestas sobre documentos funcionan cuando las tratas como un problema de recuperación con un paso de generación encima, no como una caja mágica de respuestas. Respeta la estructura del documento al fragmentar, combina búsqueda semántica y por palabra clave, obliga a que las respuestas se fundamenten en el texto recuperado, devuelve citas y mide la recuperación y la generación como cosas separadas. Sobre todo, diseña para las preguntas que lo rompen en lugar de hacer la demo solo con las que no. Haz eso y preguntarle a tus documentos deja de ser un truco para convertirse en una herramienta en la que puedes confiar.