This is a viewer only at the moment see the article on how this works.
To update the preview hit Ctrl-Alt-R (or ⌘-Alt-R on Mac) or Enter to refresh. The Save icon lets you save the markdown file to disk
This is a preview from the server running through my markdig pipeline
Wednesday, 26 November 2025
"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
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.
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:
Esta es de lejos la más común. Cada "solución de IA empresarial" sigue este patrón:
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.
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.
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.
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:
Esto es lo que realmente sucede:
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:
Y eso son sólo PDFs.
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.
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]
Un buen RAG necesita buenos metadatos, pero extraer metadatos de los documentos es difícil:
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.
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 ajuste requiere datos de formación de calidad. La mayoría de las empresas no los tienen.
"¡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?
¿Cómo sabes si tu modelo afinado es realmente mejor? La mayoría de las empresas no pueden responder esto porque:
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.
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:
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.
No me malinterpretes, hay casos de uso legítimo.
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.
Mientras que todos están construyendo el mismo gasoducto RAG, los problemas realmente interesantes en IA comercial están siendo ignorados:
La mayor limitación en la efectividad de la IA no es el modelo. Son los datos. La mayoría de las organizaciones tienen:
Pero "la iniciativa de calidad de los datos" no te da un artículo de Forbes como "la transformación de la AI".
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.
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:
La mayoría de los proyectos comerciales de IA tratan al humano como un pensamiento secundario.
Las aplicaciones de IA realmente valiosas no son "chatbot en sus documentos". Son aplicaciones que:
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.
Un importante motor de proyectos tontos de IA es el ecosistema de consultoría:
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.
Startups cae en una trampa ligeramente diferente. No son las consultorías las que impulsan la disfunción, es el entorno de financiación.
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:
¿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:
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.
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.
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?
Si estás considerando un proyecto de IA, este es mi honesto consejo:
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.
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á.
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.
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.
La IA no es mágica. Los LLM actuales alucinan. Los sistemas RAG no tienen documentos relevantes. Modelos afinados de deriva. Establece expectativas realistas.
Construir el sistema es tal vez el 30% del esfuerzo. Mantenerlo, mejorarlo, y mantenerlo relevante es el otro 70%. Presupuesto en consecuencia.
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.
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.
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.
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:
Esto es mucho más robusto que "AI maneja todo y a veces un chequeo humano".
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:
La solución: modelos locales
Los modelos modernos de código abierto son jodidamente buenos.
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
Por incrustación (el bit de búsqueda vectorial RAG):
Por generación (las respuestas "AI" reales):
Por tareas de codificación:
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.
Una arquitectura sensata usa:
Modelos locales para tareas de gran volumen y menor complejidad
API en la nube para un razonamiento complejo cuando sea necesario
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.
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.
¿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.
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
Generación Salida LLM en bruto Salida estructurada con validación Revisión humana Opcional Integrado en el flujo de trabajo
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.
No se puede mejorar lo que no se puede medir.
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.
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 futuro no es un modelo gigante haciendo todo. múltiples modelos especializados trabajando juntos, cada uno haciendo lo que es bueno en.
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) 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 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.
Si no lo has hecho ya, mira mi Serie RAG 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:
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 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 cosasPuede 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 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:
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:
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.
He escrito extensamente sobre estos patrones:
Artículo Lo que aprenderás |-------|--------------------------------------------------------------------------|-----------------------------------------------------------------| | Arquitectura | DiSE vs Voyager ¿Por qué la orquestación estructurada supera a los modelos monolíticos? | Multimodelo | Motores de decisión sintéticos Construcción de tuberías de modelos especializados | Fundamentos de los GCR | Serie RAG De las incrustaciones a los sistemas de producción | Acoplamientos locales | Búsqueda semántica con ONNX Búsqueda de vectores locales amigables con CPU | LLM locales | DiSE Un sistema de flujo de trabajo selkf evolvign usando modelos locales conectados entre sí | Simulación API | LLMApi Usando LLM locales para simular APIs para probar | Práctico RAG | Construyendo un Abogado GPT 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.
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.
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.