La estrategia como documento — El séptimo capítulo

Capítulo 6 — La estrategia como documento, no como código

Llegamos al *insight* que más de todos, en el relato de quienes han construido RAG desde 2023 en adelante, recurre como "lo que me hubiera gustado entender desde el primer día".

Los *frameworks* tradicionales tratan la estrategia de búsqueda como código Python. ¿Quieres, para los catálogos técnicos, buscar primero por código de producto, luego por palabras clave, luego por vectores semánticos, y solo en última instancia generar la respuesta? Escribe una función. ¿Quieres, para los álbumes fotográficos, saltarte por completo la búsqueda semántica tradicional y confiar en un *reranker* especializado para imágenes? Escribe otra función. ¿Quieres, para los vídeos corporativos, dividir el audio de la pista visual, transcribirlos por separado, tratarlos como fuentes distintas y luego recomponerlos en la respuesta final? Otra función aún. Cada tipo de contenido, cada dominio, cada cliente acaba generando una rama de código que diverge de las demás, hasta el punto en que modificar una estrategia requiere un lanzamiento de *software*, una revisión de código, un ciclo de pruebas, un despliegue. El tiempo entre "tengo una idea sobre cómo mejorar la búsqueda en los manuales técnicos" y "la idea está en producción" se mide en semanas. Por cada idea.

La idea alternativa es sencilla de expresar y profunda en sus consecuencias: la estrategia de búsqueda no es código. Es un documento. Un JSON — un formato de texto estructurado que cualquier editor, con media hora de formación, puede leer — que dice: "primero prueba esto, luego aquello, si lo primero falla pasa al tercero, reordena así, responde con este modelo." Este documento vive en una base de datos, no en un repositorio. Se modifica desde una interfaz, no desde una pull request. Se versiona, se copia, se especializa por dominio. Una estrategia para los catálogos técnicos, una para los álbumes fotográficos, una para los manuales de instalación, una para los vídeos, una para el audio, una para los contratos legales, una para los balances. Todas coexistiendo en el mismo sistema. Todas modificables en tiempo real.

Quien ha trabajado con este enfoque —llamémoslo, sin demasiada imaginación, Meta-RAG— cuenta con un cambio de velocidad que va más allá de la ingeniería. Una solicitud del cliente tipo "añade una búsqueda específica para los códigos de producto que contienen siglas como CMP40M o RH1M" ya no es un ticket de desarrollo de dos semanas. Es un nuevo paso añadido a un procedimiento JSON, probado en caliente en un entorno de staging, promovido a producción en una tarde. La pregunta "¿qué cambia si usamos un reranker diferente para las fotos, manteniendo el actual para el texto?" se responde modificando una línea de configuración. El experimento no cuesta nada, el rollback no cuesta nada (basta con restaurar la versión anterior del documento), y el conocimiento acumulado —lo que funciona bien para un cierto tipo de contenido— se convierte en un patrimonio versionado y transferible, no el saber tácito de quien escribió esa particular rama de código y hoy está de vacaciones.

También hay un efecto social interesante que emerge en las organizaciones que adoptan este enfoque. Con las estrategias como documento, la frontera entre "desarrollador" y "usuario experto" se desplaza. Un bibliotecario digital, un archivista empresarial, un experto en el dominio —el jefe de la oficina técnica, la responsable de la documentación, el product manager que conoce como nadie las verdaderas preguntas de los clientes— puede leer una estrategia, entender qué hace, sugerir modificaciones, a veces escribirlas directamente. No tiene que pasar por el embudo del ticket de desarrollo, no tiene que explicarle a un desarrollador cosas que el desarrollador no sabe (porque no es su trabajo saberlas). El RAG deja de ser un producto que consumes y se convierte en una herramienta que modelas sobre tu conocimiento organizacional. Esto, en la experiencia de quienes lo han probado, cambia la moral del proyecto antes incluso que las cifras de las métricas.

No es magia, y tiene sus costes. Necesita un motor que ejecute estas estrategias como documento de forma eficiente y segura. Necesita un lenguaje de descripción lo suficientemente rico como para cubrir los casos reales y lo suficientemente pobre como para no convertirse en otra máquina de Turing completa disfrazada. Necesita herramientas de versionado, de prueba, de retroceso. Pero todo esto es problema de quien construye el motor — una sola vez, y para todos los usuarios. El cliente final individual ve solo una cosa: la posibilidad de hacer evolucionar su estrategia de búsqueda a la velocidad del pensamiento, en lugar de a la velocidad del ciclo de lanzamiento de software. Y esto, para quienes están dentro, es una revolución silenciosa que aún no ha encontrado su nombre en las revistas del sector.

Cierre — El séptimo capítulo, en unos meses

A principios de 2026, sumando las lecciones de los capítulos anteriores — las tablas que se perdían, los rerankers mentirosos, las alucinaciones heredadas, las facturas de la nube que crecían más rápido que el valor, los frameworks prometedores pero rígidos — alguien, en Italia, comenzó a construir un servidor RAG diferente. Escrito en Python, pensado para funcionar en hardware accesible, capaz de hablar con modelos en la nube cuando conviene y con modelos locales cuando la privacidad lo impone o el costo no cuadra. Un servidor en el que las estrategias de búsqueda son documentos modificables, el reranker es un proceso local en GPU, las tablas no se pierden porque se tratan como ciudadanos de primera clase, las fotos no heredan objetos de archivos polvorientos de otras épocas, y el costo por consulta — tanto en dinero como en datos filtrados a terceros — es conocible y controlable al céntimo.

No haremos público el nombre del proyecto. Este no es el momento para hacerlo, y no queremos convertir una investigación en publicidad. Pero si los capítulos anteriores te han permitido reconocer una situación que estás viviendo — un chatbot corporativo que responde con seguridad a preguntas incorrectas, un proyecto RAG que no despega desde hace meses, una factura de la nube que crece más rápido que la utilidad que produce, una duda creciente sobre si tus documentos confidenciales están viajando a lugares que desconoces—, entonces vale la pena saber que existe otro camino, que ha sido recorrido por alguien en Italia, y que en 2026 ha comenzado a dar las primeras respuestas que se esperaban en 2023.

La buena noticia es que la IA empresarial, finalmente, está saliendo de la fase demo. La menos buena es que lo está haciendo arrastrando consigo todas las cicatrices del camino: frameworks inflados, dependencias de proveedores, arquitecturas monolíticas, datos sucios, errores silenciosos y una cierta tendencia del sector a vender soluciones antes incluso de haber comprendido el problema. Los hemos contado en seis capítulos. El séptimo — la historia de lo que sucede cuando finalmente alguien hace las cosas bien, con paciencia, en italiano y en código abierto — lo escribiremos pronto, con menos cautela sobre los nombres y más cifras sobre la mesa.

Mientras tanto, si has llegado hasta aquí, ya has realizado una autopsia más exhaustiva que la del 90% de los responsables de la toma de decisiones que en este momento están firmando un contrato para un chatbot empresarial sin hacer ninguna de las preguntas que te has hecho leyendo estos capítulos. Es un punto de partida mejor que el que tuvieron ellos. Y en los próximos meses, la diferencia entre quienes se hicieron estas preguntas y quienes no, será muy visible en las facturas — y en las respuestas que tu IA dará a tus clientes.

Esta investigación se redactó en abril de 2026, basándose en la experiencia de dieciocho meses de diseño, construcción y optimización de sistemas RAG empresariales entre finales de 2024 y principios de 2026.