Un mapa jerárquico de los conceptos de ingeniería de IA y cuándo son importantes
Aprenda qué conceptos de ingeniería de IA determinan si un sistema funciona en absoluto, cuáles son importantes una vez que se desarrolla para producción y cuáles pueden esperar.
Una lista de sustantivos trata a los veinte elementos como equivalentes, cuando claramente no lo son. Seis de ellos determinan si su sistema funciona en primer lugar. Otros siete se vuelven relevantes una vez que comienza a desarrollar algo para producción. Los últimos siete son cosas que debería poder reconocer en una conversación, pero cuyo estudio profundo puede posponerse sin problemas durante un año; y, por desgracia, suelen ser esos los que la gente estudia en su tiempo libre.
Lo que sigue aborda el mismo tema, pero añade tres aspectos a cada concepto: qué le ofrece realmente, en qué momento comienza a ser importante y una forma de verificar si realmente lo comprende en lugar de solo reconocer el término.
Las verificaciones son la parte a la que merece la pena prestar atención. La mayoría de las personas se dan cuenta de que han estado asintiendo ante un tema durante meses solo cuando intentan explicarlo en voz alta por primera vez.
Nivel 1: Los seis elementos que determinan si su sistema funciona
1. Incrustaciones y búsqueda vectorial
Qué le ofrece: Casi todo lo relacionado con la recuperación de información depende de este concepto, y un error al aplicarlo provoca fallos que no generan ningún mensaje de error.
La verificación: Dos modelos de incrustación generan vectores de 1024 dimensiones cada uno. Explique por qué un clasificador entrenado con los resultados de uno seguirá produciendo resultados erróneos al recibir vectores del otro.
Si pensar que las dimensiones coincidentes son una señal de compatibilidad es precisamente el malentendido. Un modelo de incrustación define su propia geometría. Dos modelos diferentes colocarán una misma oración en ubicaciones completamente distintas dentro de espacios que solo coinciden por tener la misma forma. Nada en su arquitectura le advertirá al respecto.
2. Calidad de la recuperación, que no es lo mismo que RAG
Qué le ofrece: Casi toda la calidad de las respuestas en un sistema basado en recuperación de información — y casi ninguna de esa calidad proviene del propio modelo de lenguaje.
La verificación: Indique los tres puntos en los que un pipeline RAG puede fallar antes incluso de invocar al modelo de lenguaje.
Las respuestas dependen del fragmentado, los embeddings y el ranking. Si divide un documento en la frontera incorrecta, perderá la oración exacta que respondía a la pregunta. Si utiliza un modelo de embeddings entrenado en un dominio inadecuado, su jerga terminará en la zona equivocada del espacio vectorial. Si omite un sistema de reranking, su herramienta de recuperación devolverá resultados temáticamente relacionados pero factualmente irrelevantes. Los equipos que creen tener un problema de alucinaciones suelen tener en realidad un problema de recuperación de información, y a menudo pasan un mes ajustando los prompts antes de comprobarlo.
3. Evaluación
Qué le brinda: La capacidad de determinar si un cambio realmente mejoró algo, lo cual es lo que diferencia la ingeniería de las conjeturas.
La verificación: Describa el conjunto de criterios dorados con los que realiza la evaluación: cuántos ejemplos, de dónde provienen, según qué se califican y quién revisa las puntuaciones.
Si no puede responder con números reales, lo que tiene no es una evaluación, sino intuiciones más una demostración que sucedió a propósito el martes. Un punto de partida razonable está entre doscientos y quinientos pares reales de pregunta y respuesta extraídos del tráfico real de producción, calificados según un número limitado de dimensiones definidas, con una persona que verifica manualmente una parte de los resultados. También es importante saber que si utiliza un modelo como juez, ese juez necesita su propia evaluación: un problema recursivo que resulta incómodo pero inevitable.
4. Salida estructurada y uso de herramientas
Qué te ofrece: La conexión entre un sistema que genera texto y uno que realmente realiza acciones.
La verificación: El modelo devuelve JSON que no pasa la validación según tu esquema. Describe con exactitud qué hace tu sistema a continuación.
Dizer “intentamos de nuevo” es donde la mayoría de las personas se detienen, pero ahí es donde comienzan las verdaderas preguntas. ¿Cuántos intentos de repetición, con qué estrategia de retraso, y ¿el intento de repetición incluye el error de validación para que el modelo tenga la oportunidad de corregir su propio error? ¿Qué ocurre después del fallo final: el usuario ve un mensaje de error o una respuesta de calidad inferior pero utilizable? Una llamada a herramienta es, en esencia, una invocación de función a través de un límite que puede generar errores falsos, por lo que todas las prácticas estándar relacionadas con la validación de entrada no confiable son igualmente aplicables aquí.
5. Control de costos y latencia
Qué le ofrece: La diferencia entre una función que realmente se lanza al mercado y una demostración que es descartada por razones financieras.
La verificación: Indique su costo actual por solicitud y luego mencione cinco formas de reducirlo a la mitad, ordenadas según el impacto que tendría cada una.
Cinco enfoques merecen estar listos para usar. Envíe solicitudes sencillas a un modelo más económico y de menor tamaño en lugar del predeterminado. Almacene en caché las respuestas para solicitudes semánticamente similares a aquellas que ya ha respondido, no solo idénticas. Reduzca o comprima todo lo que incluya en el prompt. Agrupe todo aquello que no requiera una respuesta en tiempo real en lotes y ejecútelo sin conexión. Además, acorte lo que genera el modelo, ya que los tokens que produce suelen costar más que los tokens que usted envía. Según se informa, Stripe pagó más de 7 mil millones de dólares por OpenRouter este mes: una empresa cuyo producto principal automatiza esencialmente los dos primeros de estos métodos, lo que indica que la industria ya no considera el control de costos como un detalle menor.
6. Gestión del contexto
Qué te ofrece: un comportamiento predecible cuando la entrada supera el tamaño de la ventana de contexto, algo que ocurre constantemente en entornos de producción y casi nunca en demostraciones.
La verificación: cuando se llena la ventana de contexto, ¿qué se descarta y quién toma esa decisión?
Una respuesta sólida menciona una política concreta: descartar primero las intervenciones más antiguas, eliminar primero los fragmentos recuperados con menor puntuación, resumir la sección intermedia o rechazar directamente la solicitud. Una respuesta preocupante es que el framework se encarga de ello, ya que eso suele significar que algo importante se descarta en silencio y nadie ha verificado realmente de qué se trata.
Nivel 2: Los siete que aprendes al desarrollar algo real
Estos se vuelven relevantes una vez que el sistema está en funcionamiento y los usuarios reales interactúan con él. No hay problema en estudiarlos antes, pero hacerlo antes de la fase 1 coloca los esfuerzos en el orden incorrecto.
7. Los prompts como artefactos versionados
La habilidad para redactar prompts recibe mucha más atención de la que merece, mientras que la disciplina técnica relacionada con ellos recibe mucho menos. Lo que realmente se necesita es un registro, versiones fijas, comparaciones lado a lado y la posibilidad de revertir cambios, ya que un prompt es, en efecto, código que llega a producción sin pasar nunca por un compilador.
8. Estrategia de fragmentación
Dividir el texto en ventanas de tamaño fijo, dividirlo según límites semánticos y agregar solapamiento entre los fragmentos son diferentes estrategias que implican compromisos entre la recuperación y la precisión. La elección adecuada depende de cómo estén estructurados los documentos subyacentes, no de la opción predeterminada que recomiende un tutorial.
9. Reclasificación
El patrón habitual es obtener primero una lista amplia y económica, y luego aplicar un proceso de puntuación más costoso a dicha lista. Omitir ese segundo paso es probablemente la razón más común por la cual un pipeline de recuperación produce resultados que parecen casi correctos, pero no del todo.
10. Límites y inyección de prompts
Esto exige defensas en capas: filtros económicos en el punto de entrada y verificaciones más costosas cerca del propio modelo. Cualquier texto que provenga de un usuario o de un documento que haya recuperado su sistema debe tratarse como entrada potencialmente hostil, nunca como instrucciones fiables.
11. Observabilidad para sistemas no deterministas
Lo que se necesita aquí son rastros, no solo registros simples. La pregunta realmente importante es qué fragmentos se recuperaron y qué versión de la prompt estaba en uso cuando surgió una respuesta incorrecta específica hace tres días, y solo los detalles a nivel de rastro pueden responder a eso.
12. Elegir entre prompting, recuperación y ajuste fino
Esta decisión tiene mucho más peso que dominar cualquier técnica en particular. La recuperación proporciona conocimientos, el ajuste fino controla el comportamiento y el formato de salida, mientras que las instrucciones abarcan todo lo demás que se puede gestionar sin ninguno de estos elementos. Un error común es recurrir al ajuste fino para resolver lo que en realidad es una deficiencia en la recuperación de información.
13. Bucles de agente y selección de herramientas
Un único agente equipado con un conjunto de herramientas bien seleccionado y un bucle de ejecución limitado puede manejar una proporción sorprendentemente grande de los problemas que las personas intentan resolver recayendo en arquitecturas multiagente.
Nivel 3: Los siete que vale la pena reconocer y posponer
Para este nivel, basta con conocer el vocabulario lo suficientemente bien como para seguir una conversación al respecto. Profundizar puede esperar hasta que un problema concreto lo haga necesario, y para muchos profesionales ese momento nunca llega.
14. Orquestación multiagente
Este es el elemento más sobreexagerado de la lista. Existe una creciente cantidad de escritos que analizan por qué estos sistemas fallan una vez desplegados, y la conclusión recurrente es que la sobrecarga de coordinación y las tasas de error acumulativas tienden a hacer que su rendimiento sea peor que el de un agente único y bien delimitado en la mayoría de los casos de uso. Conozca a qué se refiere el término y recurra a este patrón solo como último recurso.
15. Cuantización y optimización del servicio
Esto es de gran importancia si usted alberga sus propios pesos del modelo, pero apenas tiene relevancia si simplemente llama a una API.
16. Internos de los Transformers
Los mecanismos de atención, las codificaciones posicionales y el resto de la arquitectura aparecen con mucha más frecuencia en las entrevistas que en el trabajo diario. Vale la pena aprenderlos una vez, pero comprenderlos en profundidad cambia sorprendentemente poco la forma en que se construyen los sistemas.
17. Destilación
Esto resulta útil una vez que ya se cuenta con un sistema funcional pero costoso y es necesario reducir gastos, lo cual es un problema que se genera con el tiempo y no algo con lo que se empieza.
18. Caché semántico
Técnica poderosa con efectos negativos reales: un acierto en el caché con una consulta similar devuelve una respuesta incorrecta presentada con total confianza.
19. Gráficos de conocimiento y GraphRAG
Ofrecen beneficios reales cuando los datos subyacentes son verdaderamente relacionales, pero requieren una complejidad adicional considerable para aprovechar dichos beneficios.
20. Ajuste de preferencias y la familia RLHF
Esto es principalmente relevante para los equipos que entrenan modelos, en lugar de aquellos que desarrollan aplicaciones sobre modelos ya existentes.
La parte incómoda
Si observas los tres niveles, notarás algo que no está bien.
La orquestación de múltiples agentes, los mecanismos internos de los modelos transformer y la redacción de prompts son los temas que absorben la mayor parte del esfuerzo de aprendizaje de las personas, y los tres pertenecen al Nivel 2 o al Nivel 3. Mientras tanto, la evaluación, la calidad de la recuperación de información y el control de costos son los factores que realmente determinan si un sistema real funciona, pero reciben solo una fracción de la atención, principalmente porque ninguno de ellos permite crear una demostración atractiva.
Existe una razón clara para esa diferencia, y vale la pena exponerla abiertamente en lugar de usarla como crítica. Los temas de nivel 3 son fáciles de consumir: puedes leer sobre orquestación multiagente durante el desplazamiento al trabajo y sentir que has aprendido algo. Por el contrario, la evaluación te obliga a crear un conjunto de datos ideal, discutir con un compañero sobre qué significa realmente “bueno”, y a veces aceptar que tu sistema nunca fue tan potente como parecía en la demostración. Una de esas actividades resulta cómoda; la otra es la que realmente ayuda.
Cómo aprender realmente estas cosas en lugar de solo acumularlas
La trampa con cualquier lista como esta es tratarla como un plan de estudios que hay que leer completo. Leer solo te lleva hasta el reconocimiento, y ese reconocimiento se derrumba en cuanto alguien hace una pregunta adicional.
Dos hábitos funcionan mucho mejor que leer por sí solo.
Primero, construye un sistema pequeño de punta a punta y luego rompelo intencionadamente. Dirige un pipeline de recuperación hacia documentos que realmente te importen y sabota cada etapa a propósito. Divide el texto de forma deficiente y observa cómo empeora la calidad de las respuestas. Retira el reordenador de resultados y observa los cambios. Introduce un intento de inyección de comando en el sistema y mira qué información se filtra. Un fin de semana dedicado a esto enseña más que un mes de lectura, porque lo que queda son recuerdos de fallos específicos, no definiciones abstractas.
En segundo lugar, pruebe ese vocabulario con preguntas realistas. Las verificaciones descritas en este texto se basan en el tipo de preguntas que realmente surgen en la práctica, y trabajar con ejercicios reales de estilo de diseño de sistemas es la forma más rápida de identificar las lagunas en su comprensión, sobre todo porque las preguntas reales incluyen seguimientos, y son precisamente en esos seguimientos donde el reconocimiento superficial deja de ser suficiente.
Dónde podría estar equivocado
Esta clasificación es un juicio subjetivo influenciado por los sistemas específicos analizados aquí, no el resultado de una encuesta formal; por lo tanto, es más honesto denominarla un orden defendible en lugar de uno definitivo.
Hay dos categorías sobre las cuales vale la pena debatir abiertamente. La orquestación de múltiples agentes se encuentra en el nivel 3, en parte porque las pruebas actuales sobre cómo se comportan estos sistemas en entornos reales no son alentadoras, y un marco realmente sólido que aparezca en el futuro cercano podría elevar fácilmente su posición. Los componentes internos de los modelos Transformer ocupan un lugar bajo aquí, ya que trabajar con modelos de IA es cada vez más una disciplina de integración en lugar de una de modelado, y quienes trabajan directamente con los modelos deberían elevar este tema varios puestos.
La categoría que merece ser defendida con mayor firmeza es la evaluación, en el tercer lugar; sin embargo, hay argumentos sólidos para colocarla en primer lugar. Todos los demás elementos de esta lista se convierten en conjeturas sin ella, ya que no se puede mejorar lo que no se puede medir, y muy pocas equipos que desarrollan sobre la base de modelos hoy en día pueden afirmar con certeza si los cambios realizados la semana pasada mejoraron o empeoraron las cosas.
Si se reorganizara esta clasificación, las discrepancias más interesantes probablemente se encontrarían en la frontera entre el Nivel 1 y el Nivel 2. Una conversación más útil sería identificar qué elemento se movería hacia arriba y qué beneficio conlleva ese cambio, en lugar de crear otra lista de veinte términos.
Lecturas relacionadas
- Gestionar LLM como juez como sistema de producción dinámico — Aprenda cómo el ciclo de vida de cuatro etapas de Netflix —datos reales, entrenamiento ajustado con criterios específicos, implementación segura y monitoreo continuo— mantiene preciso a un LLM en calidad a gran escala.