Bitácora Dev

Montar un agente de IA en casa: lo que cuesta de verdad

Rubén — Sun, 18 Oct 2026 00:00:00 GMT

Llevo meses con agentes de IA corriendo dentro de mi propia red: uno que gestiona tareas del día a día, otro que vigila servicios y otro que escribe documentación. Cuando cuento que “tengo agentes en casa”, la pregunta es siempre la misma: ¿y eso cuánto cuesta? La respuesta honesta es que depende de una cosa que casi nadie mide bien: qué modelo usas para cada tarea.

Lo primero: local no significa gratis

Hay una idea muy extendida de que si el modelo corre en tu máquina, el coste es cero. Es falso, solo se paga en otra moneda:

Hardware: un modelo de 7-8B en cuantización Q4 necesita unos 6 GB de VRAM libres para ir cómodo. En una GPU integrada, o tiras de CPU, o no cabe.
Energía y calor: una GPU al 100% durante horas se nota en la factura y en el ruido.
Tiempo: la primera respuesta de un modelo cargado en frío puede tardar 20 o 30 segundos. Eso mata cualquier flujo interactivo.

En mi caso, la conclusión fue clara: local para lo que se repite y no necesita cabeza, API para lo que sí. Un modelo pequeño local para clasificar, resumir o extraer campos; un modelo grande remoto para razonar, escribir o decidir.

La aritmética que de verdad importa

El error típico es mirar solo el precio por millón de tokens de entrada y salida. Lo que cambia la factura es el tamaño del contexto que arrastras en cada llamada. Si tu agente manda 12.000 tokens de historial en cada iteración de un bucle de 8 pasos, has pagado 96.000 tokens de entrada para una tarea que quizá necesitaba 2.000.

Tres reglas que aplico siempre:

Contexto mínimo viable. Cada herramienta externa que expones al modelo añade tokens a cada llamada. Si tienes 30 herramientas descritas, estás pagando por las 30 en todas las peticiones.
Recorta el historial, no lo acumules. Resumir los turnos viejos cuesta una llamada barata y ahorra muchas caras.
Mide. Sin métricas por tarea no sabes si el gasto viene de un bucle que se repite o de un contexto inflado.

# Mal: el agente arrastra todo el historial en cada paso
messages = history + [nuevo_mensaje]

# Bien: ventana recortada + resumen de lo anterior
messages = [resumen_previo] + history[-6:] + [nuevo_mensaje]

Latencias: el enemigo silencioso

Un agente que tarda 4 minutos en hacer algo que tú harías en 30 segundos no se usa. Y el tiempo se va casi siempre en tres sitios:

Cadenas de herramientas que se llaman en secuencia cuando podrían ir en paralelo.
Reintentos silenciosos: un proveedor que devuelve error y el agente reintenta tres veces con backoff exponencial. El usuario solo ve que “va lento”.
Arranque en frío del modelo local.

Medir el tiempo por paso, y no solo el total, fue lo que me dejó ver que la mitad del tiempo se iba en un reintento que no hacía falta.

Cosas que rompen y nadie te cuenta

Credenciales que caducan. Un token expirado convierte un agente en un generador de errores. Si tienes varias tareas programadas, van a fallar todas a la vez y a la misma hora. Merece la pena tener un chequeo periódico que valide la credencial antes de que lo haga el trabajo real.
Procesos que mueren en silencio. Un listener que nadie supervisa deja de funcionar y la tarea que dependía de él se queda esperando para siempre. Si un componente es crítico, necesita su propio servicio con reinicio automático, no un proceso lanzado a mano.
El estado compartido. Si dos agentes se coordinan por un canal (Redis, cola, fichero), ese canal es infraestructura: hay que tratarlo como tal, con su autenticación y su monitorización.

Un agente no es un script con esteroides: es un servicio más. Si no lo despliegas, monitorizas y respaldas como tal, te va a despertar de noche.

Cómo lo tengo montado hoy

Modelo pequeño local para tareas de clasificación y extracción: coste cero por llamada y datos que no salen de casa.
Modelo grande remoto para razonamiento y redacción, con contexto recortado y medición por tarea.
Credenciales centralizadas y un chequeo diario que avisa si alguna ha dejado de valer.
Todo bajo supervisión: los componentes críticos corren con reinicio automático y logs rotados, porque un log de 1,5 GB también es un fallo de diseño.

Qué haría distinto si empezara hoy

Empezaría por medir antes de optimizar: registrar tokens, latencia y coste por tarea desde el primer día. Y separaría desde el principio lo que es infraestructura de lo que es experimento. La mayor parte del tiempo perdido no vino de elegir mal el modelo, sino de tratar como juguete algo que estaba sosteniendo tareas reales.

RAG en local: cuándo merece la pena y cuándo es un juguete

Rubén — Sun, 11 Oct 2026 00:00:00 GMT

Cada pocas semanas alguien pregunta cómo montar un RAG sobre su documentación. La respuesta corta es que depende de la pregunta que vayas a hacer, y que hay un porcentaje alto de casos donde un grep bien afinado gana. Este artículo es el criterio que aplico antes de levantar nada.

Qué resuelve RAG de verdad

RAG (generación aumentada por recuperación) sirve para una cosa concreta: encontrar trozos de texto relevantes cuando la coincidencia exacta de palabras no funciona.

Gana cuando:

Las preguntas son conceptuales: “¿cómo decidimos los topes de facturación?”.
El vocabulario del que pregunta y el del documento no coinciden.
La información está repartida y hay que juntar varios fragmentos.

Pierde cuando:

Buscas un identificador, un error exacto o un nombre de función → grep es instantáneo, determinista y no alucina.
El corpus es pequeño (menos de, digamos, 50 documentos): leerlos enteros es más barato y más fiable que indexarlos.
Necesitas que la respuesta sea auditable al 100%: con RAG siempre hay un fragmento recuperado y un modelo interpretando.

La decisión, en una tabla

Situación	Herramienta
Busco un error o un ID exacto	`grep`/ripgrep
Corpus pequeño (< 50 docs)	leer completo, sin índice
Preguntas conceptuales, vocabulario variable	RAG
Necesito citas verificables	RAG con enlaces al fragmento
Datos muy sensibles	local, y solo si el índice se queda en casa

Montar el índice: las decisiones que importan

1. El troceado (chunking)

Es la decisión que más afecta a la calidad y la que menos gente revisa. Trozos demasiado pequeños pierden contexto; demasiado grandes diluyen la señal y encarecen cada consulta.

# Un troceado razonable para documentación técnica:
# respeta los encabezados y no parte código por la mitad.
def chunk(texto, max_tokens=600, solape=80):
    bloques = partir_por_encabezados(texto)
    return [ventana(b, max_tokens, solape) for b in bloques]

Regla práctica: el trozo debe responder por sí solo a una pregunta. Si al leerlo hace falta el párrafo anterior para entenderlo, es demasiado pequeño.

2. El modelo de embeddings

Aquí sí conviene gastar un poco de cabeza: un modelo malo de embeddings hace que el problema parezca de “generación” cuando en realidad es de recuperación. Y ojo con mezclar idiomas: si el corpus está en español, el modelo tiene que ir bien en español, no solo en inglés.

3. El re-ranking

Recuperar 20 candidatos y quedarse con los 5 mejores cuesta poquísimo y suele mejorar el resultado más que cambiar de modelo generador.

Cómo evaluar sin engañarte

La trampa clásica es probar con 5 preguntas que tú mismo has escrito sabiendo ya la respuesta: todo funciona. El método que uso:

Conjunto de preguntas reales (20-30), incluyendo las que sabes que fallan.
Para cada una, marcar qué documento debería salir. Sin esto no hay evaluación posible.
Medir dos cosas separadas: ¿recuperó el documento correcto? y ¿la respuesta final fue correcta?.
Repetir con grep como línea base. Si tu RAG no supera al grep en recuperación, no merece la complejidad.

Si no puedes medir si el sistema acierta, no tienes un sistema: tienes una demo.

Lo que se rompe en producción

Índice desactualizado. Si los documentos cambian y el índice no, el RAG responde con datos viejos con total seguridad. La reindexación tiene que ser parte del flujo, no un script manual que se olvida.
Coste por consulta descontrolado. Recuperar 50 fragmentos y pasarlos todos al modelo multiplica el coste sin mejorar la respuesta.
Confianza excesiva en la respuesta. RAG no elimina las alucinaciones: las reduce cuando la recuperación es buena, y las esconde cuando es mala. Hay que citar siempre el fragmento de origen y comprobarlo.

Mi conclusión

Para buscarme a mí mismo entre mis notas: grep y nombres de fichero decentes. Para preguntas conceptuales sobre documentación larga y cambiante: RAG, con índice local, troceado que respeta la estructura y evaluación medida. Y en cualquier caso, la decisión se toma con el conjunto de preguntas reales delante, no con la sensación de que las respuestas suenan bien.

Refactorizar una app en producción sin romperla: el método

Rubén — Sun, 04 Oct 2026 00:00:00 GMT

Toda aplicación que dura acaba teniendo el mismo problema: la lógica de negocio vive en las vistas, las vistas llaman al ORM directamente y nadie se atreve a tocar nada. La semana pasada cerré una refactorización de meses sobre una aplicación en producción: reorganización por capas, fusión de dos líneas de desarrollo divergentes y despliegue final sin incidencias. Este es el orden que seguí, porque el orden es lo que hace que no se rompa nada.

1. Nunca refactorices sin tests que te cubran

Antes de mover una sola línea, necesitas tests de caracterización: pruebas que fijen el comportamiento actual, aunque el código sea feo. No buscan corrección, buscan “que siga haciendo lo mismo”.

# Congela el comportamiento de las zonas que vas a tocar
pytest apps/facturacion apps/informes -q --create-db

Dos detalles que ahorran disgustos:

--create-db (esquema fresco). Una base de tests reutilizada de una ejecución anterior hace fallar tests correctos con errores que parecen del código, y te manda a cazar fantasmas.
Ejecuta la suite completa contra el commit anterior cuando algo falla. Si ya fallaba antes, no es una regresión: es deuda. Y hay que decirlo con la prueba delante, no de memoria.

2. Separar en capas, pero por dentro

El patrón que mejor me ha funcionado es el aburrido:

selectors/ → consultas a base de datos.
services/ → lógica de negocio y cálculos.
views/ → orquestación fina: validar entrada, llamar al servicio, devolver respuesta.

Lo importante no es el nombre de las carpetas, sino que el cálculo salga de la vista. En cuanto un cálculo vive en una función propia, se puede probar sin HTTP, sin sesión y sin plantillas. Ahí es donde la refactorización empieza a pagarse sola.

3. Ramas divergentes: comparar remotos, no locales

Si llevas meses con dos líneas de trabajo (la refactorizada y la de funcionalidades), las ramas locales mienten: probablemente están atrasadas. Compara siempre contra el remoto, tras un fetch --prune:

git fetch --all --prune
git rev-list --count origin/main..origin/refactor   # commits que le faltan a main
git cherry origin/main origin/refactor | head       # parches ya aplicados (-) vs nuevos (+)

Y para saber qué ficheros faltan de verdad, a nivel de árbol:

comm -23 <(git ls-tree -r --name-only origin/refactor | sort) \
         <(git ls-tree -r --name-only origin/main | sort)

4. El merge limpio que pierde código (el pitfall que más me mordió)

Un merge puede resolver sin marcar conflicto y aun así tirar un cambio. Ocurre cuando una rama extrajo un bloque a un método y la otra modificó ese mismo bloque: el hunk entrante desaparece dentro de la llamada al método nuevo. Git dice “todo bien” y tú has perdido un arreglo.

Verificación obligatoria tras cada merge, por cada cambio semántico:

grep el nombre del parámetro/método nuevo en el fichero fusionado.
Ojo al caso traicionero: el parámetro existe pero la lógica que lo usa no. Parece portado y no lo está.
git diff origin/<rama-features> HEAD -- <fichero>: lo que salga debe ser estructura, nunca comportamiento que falta.

Un merge que termina “limpio” no demuestra nada. La prueba es buscar el comportamiento, no confiar en el mensaje de git.

5. Fusionar en el orden correcto

El orden que funcionó:

Refactor → línea de funcionalidades (ahí están los conflictos gordos).
Línea unificada → main.
Comprobar si es fast-forward: git merge-base --is-ancestor A B antes de mergear.

Y si hay conflicto en ficheros de cálculo, se resuelve a mano, nunca con --ours/--theirs en bloque. En ficheros de interfaz que se reescribieron junto con sus plantillas y sus rutas, se toma la versión entrante entera: mezclar media interfaz nueva con media vieja es peor que elegir una.

6. Desplegar con red, no con fé

Antes de tocar producción:

Copia de la base de datos con verificación de integridad (pg_restore -l sobre el dump, y contar filas de las tablas clave antes y después).
Guardar el trabajo local del servidor: si el checkout de producción tiene cambios a mano, haz un parche antes de resetear. Y comprueba si esos cambios ya están en la release.
Anotar los identificadores de las imágenes Docker actuales para poder volver atrás.
Un modo de mantenimiento real, no un rm a mano de un fichero.

# Antes de desplegar: copia + parche de cambios locales + inventario de imágenes
bash scripts/pre_deploy_backup.sh
docker inspect --format '{{.Image}}' web > imagenes_previas.txt

Y tras el despliegue, un script de verificación que compruebe lo que importa: commit desplegado, migraciones aplicadas sin pendientes (migrate --check), traducciones compiladas, traducciones presentes, petición HTTP real y conteo de filas de las tablas críticas.

7. Limpiar

Cuando la rama ya está integrada, se borra. Pero con criterio:

Demuestra que está contenida antes de borrarla: git rev-list --count origin/main..origin/<rama> debe dar 0.
Si está checkouteada en un worktree, no la puedes borrar: primero git -C <worktree> checkout --detach <sha>.
Deja una rama de seguridad backup/<rama>-pre-merge-<fecha> y decide después si sobra.

Lo que me llevo

La refactorización no fue difícil por el código: fue difícil por la incertidumbre. Cada paso buscaba reducirla: tests que congelan el comportamiento, comparaciones contra el remoto, verificación de cada cambio tras el merge, copias con integridad comprobada y un despliegue con marcha atrás preparada. Si tuviera que resumirlo en una frase: no se trata de escribir código mejor, se trata de no perder nada por el camino.