A veces, su “experimento” falla, luego gira ligeramente su trabajo y este otro experimento tuvo un éxito mucho mejor.
Precisamente por eso, antes Al diseñar nuestra solución final, debemos comenzar de manera simple y cubrir nuestros riesgos.
- Defina un “presupuesto” o plazo. Veamos qué podemos hacer en X semanas y luego decidamos cómo continuar o si. Por lo general, serán suficientes de 2 a 4 semanas para comprender la PoC básica. Si parece prometedor, continúe invirtiendo recursos para mejorarlo.
- Experimento-Ya sea que elija un enfoque ascendente o descendente para su fase de experimentación, su objetivo es maximizar la tasa de sucesión de resultados. Al final de la primera iteración de experimentación, debería tener alguna prueba de concepto (con la que las partes interesadas puedan jugar) y una línea de base que haya logrado.
- Retrospectiva— Al final de nuestra fase de investigación, podremos comprender la viabilidad, las limitaciones y el costo de crear una aplicación de este tipo. Esto nos ayuda a decidir si producirlo y cómo diseñar el producto final y su UX.
- Productización — Desarrolle una versión lista para producción de su proyecto e intégrela con el resto de su solución siguiendo las mejores prácticas estándar de SWE e implementando un mecanismo de recopilación de datos y comentarios.
Para implementar bien el proceso orientado a experimentos, debemos tomar una decisión informada sobre cómo abordar y construir estos experimentos:
Comenzando con Lean: el enfoque ascendente
Si bien muchos de los primeros usuarios rápidamente se lanzan a” Lo último” sistemas agentic multicadena con Langchain completo o algo similar, encontré “El enfoque ascendente” a menudo produce mejores resultados.
Empiece magro, muy delgadoabrazando el “un mensaje para gobernarlos a todos” filosofía. Aunque esta estrategia puede parecer poco convencional y probablemente produzca malos resultados al principio, establece un base para su sistema.
A partir de ahí, repita y perfeccione continuamente sus indicaciones, empleando técnicas de ingeniería de indicaciones para optimizar los resultados. A medida que identifique debilidades en su solución lean, divida el proceso agregando ramas para abordar esas deficiencias.
Mientras diseño cada “hoja” de mi gráfico de flujo de trabajo LLM, o arquitectura nativa de LLM, sigo El Triángulo Mágico³ para determinar dónde y cuándo cortar las ramas, partirlas o engrosar las raíces (mediante técnicas de ingeniería rápidas) y exprimir más limón.
Por ejemplo, para implementar “consultas SQL en lenguaje nativo” con el enfoque ascendente, comenzaremos enviando ingenuamente los esquemas al LLM y le pediremos que genere una consulta.
Por lo general, esto no contradice el “enfoque de arriba hacia abajo”, sino que sirve como un paso más antes de él. Esto nos permite mostrar ganancias rápidas y atraer más inversiones en proyectos.
El panorama general inicial: la estrategia de arriba hacia abajo
“Sabemos que el flujo de trabajo de LLM no es fácil y, para lograr nuestro objetivo, probablemente terminemos con algún flujo de trabajo o arquitectura nativa de LLM”.
El enfoque Top-Down lo reconoce y comienza diseñando la arquitectura nativa del LLM desde el primer día e implementando sus diferentes pasos/cadenas desde el principio.
De esta manera, puedes probar la arquitectura de tu flujo de trabajo en su conjunto y exprimir todo el limón en lugar de refinar cada hoja por separado.
Por ejemplo, para implementar “consultas SQL en lenguaje nativo” con el enfoque de arriba hacia abajo, comenzaremos a diseñar la arquitectura incluso antes de comenzar a codificar y luego pasaremos a la implementación completa:
Encontrar el equilibrio adecuado
Cuando comiences a experimentar con LLM, probablemente comenzarás en uno de los extremos (de arriba hacia abajo demasiado complicado o de una sola vez súper simple). En realidad, no existe tal ganador.
Idealmente, definirá un buen SoP¹ y modelará a un experto antes de codificar y experimentar con el modelo. En realidad, modelar es muy difícil; A veces, es posible que no tenga acceso a dicho experto.
Me resultó difícil conseguir una buena arquitectura/SoP¹ en el primer disparo, por lo que vale la pena experimentar un poco antes de saltar a los peces gordos. Sin embargo, eso no significa que todo tiene que ser demasiado delgado. Si ya tienes un comprensión previa ese algo DEBE romperse en pedazos más pequeños, hazlo.
En cualquier caso, debes aprovechar el paradigma del Triángulo Mágico³ y modelar el proceso manual correctamente mientras diseñas tu solución.