# Por qué la mayoría de los proyectos comerciales 'AI' son tontos > "Estamos construyendo un asistente de conocimiento con IA que revolucionará cómo nuestros empleados acceden a la información..." > > - Cada anuncio de trabajo, plataforma y propuesta de consultoría en 2024-2025 ## Introducción He pasado el mes pasado o tan apropiadamente sumergiéndome en el espacio comercial de IA. Lee copiosas cantidades de comercialización fastuosidad. Porado sobre docenas de anuncios de trabajo. Saturado a través de más demos de productos de lo que me gustaría admitir. Y he llegado a una conclusión bastante deprimente. **Es casi todo lo mismo.** "Base de conocimiento de la empresa impulsada por la AI". "Búsqueda inteligente de documentos". "Charlador cliente con conocimiento empresarial". Deshágase de la copia de marketing sin aliento y encontrará la misma arquitectura, los mismos modos de fallo, y las mismas partes interesadas decepcionadas cerca de seis meses más adelante. Las variantes de chatbot de clientes son particularmente entretenidas: pueden convertirse en desastres de relaciones públicas notablemente rápidamente cuando los desarrolladores que no entienden las barandillas los dejan sueltos en el público. Nada como tu bot de apoyo ofreciendo alegremente reembolsos que no das, componiendo características de producto que no existen, o yendo en una tangente filosófica sobre el significado de la existencia cuando alguien pregunta acerca de los tiempos de envío. Sin las limitaciones adecuadas, estos bots prometerán felizmente algo, admitirán crímenes que su empresa no cometió, o desarrollarán fuertes opiniones sobre los competidores. Este es el sucio secreto que nadie en la gerencia quiere escuchar: **La mayoría de los proyectos comerciales de IA no son innovadores.** Antes de ir más lejos, un descargo de responsabilidad: no soy un "visionario de la AI" o cualquiera que sea el título del momento impulsado por el bombo (en su mayoría ex "visionarios de blockchain" que han pivotado convenientemente). Soy un ingeniero de software que ha estado construyendo este tipo de sistemas —búsqueda, gestión del conocimiento, procesamiento del lenguaje natural, apoyo a la decisión— durante casi tres décadas. He visto esta imagen antes con sistemas expertos, con web semántica, con big data, con blockchain. [TOC] ## Los dos tipos de proyectos comerciales de IA Deshazte de las tonterías de marketing y encontrarás que aproximadamente el 95% de los proyectos comerciales "AI" se dividen en una de dos categorías: ### Tipo 1: El oleoducto RAG Esta es de lejos la más común. Cada "solución de IA empresarial" sigue este patrón: ```mermaid flowchart LR A[Documents] --> B[Document Ingestion Pipeline] B --> C[Vector Database / RAG] C --> D[Construct Prompts] D --> E[LLM API Call] E --> F[Hybrid Search] F --> G[Response to User] style B stroke:#ff0000,stroke-width:4px ``` Esa caja roja, ahí es donde todo se rompe, más sobre eso en un momento. El tono suena impresionante: "Hemos construido una IA que entiende los documentos de su empresa y puede responder a las preguntas de forma inteligente!" La realidad: Usted ha construido un motor de búsqueda con pasos adicionales y una factura OpenAI de £10.000/mes. ### Tipo 2: El modelo de ajuste fino Este es aún más tonto. El tono: "Hemos entrenado nuestro propio modelo de IA específicamente para su industria!" La realidad: Usted ha tomado el modelo de otra persona y afinado en un conjunto de datos que es probablemente demasiado pequeño, demasiado sucio, y demasiado estrecho para hacer una diferencia significativa sobre sólo utilizar el modelo base con buenos avisos. ```mermaid flowchart TD A[Existing LLM] --> B[Collect Training Data] B --> C[Clean Data - Maybe] C --> D[Fine-tune Model] D --> E[Deploy Model] E --> F[Discover it's not much better than base model] F --> G[Keep paying for inference anyway] G --> H[Hope nobody notices] ``` La mayoría de los proyectos de ajuste que he visto hubieran sido mejor servidos gastando el mismo dinero en mejorar sus avisos y sistemas de recuperación. ## Por qué la ingestión de documentos es donde los sueños van a morir Hablemos de esa caja roja en el diagrama de RAG. **La ingestión de documentos es la parte que falla más a menudo**, y es la parte que recibe la menor atención en las demostraciones llamativas. Esto es lo que muestra la demostración de ventas: - Hermosos PDF que fluyen al sistema - Limpiar el marcado extraído a la perfección - ¡Todo tu conocimiento, buscable por IA! Esto es lo que realmente sucede: ### El problema de PDF Los PDF son una pesadilla. Fueron diseñados para imprimir, no para extraer datos estructurados. Cada analizador PDF que he utilizado tiene diferentes modos de fallo: - Columnas que se fusionan incorrectamente - Tablas que se convierten en galimatías - Encabezados y pies de página que contaminan el contenido - Documentos escaneados que necesitan OCR (y OCR tiene sus propias tasas de error) - Documentos protegidos por la seguridad que no se pueden procesar en absoluto - Problemas de codificación de fuentes que convierten el texto en basura Y eso son sólo PDFs. - Archivos de PowerPoint con texto en SmartArt - Documentos de texto con cambios en la pista - Archivos Excel con celdas fusionadas - Imágenes escaneadas con caligrafía - Formatos heredados de sistemas que murieron en los años 90 ### La catastrofa aplastante Una vez que hayas extraído el texto (pobremente), necesitas trocearlo para tu base de datos vectorial. Aquí es donde ocurre más pensamiento mágico. "¡Usaremos trocitos semánticos!" Genial, tu contrato de 200 páginas es ahora de 500 pedazos, y la IA no tiene idea de cuáles están relacionados o en qué orden aparecen. "¡Usaremos trozos de tamaño fijo con solapamiento!" Perfecto, acabas de dividir una frase por la mitad y la incrustación ahora representa una tontería. ```mermaid flowchart TD A[Original Document] --> B[Chunk 1: This contract shall be governed by] A --> C[Chunk 2: the laws of the State of California] B --> D[Embedding: Legal stuff?] C --> E[Embedding: Geography?] D --> F[User asks about jurisdiction] E --> F F --> G[AI: Based on my knowledge, possibly California, or maybe legal governance, who knows] ``` ### El desorden de los metadatos Un buen RAG necesita buenos metadatos, pero extraer metadatos de los documentos es difícil: - ¿Cuál es la fecha del documento? ¿Es la fecha de creación, la fecha de modificación o la fecha mencionada en el contenido? - ¿Quién es el autor? ¿La persona que creó el expediente, el autor legal o el experto en materia? - ¿A qué categoría pertenece? Su taxonomía probablemente no coincide con la forma en que se organizaron los documentos. - ¿Este documento sigue siendo válido? ¿O ha sido reemplazado por algo más nuevo que su sistema no conoce? La mayoría de las organizaciones tienen décadas de documentos con convenciones de nombres inconsistentes, estructuras de carpetas que tenían sentido para alguien que se fue en 2003, y metadatos que están ausentes o equivocados. ## La Fantasía de los Afinados Permítanme ser claro: el ajuste tiene su lugar, pero la forma en que la mayoría de las empresas lo abordan está fundamentalmente rota. ### El problema de los datos El ajuste requiere datos de formación de calidad. La mayoría de las empresas no los tienen. - Datos ruidosos e inconsistentes repartidos por sistemas - Datos que reflejan cómo se hicieron las cosas, no cómo se deben hacer - Datos que están llenos de errores que nadie nunca se molestó en arreglar - Datos que son propietarios pero no realmente tan valiosos "¡Nos ajustaremos en nuestros tickets de soporte!" Tus tickets de soporte están llenos de clientes frustrados, información incorrecta del personal junior y casos extremos que no representan el uso normal. "¡Vamos a afinar nuestras llamadas de ventas!" ¿Te refieres a aquellas en las que los vendedores hacen promesas que el producto no puede cumplir? ### El problema de la evaluación ¿Cómo sabes si tu modelo afinado es realmente mejor? La mayoría de las empresas no pueden responder esto porque: - No tienen un buen conjunto de datos de referencia - No tienen métricas de evaluación claras. - No han hecho rigurosas pruebas A/B. - Están comparando vibraciones, no datos. He visto empresas pasar seis meses afinando un modelo y luego no tienen manera de demostrar que es mejor que sólo el uso de GPT-4 con un buen sistema de aviso. ### El problema del mantenimiento Los modelos afinados necesitan actualización. Sus cambios de negocio. Sus productos cambian. Sus procesos cambian. Ese modelo afinado en enero ahora está dando respuestas basadas en información anticuada. Pero actualizar significa: - Recolección de nuevos datos de formación - Entrenando de nuevo. - Validación del nuevo modelo - Desplegándolo - Esperando que no introdujeras regresiones. La mayoría de las empresas afinan una vez y luego sólo viven con la deriva. El modelo lentamente se vuelve menos relevante mientras que todo el mundo finge que todavía está agregando valor. ## ¿Qué proyectos "AI" son realmente buenos para No me malinterpretes, hay casos de uso legítimo. ```mermaid flowchart TD subgraph RAGWorks["✅ RAG Works When"] R1[Well-structured docs] R2[Clear metadata] R3[Search + synthesis use case] R4[Heavy ingestion investment] R5[Feedback loops exist] end subgraph FTWorks["✅ Fine-Tuning Works When"] F1[Large high-quality dataset] F2[Base model truly struggles] F3[Ongoing maintenance budget] F4[Clear eval metrics] F5[Already tried prompting + RAG] end style R4 stroke:#00aa00,stroke-width:2px style F5 stroke:#00aa00,stroke-width:2px ``` Las cajas verdes son los prerrequisitos de la mayoría de los proyectos omitir. **"Ya hemos optimizado el impulso y el RAG"** es el bar para afinar. **"Inversión en ingestión pesada"** olvídate de esto y estás construyendo sobre arena. ## Los problemas reales Nadie está resolviendo Mientras que todos están construyendo el mismo gasoducto RAG, los problemas realmente interesantes en IA comercial están siendo ignorados: ### Calidad de los datos La mayor limitación en la efectividad de la IA no es el modelo. Son los datos. La mayoría de las organizaciones tienen: - Los datos se extienden por docenas de sistemas que no hablan entre sí - No hay una sola fuente de verdad para nada - Gobernabilidad de datos que es más aspiración que realidad - Problemas de calidad que nadie tiene presupuesto para arreglar **Pero "la iniciativa de calidad de los datos" no te da un artículo de Forbes como "la transformación de la AI".** ### Integración de procesos Dejar caer un chatbot de IA en un proceso existente no lo hace mágicamente mejor. El proceso necesita ser rediseñado en torno a las capacidades y limitaciones de la IA. La mayoría de las compañías simplemente atornillan IA en procesos rotos y se preguntan por qué no ayuda. ### Colaboración humana-AI Las mejores implementaciones de IA aumentan las capacidades humanas en lugar de tratar de reemplazarlas. Pero eso es más difícil de vender que "AI que hace X automáticamente!" Humanos + IA trabajando juntos requiere: - Puntos de entrega claros - Razonamiento transparente de la IA - Mecanismos de anulación fáciles - bucles de retroalimentación para mejorar La mayoría de los proyectos comerciales de IA tratan al humano como un pensamiento secundario. ### Innovación genuina Las aplicaciones de IA realmente valiosas no son "chatbot en sus documentos". Son aplicaciones que: - Habilitar cosas que antes eran imposibles - Crear nuevas categorías de valor - Resolver los problemas de formas fundamentalmente nuevas Pero son difíciles. Las tuberías RAG son fáciles (bueno, más fáciles). Así que eso es lo que todo el mundo construye. ## El Complejo Industrial de Consultoría Un importante motor de proyectos tontos de IA es el ecosistema de consultoría: ```mermaid flowchart TD A[Big Consultancy Tells C-Suite: You Need AI!] --> B[C-Suite Panics] B --> C[Consultancy Deploys Army of Juniors] C --> D[Recommendations: RAG + Fine-Tuning] D --> E[Build Same Thing as Last 20 Clients] E --> F[Demo Goes Well] F --> G[Reality: Real Data Breaks Everything] G --> H[Consultancy Moves On] H --> I[Internal Team Struggles] I --> J[Project Quietly Fails] J --> K[Nobody Admits It] K --> A style G stroke:#ff0000,stroke-width:3px style J stroke:#ff0000,stroke-width:3px ``` He visto este patrón docenas de veces, la consultoría es pagada, los ejecutivos dicen que "hicieron IA". Los ingenieros se quedan atascados manteniendo algo que apenas funciona, y el problema real del negocio sigue sin resolverse. ## El requisito de la IA conducida por VC Startups cae en una trampa ligeramente diferente. No son las consultorías las que impulsan la disfunción, es el entorno de financiación. ```mermaid timeline title Technology Requirements for VC Funding 2005 : Web 2.0 - "You need social features" 2010 : Mobile - "You need an app" 2015 : Cloud - "You need to be cloud-native" 2018 : Blockchain - "You need a token" 2023 : AI - "You need an AI strategy" ``` ¿Te suena familiar? Cada pocos años, hay una nueva tecnología que los VCs deciden que es esencial. Si tu baraja de lanzamiento no lo menciona de manera prominente, no estás recibiendo fondos. La tecnología puede ser irrelevante para tu producto real, no importa. Necesitas la palabra de moda. Vi esto pasar con blockchain en 2017-2018. Las empresas que no tenían negocio en un blockchain eran fichas de hornear zapatos en sus productos porque eso es lo que consiguió financiación. La mayoría de esas características blockchain desaparecieron silenciosamente una vez que el dinero fue asegurado. **Ahora está pasando con AI.** Startups están atornillando características LLM en productos que no los necesitan porque: - Los inversores no mirarán las barajas sin la "AI" mencionada - Las valoraciones son 3-5x más altas para las "empresas AI" - La prensa solo cubre historias de IA - "AI-powered" es la apuesta de mesa para la comercialización ¿El resultado? Productos con características de IA incómodas que los usuarios ignoran. Pista quemada en experimentos de ajuste fino que no van a ninguna parte. Ingeniería tiempo perdido en los sistemas RAG cuando una simple consulta de base de datos funcionaría mejor. **La peor parte:** Muchos fundadores saben que esto es tonto. Están construyendo características de IA en las que no creen porque necesitan sobrevivir el tiempo suficiente para construir lo que realmente les importa. Algunos tienen éxito en este juego. La mayoría no. Si eres un fundador de startup siendo empujado a agregar IA, pregúntate: - ¿La IA realmente mejora la propuesta de valor principal de mi producto? - ¿O solo estoy marcando una caja para inversores? Si es el último, construir la función de IA viable mínimo que marca la casilla, a continuación, centrarse en lo que realmente importa. No permita que el entorno de financiación distraiga de la construcción de algo valioso. ## El complejo industrial Hype Esta es la verdad incómoda que nadie en AI quiere discutir: **casi todo el mundo en el ecosistema tiene un incentivo financiero para mantener el bombo.** ```mermaid flowchart TD subgraph Researchers["🔬 Frontier Labs"] R1[Need billions for compute] R2[Must show progress to justify spend] R3[Hype generates investment] end subgraph Companies["🏢 Tech Companies"] C1[Need AI angle for valuation] C2[Must justify AI team costs] C3[Hype drives stock price] end subgraph Investors["💰 Financial Backers"] I1[Massive capital deployed] I2[Need exits and returns] I3[Hype maintains valuations] end subgraph Media["📰 Tech Media"] M1[AI stories get clicks] M2[Access depends on positive coverage] M3[Hype drives engagement] end R3 --> I1 C3 --> I1 I3 --> R1 I3 --> C1 M3 --> R3 M3 --> C3 ``` **Los investigadores** En laboratorios fronterizos necesitan miles de millones en computación para entrenar a la próxima generación de modelos. Ese dinero proviene de los inversores y la gran tecnología. Para justificar ese gasto, necesitan demostrar progreso — y el "progreso" se traduce en anuncios sin aliento sobre capacidades que pueden o no materializarse en aplicaciones prácticas. Si el bombo muere, el financiamiento se seca. **Las empresas** La valoración de OpenAI depende de la creencia de que AGI está a la vuelta de la esquina. Cada startup "con IA" depende de que IA siga siendo el sector caliente. El momento en que el sentimiento cambia, miles de millones en riqueza de papel se evapora. **Los inversores** han desplegado cantidades asombrosas de capital en IA. Necesitan salidas. Necesitan la música para seguir tocando el tiempo suficiente para realizar retornos. Una evaluación realista de las capacidades de IA a corto plazo evaluaría cráteres en todo el sector. **Medios de comunicación** El acceso a las compañías de IA a menudo depende de mantener relaciones positivas, lo que significa que la cobertura crítica es limitante en la carrera. ¿El resultado? Un ciclo de bombo auto-reforzado donde todo el mundo tiene razones para seguir inflando expectativas, y muy pocas personas se benefician de decir la verdad. Esto no significa que la IA no sea realmente útil, absolutamente lo es, como he discutido a lo largo de este artículo. Pero la brecha entre lo que se está prometiendo y lo que se está entregando es enorme, y los incentivos están alineados para mantener esa brecha oculta. Cuando alguien te dice que la IA revolucionará tu negocio, pregúntate: ¿qué gana si crees eso? ## ¿ Qué debería hacer usted realmente? Si estás considerando un proyecto de IA, este es mi honesto consejo: ### 1. Comience con el problema, no con la tecnología No preguntes "¿cómo podemos usar la IA?" Pregunta "¿Qué problema estamos tratando de resolver?" Si la IA es la solución correcta, genial. Pero a menudo no lo es. ### 2. Fije sus datos primero Antes de construir una tubería RAG, arregle el desorden de documentos. Antes de ajustar, limpie sus datos de entrenamiento. La IA no solucionará sus problemas de datos; los amplificará. ### 3. Comenzar pequeño e iterado No lances una masiva "transformación de AI". Construye una pequeña prueba de concepto. Pruébala con usuarios reales. Aprende lo que realmente funciona. Luego expandete. ### 4. Invertir en los bits aburridos La tubería de ingestión de documentos no es sexy, la limpieza de datos no es emocionante, el marco de evaluación no es algo que se pueda demo al tablero, pero esto es lo que determina el éxito o el fracaso. ### 5. Sea honesto acerca de las limitaciones La IA no es mágica. Los LLM actuales alucinan. Los sistemas RAG no tienen documentos relevantes. Modelos afinados de deriva. Establece expectativas realistas. ### 6. Plan de conservación Construir el sistema es tal vez el 30% del esfuerzo. Mantenerlo, mejorarlo, y mantenerlo relevante es el otro 70%. Presupuesto en consecuencia. ### 7. Considere si usted necesita una solución personalizada en absoluto Tal vez lo que usted necesita es un mejor uso de herramientas fuera de la estantería. ChatGPT con algunas instrucciones personalizadas puede ser suficiente. No todo necesita una plataforma de IA a medida. ## Pero no tienen que ser tontos Bien, he pasado unas pocas palabras desaprovechando los proyectos comerciales de IA. **Estos proyectos pueden realmente funcionar, si te acercas a ellos con sensatez.** El problema no es RAG o afinar como conceptos. El problema es la implementación perezosa, expectativas poco realistas, e ignorar los fundamentos. He aquí cómo hacerlo mejor. ### Enganche IA a flujos de trabajo existentes, no los reemplace El mayor error que veo es tratar la IA como un reemplazo de los procesos existentes en lugar de una mejora. Su negocio ya tiene flujos de trabajo que funcionan (en su mayoría). En lugar de arrancarlos y reemplazarlos con una versión "alimentada con AI", enganchar la IA en los huecos. ```mermaid flowchart TD subgraph Traditional["Traditional Workflow"] A[Document Arrives] --> B[Human Reviews] B --> C[Decision Made] C --> D[Action Taken] D --> E[Results Logged] end subgraph Enhanced["AI-Enhanced Workflow"] A2[Document Arrives] --> AI1[AI: Extract Key Info] AI1 --> B2[Human Reviews - With AI Summary] B2 --> AI2[AI: Suggest Decision Based on History] AI2 --> C2[Human Makes Final Decision] C2 --> D2[Action Taken] D2 --> AI3[AI: Auto-categorise & Log] AI3 --> E2[Results Available for Future AI Training] end ``` Note lo que es diferente: - **Los humanos todavía están en el bucle** para las decisiones que importan - **IA maneja las partes tediosas** - extracción, resumen, categorización - **Cada paso de IA es pequeño y verificable** - si la IA se extrae mal, el humano lo captura durante la revisión - **Existen bucles de retroalimentación** - los resultados registrados entrenan futuras mejoras de IA Esto es mucho más robusto que "AI maneja todo y a veces un chequeo humano". ### Usar LLM locales para coste y confidencialidad Este es un sucio secreto: probablemente no necesitas GPT-4 o Claude para la mayoría de las tareas. Y definitivamente no necesitas enviar tus documentos confidenciales a los servidores de OpenAI. **El problema de los costos** A escala, los costos de API se suman rápidamente. Un sistema RAG ocupado puede hacer miles de llamadas LLM por día. A $0.01-0.03 por tokens de 1K, que es dinero real. Y a medida que escala, se pone peor. **El problema de la confidencialidad** Muchas organizaciones no pueden (o no deberían) enviar sus documentos a APIs externas: - Documentos jurídicos con información del cliente - Registros médicos - Datos financieros - Investigación propia - Cualquier cosa cubierta por el RGPD, HIPAA, etc. **La solución: modelos locales** Los modelos modernos de código abierto son jodidamente buenos. - **Cero costo marginal por consulta** - que has pagado por el hardware, inferencia es "libre" - **Completar la privacidad de los datos** - nada sale de su infraestructura - **Sin límites de tipos** - escalar tanto como su hardware lo permita - **Opciones de personalización** - Afinar sin que los datos salgan de su control ```mermaid flowchart LR subgraph Cloud["Cloud API Approach"] A1[Your Documents] --> B1[Internet] B1 --> C1[OpenAI/Anthropic] C1 --> D1[£££/month] C1 --> E1[Privacy Concerns] end subgraph Local["Local LLM Approach"] A2[Your Documents] --> B2[Your Server] B2 --> C2[Local LLM] C2 --> D2[Fixed Hardware Cost] C2 --> E2[Data Never Leaves] end ``` #### Opciones prácticas de modelos locales Por **incrustación** (el bit de búsqueda vectorial RAG): - **transformadores de frases** - Rápido, exacto, funciona con hardware modesto - **empotrado en el sistema nómico** - Gran calidad, pequeña huella - **Modelos BGE** - Competitivo con opciones comerciales Por **generación** (las respuestas "AI" reales): - **Llama 3.1 8B/70B** - Excelente propósito general, gran instrucción siguiendo - **Mistral/Mixtral** - Razonamiento rápido, eficiente y bueno - **Phi-3** - Sorprendentemente capaz por su tamaño - **Qwen 2.5** - Fuerte apoyo multilingüe Por **tareas de codificación**: - **CodeLlama** - Capacitación específica para el código - **Codificador de DeepSeek** - Excelente comprensión del código - **StarCoder** - Bueno para muchos idiomas Correr estos localmente no es tan difícil como se podría pensar. **Ollama**, **llama.cpp**, **vLLM**, o **inferencia de generación de texto** He construido una serie de aplicaciones (ver la parte inferior del artículo) que demuestran que esto se ejecuta en el hardware del consumidor. #### El enfoque híbrido Una arquitectura sensata usa: 1. **Modelos locales para tareas de gran volumen y menor complejidad** - Clasificación de los documentos - Extracción de entidades - Preguntas y respuestas sencillas - Resumen 2. **API en la nube para un razonamiento complejo cuando sea necesario** - Análisis complejo en varias etapas - Tareas que requieren las ventanas de contexto más grandes - Retroceso cuando la confianza del modelo local es baja Este enfoque híbrido le da los beneficios de costo de inferencia local con la capacidad de los modelos de nube cuando realmente lo necesita. ### Construir valor incremental, no grandes transformaciones ```mermaid flowchart LR subgraph Waterfall["❌ The Waterfall AI Project"] W1[Month 1-3: Requirements] --> W2[Month 4-6: Build Platform] W2 --> W3[Month 7-9: Integration] W3 --> W4[Month 10: Demo - Looks Great!] W4 --> W5[Month 11: Real Users Break It] W5 --> W6[Month 12: Project Shelved] end subgraph Incremental["✅ The Incremental Approach"] I1[Week 1-2: One Small Problem] --> I2[Week 3-4: Refine + Measure] I2 --> I3[Week 5-6: Add Capability] I3 --> I4[Week 7-8: Refine + Measure] I4 --> I5[Repeat...] I5 --> I6[Continuous Value Delivery] end style W5 stroke:#ff0000,stroke-width:3px style W6 stroke:#ff0000,stroke-width:3px style I6 stroke:#00aa00,stroke-width:3px ``` Cada paso en el enfoque incremental proporciona valor medible. Cada paso le enseña algo. Si algo falla, usted ha perdido semanas, no meses. ### Hacer de la ingestión de documentos una preocupación de primera clase ¿Recuerdas esa caja roja en el diagrama? **Invertir en calidad sobre cantidad.** Es mejor tener 1.000 documentos perfectamente procesados que 100.000 documentos mal procesados. Comience con sus documentos más importantes y hágalos bien. **Utilice la IA para ayudar con la ingestión.** Los modelos modernos de lenguaje de visión (GPT-4V, Claude, LLaVA localmente) pueden leer documentos complejos - tablas, gráficos, notas manuscritas - de maneras que el OCR tradicional no puede. **Construye bucles de retroalimentación.** Cuando la recuperación falla, log it. Cuando los usuarios dicen "eso no es lo que dice el documento," capturarlo. Utilice esta retroalimentación para mejorar su tubería de ingestión. **Acepta que algunos documentos no funcionarán.** No todos los PDF antiguos escaneados vale la pena luchar con. A veces la respuesta es "vamos a manejar ese tipo manualmente" en lugar de pasar meses en casos extremos. ### Piensa en el sistema completo, no sólo en la IA Bit Una solución de IA de trabajo necesita: Componente Lo que la mayoría de los proyectos hacen Lo que realmente funciona |-----------|----------------------|---------------------| Ingestión de datos Pensamientos posteriores Enfoque primario Calidad de los datos "AI lo resolverá" Tubería de limpieza dedicada # Búsqueda básica de vectores # # búsqueda híbrida # # # reordenando # # # búsqueda básica de vectores # # búsqueda híbrida # Generación Salida LLM en bruto Salida estructurada con validación Revisión humana Opcional Integrado en el flujo de trabajo # Realimentación # # Ninguno # # bucle de mejora continua # Monitoreo "Está funcionando" métricas detalladas y alertas Mantenimiento "Versión 1 para siempre" Actualizaciones regulares y readiestramiento El modelo de IA es tal vez 20% de un sistema de trabajo. El otro 80% es la materia aburrida que realmente hace que funcione en la producción. ### Construir en la Observabilidad desde el primer día No se puede mejorar lo que no se puede medir. - **Calidad de obtención**: ¿Está encontrando documentos relevantes? - **Calidad de la generación**: ¿Son exactas las respuestas? Seguimiento de las tasas de alucinaciones (sí, esto es difícil). - **Satisfacción del usuario**: ¿La gente realmente lo encuentra útil? Seguimiento de uso, tasas de finalización, pulgares hacia arriba / hacia abajo. - **Costo por consulta**: ¿Qué está gastando realmente? Seguimiento de uso de token, latencia, costos de infraestructura. - **Modos de fallo**: ¿Cuándo se rompe? Ratios de error de seguimiento por tipo de documento, tipo de consulta, etc. Este dato le indica dónde invertir esfuerzo. Tal vez su recuperación es genial, pero la generación es alucinante. Tal vez ciertos tipos de documentos siempre fallan. No se puede arreglar lo que no se puede ver. ### El fin de "Big LLM lo resuelve todo" Este es el cambio más importante que está sucediendo ahora: **la era de "tirar todo en GPT-4 y esperar lo mejor" está terminando.** El enfoque 2023-2024 era simple: conseguir el modelo más grande que puedas permitirte, llenar tu ventana de contexto de todo, y rezar. Funcionó... más o menos. Para demos. Para prototipos. Para conseguir inversión. Pero no escala, es caro, es lento, y cada vez más, está siendo superado por arquitecturas más inteligentes. #### El cambio a pequeños modelos orquestados El futuro no es un modelo gigante haciendo todo. **múltiples modelos especializados trabajando juntos**, cada uno haciendo lo que es bueno en. ```mermaid flowchart TD subgraph OldWay["The 2023 Approach"] A1[Everything] --> B1[GPT-4] B1 --> C1[Hope It Works] B1 --> D1[£££££] end subgraph NewWay["The 2025+ Approach"] A2[Input] --> B2[Router Model - Small/Fast] B2 --> C2[Specialist Model A - Extraction] B2 --> D2[Specialist Model B - Reasoning] B2 --> E2[Specialist Model C - Generation] C2 --> F2[Orchestrator] D2 --> F2 E2 --> F2 F2 --> G2[Output] end ``` Esto es lo que he estado explorando en mi [DiSE (Evolución sintética directa)](/blog/disejustvoyager) trabajo—la idea de que **estructura supera la brillantez**. Una tubería cuidadosamente orquestada de modelos más pequeños y enfocados supera a un único modelo masivo tratando de hacer todo. El mismo pensamiento se aplica a la [Motor de decisión sintético](/blog/semantidintelligence) concepto: utilizando múltiples backends LLM en secuencia, donde cada modelo aporta diferentes fortalezas. Modelos rápidos para triaje, modelos precisos para validación, modelos creativos para generación. Cada uno haciendo lo que hace mejor. #### ¿Por qué esto importa para RAG? Si no lo has hecho ya, mira mi [Serie RAG](/blog/rag-primer) Pero aquí está la idea clave: **El propio GCR es una forma de este enfoque orquestado**. Usted está usando embeddings (un modelo) para encontrar contenido relevante, luego usando un LLM (otro modelo) para sintetizar una respuesta. La siguiente evolución está llevando esto más lejos: - **Modelo de empotrado** → encuentra documentos candidatos - **Recalificación del modelo** → pedidos por relevancia real - **Modelo de clasificación** → determina la intención de consulta - **Modelo de generación pequeña** → maneja simples consultas factuales - **Modelo de razonamiento grande** → maneja análisis complejos (sólo cuando sea necesario) Cada modelo es más pequeño, más rápido y más barato que el uso de GPT-4 para todo. Pero juntos, superan el enfoque monolítico. #### El futuro agente El término "agente" se toma prestado de la psicología — mi campo original antes de caer en el software. En psicología, la agencia se refiere a la capacidad de actuar independientemente, de tomar decisiones y ejecutarlas en el mundo. Una persona agente no sólo responde a los estímulos; inician la acción, persiguen metas y adaptan su comportamiento en base a los resultados. **AI agente** aplica este concepto a los modelos de lenguaje. En lugar del patrón tradicional —se hace una pregunta, el modelo genera texto— un sistema agente puede realmente *Hacer cosas*Puede usar herramientas, ejecutar código, consultar bases de datos, llamar a APIs, escribir archivos y orquestar flujos de trabajo de varios pasos. Es la diferencia entre pedir instrucciones a alguien y contratar a alguien para que te lleve allí. Esto es lo que los últimos modelos de Anthropic (incluyendo [Claude Opus 4.5](https://www.anthropic.com/news/claude-opus-4-5) que literalmente estoy usando para escribir esto a través de Claude Code) demostrar tan eficazmente. Esto es lo que hace que la multitud afinada se sienta incómoda: **Si describes las herramientas lo suficientemente bien, no necesitas una afinación costosa para usarlas.** Los modelos de base modernos son notablemente buenos en el uso de herramientas fuera de la caja: solo necesita esquemas de funciones claros y una buena documentación en el contexto. Se trata de un cambio masivo desde el enfoque Toolformer (finalizar un modelo para aprender a usar herramientas mediante la medición de resultados). Eso es caro, requiere datos de entrenamiento especializados, y le fija en un conjunto específico de herramientas. ¿La alternativa? Describa sus herramientas claramente, dé al modelo un buen contexto, y deje que se de cuenta cuándo usarlas. Los resultados suelen ser mejores porque: - **Las descripciones de las herramientas se pueden actualizar al instante** - no se necesita readiestramiento - **Se pueden añadir nuevas herramientas en tiempo de ejecución** - Sólo tienes que añadir otro esquema - **El modelo se beneficia de su razonamiento general** - no sólo patrones memorizados - **Puede utilizar cualquier modelo capaz** - no uno específicamente afinado ```mermaid flowchart TD subgraph RAG["Traditional RAG Chatbot"] R1[User Question] --> R2[Search Documents] R2 --> R3[Construct Prompt] R3 --> R4[LLM Generates Answer] R4 --> R5[Return to User] end subgraph Agentic["Agentic AI Pattern"] A1[User Task] --> A2[LLM Understands Task] A2 --> A3[Break Into Steps] A3 --> A4{Select Tool} A4 --> A5[Execute Tool] A5 --> A6{Evaluate Results} A6 -->|Need More| A4 A6 -->|Done| A7[Return to User] end style A6 stroke:#00aa00,stroke-width:3px ``` Este patrón agente es fundamentalmente diferente de los chatbots de RAG. Y es donde se encuentra el valor real. **Marcos como LangChain, LlamaIndex y Kernel Semántico hacen esto posible hoy en día.** Puede construir sistemas donde: - Un pequeño modelo rápido maneja el encaminamiento y la clasificación - Los modelos especializados manejan tareas específicas del dominio - El uso de la herramienta extiende las capacidades más allá del lenguaje puro - Los bucles de retroalimentación permiten una mejora continua Las empresas que se den cuenta de esto construirán sistemas de IA que realmente funcionan. Los que todavía intentan afinar su camino hacia el éxito o construir otro chatbot de RAG seguirán decepcionados. #### Dónde aprender más He escrito extensamente sobre estos patrones: Artículo Lo que aprenderás |-------|--------------------------------------------------------------------------|-----------------------------------------------------------------| | **Arquitectura** | [DiSE vs Voyager](/blog/disejustvoyager) ¿Por qué la orquestación estructurada supera a los modelos monolíticos? | **Multimodelo** | [Motores de decisión sintéticos](/blog/semantidintelligence) Construcción de tuberías de modelos especializados | **Fundamentos de los GCR** | [Serie RAG](/blog/rag-primer) De las incrustaciones a los sistemas de producción | **Acoplamientos locales** | [Búsqueda semántica con ONNX](/blog/semantic-search-with-onnx-and-qdrant) Búsqueda de vectores locales amigables con CPU | **LLM locales** | [DiSE](/blog/semanticintelligence-part10) Un sistema de flujo de trabajo selkf evolvign usando modelos locales conectados entre sí | **Simulación API** | [LLMApi](/blog/llmapi) Usando LLM locales para simular APIs para probar | **Práctico RAG** | [Construyendo un Abogado GPT](/blog/building-a-lawyer-gpt-for-your-blog-part1) Completar el paso de implementación de RAG La tecnología existe. Los patrones están emergiendo. La pregunta es si su organización construirá algo sensato u otro estúpido proyecto de IA. ## Conclusión El panorama comercial actual de la IA me recuerda la era temprana de la web. Todo el mundo necesitaba una "estrategia web". Las empresas construyeron sitios web porque tenían que hacerlo, no porque supieran qué hacer con ellos. La mayoría de esos sitios web eran inútiles. Eventualmente, las empresas que tuvieron éxito fueron las que descubrieron lo que la web era realmente bueno para y construido para eso. Lo mismo sucederá con IA. En este momento, estamos en la fase de "construirlo porque tenemos que" la mayoría de los proyectos son tontos, la mayoría fracasarán o no se entregarán, eso es normal para la nueva tecnología. Pero si quieres ser uno de los que tiene éxito, deja de seguir la plantilla. Empieza con problemas reales. Invierte en los bits aburridos. Y por el amor de Dios, arregla tu tubería de ingestión de documentos antes de culpar al LLM. La IA no es el problema, tus datos lo son, tus procesos lo son, tus expectativas no realistas lo son. Arregla esos primero, y tal vez, sólo tal vez, su proyecto de IA no será tonto.