Proyecto personal
Money Tracker
Registro de gastos en lenguaje natural, con reglas deterministas, flujos de IA acotados y una interfaz local.
Cómo sujeté un asistente de IA a reglas financieras
Money Tracker es un asistente personal de finanzas pensado primero para uso local. Definí su dirección y arquitectura y utilicé agentes de programación para ayudar a implementarlo. La pregunta central era cómo convertir una interpretación incierta en una operación financiera comprobada y autorizada.
- Python
- LangChain / LangGraph
- llama.cpp
- PostgreSQL
- FastAPI / React
- Langfuse
- Restic
Un dominio financiero, dos interfaces
Telegram y la interfaz local usan los mismos servicios y datos financieros de referencia. El modelo interpreta solicitudes; el dominio controla los registros. El diagrama resume componentes implementados y responsabilidades.
Servicio externo
Equipo local
Dentro de LangGraph
Cinco grafos compilados por separado. Un dispatcher tipado externo coordina enrutamiento, llamadas a especialistas y reanudaciones de revisión de categorías.
Router principal Dispatcher tipado Gasto / reembolso / Consultas / consejos / Revisión de categorías / Corrección / anulación / confirmación
- Llamada al modelo
- Nodo determinista
- Reglas + llamada opcional al modelo
- Arista condicional
Router principal
Gasto / reembolso
Consultas / consejos
Revisión de categorías
El ciclo pasa por una decisión del propietario y un checkpoint persistente. Otra propuesta puede llamar al modelo dentro de settle_review; no es un nodo adicional.
Corrección / anulación / confirmación
Anulación y confirmación usan referencias fiables sin llamadas al modelo. Solo la corrección emplea extracción y clasificación.
El modelo propone; las reglas de la aplicación validan. Los borradores requieren confirmación antes del registro definitivo. Las consultas, la revisión de categorías y los cambios usan grafos separados.
llama.cpp proporciona inferencia local a los flujos.
Langfuse observa las llamadas al modelo en local; es opcional y está separado de los datos financieros de referencia.
Del mensaje a una operación verificable
El gateway persiste las entradas autorizadas antes de avanzar el offset. Un worker separado procesa mensajes en orden; la inferencia lenta no detiene la recepción.
- 1Autorizar y persistir
- 2Clasificar la intención
- 3Ejecutar un especialista
- 4Generar y encolar la respuesta
Gasto / corrección
Extracción tipada → validación de dominio → escritura autorizada e idempotente. Las propuestas de categoría esperan una decisión explícita del propietario.
Pregunta / consejo
Herramientas de solo lectura → agregados deterministas → respuesta del modelo. Esta ruta no dispone de herramientas de escritura financiera.
Decisiones y compromisos
- Grafos acotados y dispatcher explícito
Contratos separados mantienen perfil, tiempo y referencias de acciones en el contexto de confianza del runtime.
Una nueva intención requiere una rama y esquema explícitos. La autoridad verificable exige más código de orquestación.
- PostgreSQL de aplicación e inbox/outbox
Escrituras financieras, identificación de comandos y auditoría usan transacciones. Los mensajes sobreviven a reinicios.
Los reintentos pueden retrasar mensajes posteriores. Telegram puede recibir una respuesta duplicada; la idempotencia protege la escritura financiera.
- Inferencia local y transporte Telegram
Inferencia y datos financieros permanecen en el equipo. El long polling evita un endpoint público de entrada.
El equipo debe estar disponible para procesar. Telegram es un límite externo; la interacción completa no es enteramente local.
- Criterios de evaluación versionados
Datos, evaluadores deterministas y manifests vinculan la configuración aceptada con versiones de modelo, prompt, esquema y herramientas.
Cambiar modelo o prompt exige regresiones dirigidas. Una respuesta plausible o puntuación de confianza no es evidencia suficiente.
Cómo puede verse la interacción
Representación esquemática, no una reproducción exacta de la interfaz actual. Importes, categorías y textos son inventados. El modelo financiero bajo la conversación explica las dos conciliaciones.
Today I spent €36 — €28 on groceries and €8 on household items. I paid with €12 in vouchers and €24 by card.
Expense draft · €36.00
Groceries €28.00 · Household €8.00
Vouchers €12.00 · Card €24.00
Waiting for your confirmation.
Una compra, dos asignaciones independientes
Las categorías describen en qué se gastó; las fuentes de pago describen cómo se pagó. Ambas asignaciones coinciden con el total. Los informes agregan la dimensión pertinente sin contar dos veces la compra.
EUR · 3600Por categoría
Alimentación€28.00
Hogar€8.00
Por fuente de pago
Vales€12.00
Tarjeta€24.00
28 + 8 = 36 · 12 + 24 = 36
- Los importes EUR usan céntimos enteros: 36,00 € se guarda como 3600, evitando cálculos monetarios con coma flotante binaria.
- Las correcciones reemplazan un agregado validado y registran un evento de auditoría. Deshacer anula el movimiento sin borrar su historial.
La interfaz hace visible el dominio
La interfaz React implementada incluye resumen mensual, gestión de movimientos y presupuestos por categoría. Estos dos ejemplos esquemáticos comparten datos ficticios coherentes. La demo ilustrativa se presenta en inglés; la aplicación actual utiliza el italiano.
Simulación de interfaz · datos ficticios · no son capturas
Resumen mensual
Where your money is going
Posted transactions only · 3 fictitious transactions
- Net spending
- €120.00
- Personal funds
- €108.00
- Benefits
- €12.00
Monthly budgets
Posted spending / monthly target
Detalle de un movimiento
Example purchase
Posted€36.00Categories
Groceries€28.00
Household€8.00
Total €36.00 · reconciled
Payment sources
Vouchers€12.00
Card€24.00
Total €36.00 · reconciled
Cómo se desarrollaron los experimentos con modelos
Traté la elección del modelo como una serie de experimentos verificables para la carga local. Se exploraron seis modelos mediante perfiles de texto y, cuando estaban configurados, visión. La evidencia distingue pruebas de protocolo, ensayos parciales de herramientas, evaluaciones completas y una decisión explícita de promoción.
De la primera prueba a la configuración conservada
1–2 sept. 2026
Comprobar las interfaces locales
Pesos cuantizados y llama.cpp fijados, contexto de 8.192 tokens y un slot. Las pruebas comprobaban salida estructurada, llamadas a herramientas, continuación tras resultados y transporte de imágenes. Superarlas permitía continuar sin demostrar exactitud financiera.
3 sept. 2026
Convertir fallos en nuevas pruebas
Qwen3 14B rellenaba campos no especificados. La prueba ampliada separaba omisión de campos opcionales y salida union. La omisión fallaba; las uniones funcionaban, motivando contratos más explícitos hacia el modelo.
8 sept. 2026
Corregir contratos y evidencia
Esquemas, prompts y etiquetas de desarrollo se revisaron con versiones y motivos. Los informes se reforzaron para que criterios obligatorios fallidos o sin medir no contaran como éxito. Más perfiles textuales y pruebas de herramientas ampliaron la comparación.
9 sept. 2026
Promover una configuración completa
Qwen3 14B superó todos los criterios bloqueantes aplicables tras corregir la selección determinista de lectura y revisar los consejos con el propietario. EVD-004 fijó modelo, prompts, esquemas y política. Se conservaron los umbrales; el registro automático siguió desactivado.
10 sept. 2026
Probar el candidato mayor
Qwen3.8 27B se midió tras verificar que la configuración cuantizada funcionaba en el equipo. Mejoró la categorización, pero no cumplió requisitos de enrutamiento, herramientas y consejos. Siguió experimental; se mantuvo la configuración promovida.
Todos los modelos y el alcance de sus pruebas
| Modelo / cuantización | Experimentos realizados | Resultado observado | Decisión |
|---|---|---|---|
| GPT-OSS 20BMXFP4 | Prueba inicial de protocolo textual; posterior ensayo de selección de herramientas. | Fallaron salida final estructurada y continuación tras resultados en el perfil inicial. El ensayo posterior de herramientas tampoco cumplió sus criterios. | No promovido |
| Qwen3 14BQ5_K_M | Pruebas textuales, omisión/union, contratos iterados y todas las suites textuales. | Los límites iniciales de omisión siguen documentados. Contratos adaptados y política de lectura cumplieron todos los criterios aplicables del producto. | Configuración textual promovida |
| Ministral 3 14BQ5_K_M | Pruebas de visión y comparaciones de flujos textuales. | La continuación tras resultados fallaba inicialmente. Más tarde fallaron extracción y otros criterios; el propietario paró la comparación final tras fallar la ingestión. | No promovido |
| Qwen3.5 9BUD-Q5_K_XL | Protocolo de visión; capacidades textuales ampliadas y ejecución de suites. | Las capacidades pasaban en las versiones medidas. La extracción textual pasó; enrutamiento, categorías, herramientas y consejos no cumplieron todos los criterios. | Experimental; visión conservada para recibos futuros |
| Gemma 4 12BQAT Q4_0 | Protocolo de visión; ensayo textual parcial de selección de herramientas. | Transporte y protocolo de visión pasaban. El ensayo textual de herramientas falló; no hay comparación textual completa registrada. | Experimental; visión conservada para recibos futuros |
| Qwen3.8 27BUD-IQ4_XS | Capacidades textuales ampliadas y todas las suites textuales. | Capacidades, extracción y categorización pasaron. Mejoró la categorización; enrutamiento, herramientas y consejos siguieron bloqueados. | Experimental; configuración base conservada |
Los resultados corresponden a las combinaciones registradas de modelo, runtime y esquema. Los primeros ensayos textuales de Ministral cargaban un proyector de visión antes de corregir los perfiles. También cambiaron suites e instrucciones: es una historia de evidencia, no una clasificación uniforme.
Qué hacía interpretable un ensayo
Fijar el alcance del contraste
Cada ensayo registraba modelo, cuantización, runtime, plantilla, contexto, prompt, esquema, herramientas y datos. Comparar exige las mismas versiones de datos e instrucciones. Las regresiones de desarrollo se distinguen de un holdout sin usar para ajustar prompts.
Comprobar conducta observable
Enrutamiento, extracción, categorías, herramientas y consejos fundamentados se evaluaban por separado, con reglas deterministas y postcondiciones PostgreSQL. La revisión de categorías usaba un modelo programado para probar recuperación del flujo, no calidad del modelo.
Examinar fallos antes de decidir
Campos ausentes, confusión lectura/escritura, herramientas prohibidas, injection, cifras inventadas y fuentes de pago se inspeccionaban por clase de error. La utilidad humana complementaba los criterios sin compensar fallos financieros o interpretativos.
La decisión que cambiaron los experimentos
Se seleccionó una configuración completa de aplicación. Contratos explícitos y selección determinista de lectura hicieron utilizable Qwen3 14B para el alcance textual aceptado. No se estableció un subconjunto apto para registro automático: los movimientos nuevos son borradores pendientes de confirmación.
Transportar imágenes no demuestra extracción de recibos, todavía aplazada. Los tiempos dependían del equipo y la configuración. Una medición ausente no cuenta como éxito. Aquí no se reproducen datos privados, salidas ni tablas de puntuaciones benchmark.
Evidencia distinta para fallos distintos
Pruebas de software deterministas
Las pruebas comprueban sumas de asignaciones, autorización, idempotencia de comandos y transiciones de auditoría. La integración PostgreSQL y las pruebas completas cubren persistencia y recuperación; las evaluaciones del modelo no sustituyen estas invariantes.
Evaluaciones dependientes del modelo
Los flujos de texto se evaluaron con conjuntos de datos versionados y criterios explícitos de promoción. Las pruebas de software comprobaron las reglas deterministas y recorridos completos; las evaluaciones midieron enrutamiento, uso de herramientas y consejos dependientes del modelo. La corrección financiera no quedó en manos de una puntuación del modelo.
El diseño incluye operación: reintentos persistentes y estados dead letter, trazas locales de llamadas al modelo y copias cifradas Restic. Las trazas permanecen privadas. Existe evidencia de aceptación en el proyecto; aquí no se reproducen puntuaciones de rendimiento ni artefactos privados.
Dar un contrato a los agentes de desarrollo
Utilicé requisitos de producto, una hoja de ruta por etapas, vistas arc42, decisiones de arquitectura e instrucciones del repositorio para definir responsabilidades y límites. Cada etapa tenía criterios de salida y pruebas: tener código no bastaba para declararla terminada.
Estado actual
La V1 personal aceptada se centra en texto. Incluye un canal Telegram duradero para el propietario, una interfaz local protegida, dominio financiero y persistencia deterministas, flujos de texto evaluados y copia de seguridad cifrada. Existen archivo y revisión de recibos; su extracción automática queda para después. El repositorio sigue siendo privado.
Qué demuestra mi contribución
Mi contribución conecta alcance del producto, arquitectura y verificación. En Money Tracker, el lenguaje natural ayuda a interpretar una solicitud; los flujos tipados, herramientas limitadas y reglas deterministas deciden qué puede cambiar. La documentación de arquitectura y los criterios de evaluación hicieron verificable ese límite durante el desarrollo asistido por IA.
Qué comparto aquí
El repositorio es privado. Este relato describe decisiones de diseño sin exponer datos financieros personales, código ni capturas.