Operar el sistema sin autoengaños: costo, respaldo y límites reales

Publicar no prueba que el sistema esté sano. Un pipeline puede producir texto todos los días y, aun así, gastar de más, perder respaldo o volverse imposible de revisar. La operación empieza cuando dejas de preguntar si “salió” y empiezas a preguntar cuánto costó cada paso, qué tan defendible fue la salida y si puedes rastrear de dónde salió.

Esa última parte importa porque el objetivo de este enfoque no es que la IA escriba sola. La meta es que la revisión humana baje a cerca del 20% del trabajo, y eso sólo pasa si la salida llega estructurada, citada y con huecos declarados. Si alguien tiene que verificar todo a mano desde cero, el sistema no ahorró nada.[100]

Qué sí conviene medir desde el primer día

El corpus no trae una batería formal de métricas ni un panel completo. Sí trae una base práctica para operar sin inventar precisión falsa.

La primera señal es el gasto por llamada y por etapa. Si usas el SDK de Laravel, puedes escuchar eventos por paso completado de un agente, por invocación completa, por generación de embeddings y por reordenado. En esos eventos vienen consumo de tokens, proveedor, modelo efectivo, número de paso y tiempo de pared; en reordenado hay resultados y metadatos, pero no consumo. Eso permite instrumentar el gasto del sistema entero sin meter contabilidad manual dentro de cada agente.[123]

La segunda señal es el presupuesto de contexto por etapa. En este sistema no se manda “todo lo que quepa”. Se fija un tope por sección: el analista recibe hasta doce fragmentos y el escritor hasta seis. Esos números están en configuración para moverlos midiendo. La regla práctica es simple: cambia números después de observar costo y resultado, no antes.[11]

La tercera señal es la trazabilidad. Cada fragmento entra etiquetado con su identificador para que el escritor cite por número y luego puedas verificar si la cita corresponde. Sin ese respaldo, el texto puede sonar bien y seguir siendo caro de auditar.[11]

La cuarta señal es más humilde, pero sigue siendo útil: acierto percibido. El corpus no documenta una métrica formal de calidad de generación para operar día a día. Lo que sí sostiene es que la revisión humana debe concentrarse en comprobar si la pieza llegó con estructura, citas y huecos declarados, porque ése es el criterio de ahorro real de trabajo.[100]

Límites que justifican decisiones negativas

Muchas decisiones útiles aquí son negativas. Sirven para evitar complejidad antes de tiempo.

La primera es no usar RAG —recuperación de fragmentos antes de generar— cuando el contexto cabe y está controlado. La revisión editorial, la conversación de recuperación de un run fallido y el diagnóstico de errores pueden resolverse como CAG —contexto completo en ventana— porque el material relevante es el propio run, sus checkpoints y sus pasos, y todo eso cabe. La frontera no es ideológica. Depende de tamaño y costo: si el contexto necesario es conocido y acotado, lo pasas entero; si tienes que elegir, recuperas.[11]

La segunda es no usar agentes donde ya conoces el procedimiento. Una cadena fija sirve cuando el orden del trabajo ya está decidido: analizar corpus, proponer índice, escribir secciones, ensamblar. Meter un agente para decidir ese orden añade llamadas, imprevisibilidad y costo para resolver algo que no estaba roto. La regla reusable es clara: cadena fija cuando el procedimiento se conoce; agente cuando lo que debes decidir es el procedimiento mismo.[49]

La tercera es no separar el sistema a otro repositorio o módulo aislado salvo que la complejidad operativa lo exija. Si ya tienes autenticación, despliegue y dominio en el sistema principal, separar por gusto puede duplicar trabajo sin comprar aislamiento útil. La condición de revisión documentada aquí es concreta: vale la pena replantearlo cuando el módulo empiece a tener usuarios distintos.[67]

Cuándo sí conviene ampliar la arquitectura

Hay tres disparadores claros para cambiar de enfoque.

El primero es el crecimiento del corpus. Pasar de CAG a RAG se vuelve razonable por tamaño, por atención del modelo y por dinero. Si el corpus crece de decenas de documentos a cientos, ya no cabe en una sola ventana. Aunque cupiera, llenar la ventana no garantiza buen uso del contexto, porque el rendimiento cae cuando la información relevante queda en medio de un contexto largo. Y además cada token de entrada se cobra en cada llamada, así que reenviar todo el corpus en un pipeline de varios pasos multiplica el gasto.[10]

El segundo es la incertidumbre operativa. Si no sabes de antemano qué falló ni qué acción corresponde, un bucle agéntico sí compra algo real. El caso documentado es la recuperación de un run fallido: ahí hay que leer el error, revisar checkpoints, proponer un parche y decidir qué paso reintentar. Ésa sí es la forma de problema donde un agente está justificado.[49]

El tercero es el aumento de complejidad de integración. Mientras una sola aplicación absorba bien autenticación, despliegue y separación de dominios, integrar y aislar puede bastar. Si el módulo adquiere usuarios, flujos o exigencias propias, entonces separar deja de ser capricho y se vuelve una medida operativa.[67]

Los costos que más se esconden

El gasto de un agente no viene de una sola parte. El corpus enumera cuatro fuentes: más llamadas al modelo, contexto que engorda en cada vuelta porque se reenvía lo acumulado, tokens de razonamiento en cada iteración y exploración que a veces no produce nada. La dominante es el contexto arrastrado. En casos complejos, un factor de cinco frente a un pipeline equivalente es una cifra realista.[96]

De ahí salen límites operativos concretos. Un bucle agéntico necesita tope de vueltas. Si el agente no llega a una propuesta en unas pocas iteraciones, una vuelta extra rara vez arregla el problema. También conviene no reenviar el historial completo cuando basta con el estado, y elegir modelo según el tipo de paso en vez de usar el más capaz para todo.[96]

Antes de dejar correr un sistema así sin supervisión, el corpus recomienda al menos esto:

1. Cadena de proveedores configurada y probada, con conmutación sólo por infraestructura.
2. Tiempo límite del trabajo mayor que el del proveedor.
3. Reintentos con espera creciente y tope.
4. Registro de consumo por llamada, con tokens crudos y actividad.
5. Tope de vueltas en cualquier bucle agéntico.
6. Un lugar donde mirar qué se degradó.[96]

Si usas la capa oficial de Laravel, la instalación base queda así:

composer require laravel/ai
php artisan vendor:publish --provider="Laravel\Ai\AiServiceProvider"
php artisan migrate

La migración crea, entre otras cosas, tablas para persistir conversaciones de agente. Eso permite reanudar una conversación pausada y deja una huella útil para auditoría y aprobación humana.[133]

Lo que este enfoque no resuelve todavía

También hay que decir qué queda fuera. El corpus descarta por ahora una evaluación automática de calidad con un modelo juez al estilo de RAGAS, por una razón de alcance y de auditoría: meter un juez automático introduce una calibración que no se puede revisar caso por caso. Se deja como línea de trabajo declarada, no como promesa escondida.[61]

Eso marca el límite de operación actual. Puedes medir costo por llamada y por etapa. Puedes fijar presupuestos de contexto. Puedes exigir citas por identificador y revisar si corresponden. Puedes poner topes a los bucles y escuchar eventos para saber dónde se fue el dinero. Lo que todavía no tienes aquí, con material reproducible, es una fórmula cerrada de evaluación, un panel completo de recuperación, un método verificable de chunking ni un procedimiento formal de auditoría de citas extremo a extremo.

La regla final sí es repetible. Primero gobierna el material y la trazabilidad. Luego optimiza modelos, recuperación y agentes. Si mezclas esas prioridades, terminas afinando velocidad y autonomía sobre un sistema que todavía no puedes defender cuando falla.