He visto muchas cosas cuando trabajo con equipos de IA empresarial: casi siempre culpan al modelo cuando algo sale mal. Esto es comprensible, pero frecuentemente también es incorrecto y termina siendo bastante costoso.
El escenario habitual es el siguiente. Los resultados son inconsistentes; Cuando alguien lo plantea, la primera reacción es culpar al modelo. Es posible que requiera más datos de entrenamiento, otra ejecución de ajuste o un modelo base diferente. Después de semanas de trabajo, el problema sigue siendo el mismo o sólo ha cambiado ligeramente. Nunca se examinó el problema real, que a menudo se encuentra en la capa de recuperación, la ventana de contexto o en cómo se enrutaban las tareas.
Lo he visto tantas veces antes que creo que vale la pena escribir sobre ello.
El ajuste fino es útil, pero se usa en exceso
En muchos casos, todavía vale la pena hacer algunos ajustes. Si se requiere adaptación de dominio, alineación de tono o calibración de seguridad, debería ser parte del flujo de trabajo. No estoy diciendo que no debas usarlo.
El problema es que es la respuesta automática a cualquier problema, aunque no sea la herramienta adecuada. En parte porque parece que es algo productivo. Empiezas un trabajo de puesta a punto, algo sucede claramente y hay un antes y un después. Parece que estás abordando el problema cuando no es así.
Un ejemplo de esto es un sistema de análisis de contratos, que estuve observando como un equipo depuraba. Los resultados no eran confiables para documentos complejos y la idea inicial era que el modelo carecía de habilidades de razonamiento legal. Entonces realizaron varias iteraciones de ajuste. El problema no desapareció. Finalmente, alguien notó que la capa de recuperación estaba realizando las mismas recuperaciones varias veces y las agregaba a la ventana contextual. El modelo intentaba trabajar con una gran cantidad de texto de bajo valor que se repetía una y otra vez. Ajustaron la clasificación de recuperación e introdujeron la compresión de contexto y, finalmente, mejoró mucho.
El modelo en sí nunca fue cambiado. Y esto es algo bastante común.
¿Qué está pasando en el momento de la inferencia?
Durante mucho tiempo, la inferencia fue sólo el paso en el que se utilizaba el modelo. En el entrenamiento se tomaron todas las decisiones interesantes. Eso está cambiando ahora.
Una razón para esto es que algunos modelos comenzaron a asignar más computación a la generación en lugar de incorporarla al proceso de capacitación. Otro factor fue que la investigación demostró que comportamientos como la autoevaluación o la reescritura de una respuesta se pueden aprender mediante el aprendizaje por refuerzo. Ambos señalaron la inferencia misma como un lugar donde se podría mejorar el desempeño.
Lo que veo ahora es que los equipos de ingeniería comienzan a tratar la inferencia como algo que realmente se puede diseñar, en lugar de simplemente un paso fijo que se acepta. ¿Cuánta profundidad de razonamiento necesita esta tarea? ¿Cómo se gestiona la memoria? ¿Cómo se prioriza la recuperación? Éstas se están convirtiendo en preguntas reales en lugar de valores predeterminados en los que no se piensa.
El problema de la asignación de recursos
Lo que a menudo se subestima es que la mayoría de los sistemas de inteligencia artificial utilizan un enfoque uniforme para todas sus consultas. Una sola pregunta sobre el estado de la cuenta sigue el mismo proceso que un proceso de cumplimiento de varios pasos, con información que debe conciliarse en varios documentos contradictorios. El mismo costo, el mismo proceso, el mismo cálculo.
Esto no parece tener mucho sentido cuando lo piensas. En todas las demás aplicaciones de ingeniería, los recursos se asignarían en función del trabajo requerido. Algunos equipos están empezando a hacer esto con IA, trasladando inferencias más ligeras a cargas de trabajo más ligeras y dirigiendo computación más pesada a tareas que realmente lo requieren. La economía mejora y la calidad de las cosas más difíciles también mejora, ya que ya no se carece de recursos suficientes.
Estos sistemas tienen más capas de lo que la gente cree
Cuando se mira el interior de un sistema de IA de producción hoy en día, generalmente no es solo un modelo el que responde preguntas. A menudo va acompañado de un paso de recuperación, un paso de clasificación, posiblemente un paso de verificación y un paso de resumen; varios pasos en conjunto para generar el resultado final. No se trata sólo de la capacidad del modelo subyacente, sino también de cómo todas esas piezas encajan para producir el resultado.
Si el clasificador de recuperación no está calibrado adecuadamente, producirá resultados similares a los errores del modelo. Una ventana de contexto que pueda crecer sin restricciones afectará sutilmente la calidad del razonamiento, pero obviamente nada fallará. Se trata de cuestiones de sistemas, no de modelos, y es necesario abordarlas mediante el pensamiento sistémico.
Un ejemplo de este tipo de pensamiento en la práctica es la decodificación especulativa. El concepto es que un modelo más pequeño genera resultados candidatos y un modelo más grande los verifica. Comenzó como una optimización de la latencia, pero en realidad es un ejemplo de cómo distribuir el razonamiento entre múltiples componentes en lugar de esperar que un modelo lo haga todo. Dos equipos que utilizan el mismo modelo base pero diferentes arquitecturas de inferencia pueden terminar con resultados bastante diferentes en producción.
La memoria se está convirtiendo en un problema real
Las ventanas de contexto más grandes han sido útiles, pero pasado cierto punto, más contexto no mejora el razonamiento; lo degrada. La recuperación se vuelve más ruidosa, el modelo realiza un seguimiento menos eficaz y los costos de inferencia aumentan. Los equipos que ejecutan IA a escala dedican tiempo real a cosas como la atención paginada y la compresión de contexto, de las que no es interesante hablar pero que son muy importantes desde el punto de vista operativo.
La idea es tener el contexto adecuado, pero no demasiado, y gestionarlo bien.
Llevar
La selección del modelo importa menos que antes. Varios proveedores ofrecen ahora modelos básicos capaces y las brechas de capacidad se han reducido para la mayoría de los casos de uso. Lo que realmente determina si una implementación tiene éxito es la infraestructura alrededor del modelo, cómo se ajusta la recuperación, cómo se asigna la computación y cómo el sistema maneja los casos extremos a lo largo del tiempo.
Los equipos que estarán en una buena posición dentro de unos años son los que tratan la arquitectura de inferencia como algo que vale la pena diseñar con cuidado, en lugar de asumir que un modelo suficientemente bueno solucionará todo lo demás. En mi experiencia, normalmente no es así.