Diseñamos el sistema alrededor del modelo.
Los proyectos de IA rara vez fallan en el prompt. Fallan en la recuperación, en la calidad de los datos, en la evaluación, en la latencia y el coste, y en lo que ocurre cuando el modelo se equivoca con total seguridad. Eso es arquitectura de sistemas, y es lo que George lleva haciendo veinte años.
La verdad poco glamurosa sobre los productos de IA
Un modelo de lenguaje es una dependencia que se invoca a través de la red. No es determinista, se factura por token, es más lento que su base de datos y, de vez en cuando, devolverá algo plausible y erróneo.
Todo lo que decide si su funcionalidad de IA funciona en producción es arquitectura de software corriente y difícil: qué contexto se recupera y cómo, cómo se mide si una respuesta fue buena, qué se cachea, qué se hace cuando el proveedor está caído y cómo se evita que el coste crezca con su éxito. Ese es el trabajo, y eso es lo que hacemos.
De «¿deberíamos usar IA?» a un sistema en producción
Los encargos suelen empezar por lo alto de esta lista y avanzar hacia abajo. Es libre de detenerse tras el primero.
Evaluación de oportunidades de IA
Un trabajo breve y remunerado que examina su producto y sus datos, y luego le indica dónde la IA aporta valor, dónde solo genera coste y qué haría falta para construirla. Recibe un plan por escrito. A veces la respuesta honesta es «todavía no», y así lo diremos.
- Lista corta de casos de uso, ordenada por valor y riesgo
- Revisión de la preparación de los datos
- Recomendación de construir, comprar o esperar
Diseño de sistemas de IA
La arquitectura alrededor del modelo: cómo le llega el contexto, cómo se sabe que la salida es buena, cuánto cuesta por petición, con qué rapidez responde y cómo el producto se degrada de forma controlada cuando el modelo o el proveedor fallan.
- Diseño de recuperación y pipelines de datos
- Arneses de evaluación y barreras de calidad
- Presupuestos de coste y latencia
- Alternativas de respaldo, caching y degradación controlada
Funciones con LLM en productos existentes
La mayor parte de este trabajo ocurre dentro de aplicaciones que ya tienen usuarios e ingresos. Añadimos la funcionalidad sin desestabilizar lo que ya genera dinero, una restricción que las demos de IA de partida en blanco nunca tienen que respetar.
- Generación aumentada por recuperación (RAG) sobre su propio contenido
- Extracción estructurada y clasificación
- Agents y uso de herramientas, acotados para que no puedan causar daño
- Asistentes y búsqueda semántica
Automatización de procesos y flujos de trabajo
La categoría menos de moda y más rentable: el trabajo manual, repetitivo y con poco margen de criterio dentro de su negocio que un modelo bien acotado puede absorber, con una persona conservando aún las decisiones que importan.
- Procesamiento de documentos y correo electrónico
- Flujos de trabajo de back-office y soporte
- Pasos de revisión con intervención humana
Selección de modelo y proveedor
Los modelos cambian cada pocos meses; la arquitectura que los rodea no debería tener que hacerlo. Mantenemos al proveedor detrás de una interfaz, elegimos el modelo más barato que supere su listón de calidad en lugar del más grande disponible, y hacemos que cambiarlo sea una cuestión de configuración en lugar de una reescritura.
Un arquitecto, no un ingeniero de prompts
Escribir prompts es una habilidad que se aprende en quince días. Saber qué parte de un sistema se vendrá abajo bajo carga lleva bastante más tiempo.
Veinte años de sistemas en producción
APIs de alto tráfico, modelos de datos que sobrevivieron a un crecimiento real y plataformas entregadas sin tiempo de inactividad. Las funciones de IA viven dentro de sistemas como estos, o nunca salen de la demo.
Trata con el ingeniero, no con un gestor de cuentas
La persona que delimita su proyecto es la persona que lo diseña y escribe el código. Nada se pierde en el traspaso, porque no hay traspaso.
Dicho con claridad, incluidas las malas noticias
Si la IA es la herramienta equivocada para su problema, ese es el consejo que recibirá en la primera semana, antes de gastar el presupuesto. Es una conversación más barata que la alternativa.
¿Tiene un problema de IA que merezca la pena resolver?
Cuéntenos qué está intentando construir. Si encaja bien, se lo diremos, y si no encaja, también se lo diremos.