El motor que tenía seis polos — El mito de las diez líneas de código

Investigación en seis partes sobre las razones por las que el chatbot documental que te han vendido sigue inventando, y sobre la dirección diferente que, a principios de 2026, alguien comenzó a recorrer.

Investigación en seis partes sobre las razones por las que el chatbot documental que te han vendido sigue inventando, y sobre la dirección diferente que, a principios de 2026, alguien comenzó a recorrer.

Introducción — El motor que tenía ocho polos (pero tenía seis)

Milán, marzo de 2026. Un gerente abre el chatbot corporativo interno, de esos montados "en dos semanas" por el departamento de TI con gran entusiasmo y poca desconfianza. Pregunta muy sencilla: "¿Cuántos polos tiene el motor CMP40M?" El chatbot responde con toda la seguridad que saben mostrar los grandes modelos de lenguaje: "El motor CMP40M tiene ocho polos."

Incorrecto. Tiene seis. La respuesta correcta no estaba en el catálogo de 422 páginas que alguien, meses antes, había volcado con la máxima confianza en una base de datos vectorial, convencido de que a partir de ahí el sistema "lo sabría todo". Ese dato, en el catálogo, simplemente no existía. Estaba en un PDF adjunto a un correo electrónico de los técnicos de SEW, archivado en una carpeta que nadie se había molestado en indexar.

Esta escena, con variaciones de sector y de dialecto, se repite en cientos de oficinas italianas. La promesa era simple y seductora: den todos los documentos empresariales a su asistente de IA, y podrá responder a cualquier pregunta sobre ellos. La realidad es mucho más prosaica: el chatbot lee pero no comprende, busca pero no encuentra, y cuando no encuentra — en lugar de decirlo — inventa. Inventa con fluidez, con gramática perfecta, con números plausibles. Lo cual es mucho peor que no responder.

Entre finales de 2024 y principios de 2026 pasamos meses haciendo la autopsia de estos fracasos. No para alimentar polémicas, sino para entender una cosa: ¿por qué una idea tan lineal — "dale los documentos y luego pregúntale cosas" — se vuelve tan difícil cuando sale del escenario de la demo y entra en la sala de los servidores reales?

Esta investigación en seis capítulos cuenta lo que encontramos: errores silenciosos que borraban catálogos enteros, rerankers en la nube con puntuaciones incorrectas, alucinaciones nacidas no del modelo sino de datos contaminados años antes, facturas que encarecían cada consulta por encima de su valor, y frameworks "populares" que prometen todo en diez líneas de código siempre y cuando no se les pida demasiado. Y en el último capítulo, la dirección diferente que alguien, en silencio, comenzó a tomar a principios de 2026 — una arquitectura en la que la estrategia de búsqueda deja de ser código y se convierte en un documento que cualquiera, en la empresa, puede leer y modificar.

Cada capítulo se sostiene por sí solo. Si quieres comenzar con la historia de las 342 tablas desaparecidas, o con la del reranker mentiroso, eres libre de hacerlo. Pero el relato en su conjunto tiene una moraleja que emerge solo al final: el RAG empresarial — ese acrónimo técnico que significa Retrieval-Augmented Generation, es decir, "genera respuestas basándose en documentos que recuperas primero" — aún no es un producto terminado. Es una frontera. Y como todas las fronteras, hasta ahora ha sido contada principalmente por los vendedores. Es hora de escuchar también a quienes han vivido dentro.

Capítulo 1 — El mito de las diez líneas de código

La diapositiva es idéntica en cada conferencia sobre IA desde 2023: "Su asistente documental empresarial en 10 líneas de código." Debajo del título, un bloque de Python en colores pastel que muestra una biblioteca de código abierto —típicamente una de esas célebres estadounidenses, cuyo nombre evoca cadenas de árboles o llamas tibetanas— que carga PDFs, los fragmenta, los pega dentro de una base de datos vectorial y los interroga con un modelo lingüístico. En cinco minutos, tienes un chatbot. En cinco minutos, los aplausos. En cinco minutos, una empresa italiana mediana se convence de que el problema está resuelto y de que su departamento de IT puede lograrlo en dos semanas.

El problema —lo que la diapositiva no dice— es que la demo está construida con tres PDFs bien formateados, una pregunta diseñada a medida para coincidir con el contenido, un escenario sin latencias reales y un presentador que ha probado todo veintisiete veces antes de subir. En la realidad, los documentos empresariales son un desastre geológico: escaneos de escaneos, tablas que se superponen al texto, notas al pie que se infiltran en los párrafos, códigos alfanuméricos tipo "RH1M" que el fragmentador corta por la mitad creyéndolos palabras, imágenes que contienen el setenta por ciento de la información útil pero que nadie extrae realmente, y diseños tan creativos que requieren un arqueólogo más que un parser.

RAG — esta es la idea bajo el capó — es una excelente idea. Toma la pregunta del usuario, busca en tu archivo los documentos más relevantes, pásalos al modelo lingüístico y obtén una respuesta basada en esos documentos. En teoría, resuelve elegantemente el problema de la alucinación: el modelo ya no tiene que "saber" la respuesta, solo tiene que "leerla" en los fragmentos que le has proporcionado. En la práctica, cada eslabón de la cadena — el chunking, el embedding, el retrieval, el reranking, la generación final — tiene sus propias formas de fallar, y la rotura rara vez se manifiesta como un error visible. Se manifiesta como una respuesta ligeramente incorrecta. Luego como una respuesta completamente incorrecta. Luego como un gerente que se pregunta por qué está pagando por un sistema que sabe menos que el becario.

Los frameworks de código abierto que han popularizado el RAG están hechos para demostrar, no para producir. Son concatenaciones elegantísimas de abstracciones en las que cada capa oculta una asunción no dicha: que tus PDFs tengan un OCR decente, que tus fotos ya hayan sido descritas, que tus tablas sigan una convención, que el modelo de embedding hable realmente tu idioma (spoiler: muchos hablan bien solo inglés), que tu archivo ya haya sido limpiado de duplicados. Cuando una de estas asunciones falla —y al menos una falla siempre, casi siempre tres— el sistema no deja de funcionar. Peor: deja de funcionar bien, pero continúa dando respuestas. Respuestas fluidas, seguras, y a menudo desconectadas de la verdad.

Hay una frase que circula entre quienes construyen estos sistemas profesionalmente, y que nunca leerás en los tutoriales: "El RAG es fácil de hacer, y difícil de hacer bien." Entre la primera demo y el servicio en producción hay un abismo que no se llena añadiendo GPU o cambiando el modelo. Se llena comprendiendo algo incómodo: cuando construyes un RAG empresarial no estás escribiendo código. Estás diseñando un pequeño, obstinado motor de búsqueda a medida para tus documentos, con todas las elecciones editoriales que esto conlleva — qué es ruido, qué es señal, qué debe indexarse dos veces, qué debe descartarse. Solo que en los tutoriales de diez líneas estas elecciones se toman por ti, una vez, por alguien que nunca ha visto tus documentos. Y son casi siempre las equivocadas para tu caso.