Ingeniería de producción para sistemas LLM financieros

Objetivos de aprendizaje

• Instrumentar un agente LangChain/LangGraph con tracing OpenTelemetry en LangSmith, estructurando datasets versionados con splits y evaluación offline/online.
• Seleccionar la plataforma de observabilidad adecuada (LangSmith, Langfuse, Phoenix, Galileo, Braintrust) según licencia, residencia de datos y modelo de precios.
• Construir un golden dataset financiero estilo FinanceBench y evaluar agentes con exact-match numérico y métricas de trayectoria, no solo con LLM-as-judge.
• Integrar la evaluación en CI/CD con quality gates que bloquean merges ante regresiones de prompts.
• Diseñar una pila de guardarraíles en defensa por capas: PII, grounding numérico fail-closed, rate limiting, circuit breakers y kill-switch.
• Presupuestar tokens y latencia por arquitectura (single-agent, debate, swarm) y delimitar qué decisiones de trading admiten agentes y cuáles exigen determinismo.

El módulo 10 estableció la observabilidad como defensa ante el vacío de gobernanza: SR 26-2 excluye explícitamente la IA agéntica del marco de model risk, de modo que la firma sigue siendo plenamente responsable sin norma que le diga cómo gobernarla. Este módulo implementa esa defensa técnicamente. La tesis operativa es doble: la evaluación financiera rigurosa exige exact-match numérico y de trayectoria (insight I6 del curso), y la economía de tokens de julio de 2026 ya permite agentes en producción para research y riesgo, mientras la latencia compuesta de los loops agénticos delimita dónde no pueden operar (insight I7). Ambas ideas se desarrollan con precios y casos verificados a julio de 2026.

11.1 Observabilidad con LangSmith

11.1.1 Tracing, datasets, evaluadores, experiments, dashboards y alertas

LangSmith es la plataforma first-party de LangChain y, a julio de 2026, se ha consolidado como plataforma completa de "agent engineering" y no solo como visor de trazas (Divitae Assets) . En aplicaciones LangChain/LangGraph el tracing se activa por variables de entorno (LANGSMITH_TRACING=true) sin instrumentación adicional: cada paso de cadena, decisión de agente y llamada a herramienta queda capturado (Divitae Assets) . La plataforma es framework-agnostic —traza aplicaciones construidas con los SDK de OpenAI, Anthropic, Vercel AI, LlamaIndex o implementaciones propias— y acepta trazas OpenTelemetry vía endpoint OTLP, soporte añadido en marzo de 2026 (SimTrade) . El SDK usa un callback asíncrono que envía trazas a un colector distribuido: el rendimiento de la aplicación no se ve afectado y, si LangSmith sufre un incidente, el agente sigue operando con normalidad (SimTrade) . Para un desk regulado, esta propiedad no es un detalle: la observabilidad nunca debe convertirse en un punto único de fallo del pipeline de decisión.

La segunda pieza son los datasets: colecciones de ejemplos (inputs, reference outputs opcional, metadata opcional) donde los reference outputs no se pasan a la aplicación, solo se usan en evaluadores, y la metadata permite vistas filtradas y splits versionados (questdb.com) . La recomendación oficial es empezar con 5–10 ejemplos curados a mano por componente crítico —para un agente financiero, ejemplos de selección correcta de herramienta, formato de argumentos o trayectoria de razonamiento— y crecer desde producción (questdb.com) . Las annotation queues cierran el ciclo: convierten trazas de producción en ejemplos de dataset con rúbricas, múltiples revisores, reservas anti-conflicto y exportación directa (questdb.com) .

LangSmith soporta cuatro técnicas de evaluación (questdb.com) : humana (revisión manual con annotation queues; sign-off de analista sobre respuestas que alimentan informes), código determinista (funciones rule-based: exact match numérico de cifras extraídas de un 10-K, validación de schema JSON), LLM-as-judge (reference-free o reference-based; útil para corrección factual contra la evidencia del filing o completitud de resúmenes de earnings) y pairwise (comparación A/B de dos versiones cuando puntuar en absoluto es difícil). La documentación advierte que los evaluadores LLM-as-judge requieren revisión cuidadosa de scores y ajuste del prompt del juez, y que los few-shot evaluators —con ejemplos de inputs, outputs y notas esperadas— suelen mejorar el rendimiento (questdb.com) . Un experiment es el resultado de evaluar una versión concreta sobre un dataset, capturando outputs, scores y trazas por ejemplo, con comparación y experiments pairwise (questdb.com) . El ciclo de vida recomendado: la evaluación offline valida antes de desplegar (benchmarking, regression testing, backtesting), la online monitoriza tráfico vivo, y los fallos online se convierten en casos offline permanentes (questdb.com) .

En producción, LangSmith genera dashboards preconstruidos por proyecto con secciones de trazas (conteo, latencia, error rate), llamadas LLM, Cost & Tokens (totales y por traza, por tipo de token), herramientas más usadas y feedback scores; los custom dashboards añaden métricas de latencia p50/p99, time to first token (TTFT) y ratios con filtros propios (Bing) . Las alertas operan por umbral sobre cinco métricas (Run Count, Cost, Errors, Feedback Score, Latency), con ventanas de 5 o 15 minutos y destinos Slack (nativo), PagerDuty, Dynatrace o webhook HTTP; la buena práctica oficial es empezar con umbrales amplios y refinar (twopirllc.github.io) . El siguiente snippet muestra la activación de tracing, la creación de un dataset con split y el lanzamiento de un experimento con evaluadores propios:

import os
os.environ["LANGSMITH_TRACING"] = "true"
os.environ["LANGSMITH_PROJECT"] = "research-agent-prod"

from langsmith import Client, evaluate

client = Client()

# Dataset dorado con split de regresión (ejemplos = inputs + reference outputs)
ds = client.create_dataset("golden-10k-extraction-v3",
                           description="Extracción de cifras de 10-K/10-Q, split regression")
client.create_examples(
    inputs=[{"question": "¿Cuál fue el EPS diluido de ACME en el FY25?"}],
    outputs=[{"answer": "$0.78", "evidence": "10-K FY25, p. 47"}],
    metadata=[{"split": "regression", "task": "extraccion_puntual"}],
    dataset_id=ds.id,
)

# Experimento: evalúa la versión actual del agente sobre el dataset
results = evaluate(
    lambda inputs: agent.invoke({"messages": [("user", inputs["question"])]}),
    data="golden-10k-extraction-v3",
    evaluators=[exact_match_numeric, trajectory_exact_match],   # §11.2
    experiment_prefix="gpt56-sol-prompt-v3",
    metadata={"model": "gpt-5.6-sol", "prompt_version": "v3.2"},
)

En cuanto a pricing, verificado a julio de 2026 (quantitativebrokers.com) : el plan Developer es gratuito (1 asiento, 5.000 trazas base/mes, retención de 14 días); Plus cuesta $39 por asiento/mes con 10.000 trazas incluidas; Enterprise es a medida (SSO, RBAC, retención configurable, self-hosted o híbrido). El 21 de julio de 2026 LangChain reestructuró su tarifa en dos monedas normalizadas: 1 LCU = $1,50 (compute) y 1 LSU = $1,00 (trazas y almacenamiento), con trazas extra a 0,005 LSU cada una (Github) . Señal de prudencia para presupuestos: LangChain ha cambiado el medidor de facturación de deployment tres veces en catorce meses (Github) — las estimaciones de plataforma deben hacerse con la calculadora oficial y margen de contingencia.

Las alternativas relevantes a julio de 2026 son Langfuse (open source MIT, adquirido por ClickHouse el 16 de enero de 2026, self-hosted gratis con paridad completa de features sobre backend ClickHouse) (Github) , Arize Phoenix (OTel-nativo vía OpenInference, fuerte en análisis de trayectoria a nivel de span) (Morioh) , Galileo (eval-first, métricas propietarias de groundedness pensadas para RAG donde la alucinación es el modo de fallo principal) (databento.com) y Braintrust (eval-first con quality gates de CI/CD que bloquean merges) (quantvps.com) .

Tabla 11.1 — Plataformas de observabilidad y evaluación LLM (a julio de 2026)

Fuentes: (quantitativebrokers.com) .

La decisión rara vez es técnica en sentido estricto; es una decisión de gobernanza de datos y de modelo operativo. Para una firma financiera, la primera pregunta es la residencia: si las trazas —que contienen extractos de filings, posiciones y potencialmente PII— no pueden salir del perímetro, Langfuse self-hosted bajo MIT ofrece paridad de features sin coste de licencia, y su adquisición por ClickHouse en enero de 2026 da cierta garantía de continuidad corporativa (WilmerHale) . LangSmith gana cuando el stack es LangChain/LangGraph puro y el equipo valora la amplitud de plataforma (datasets con splits, annotation queues, Deployment, Sandboxes GA desde mayo de 2026) sobre la soberanía del dato (Divitae Assets) . Phoenix encaja en organizaciones que ya han apostado por OpenTelemetry como estándar transversal de observabilidad. Galileo y Braintrust son apuestas eval-first: la primera cuando el riesgo dominante es la alucinación en RAG documental (databento.com) ; la segunda cuando la disciplina de CI/CD de prompts es el cuello de botella organizativo (quantvps.com) . Un patrón frecuente en equipos maduros es híbrido: tracing en Langfuse por residencia, gates de CI con promptfoo o Braintrust, y evaluación humana en annotation queues de cualquiera de las dos plataformas. Conviene, además, verificar trimestralmente precios y licencias: el propio registro de evidencia de este módulo detecta discrepancias entre fuentes en el tier Pro de Langfuse y en la licencia exacta de Phoenix.

11.2 Evaluación financiera rigurosa

11.2.1 Golden datasets, exact-match, trayectorias, replay y CI/CD de prompts

Un golden dataset financiero es un conjunto curado de triplets (pregunta → respuesta de referencia + evidencia) construido por expertos del dominio, con validez ecológica: refleja las tareas reales del analista, no preguntas de juguete. El modelo de referencia del sector es FinanceBench (Patronus AI): 10.231 triplets sobre 40 empresas cotizadas y 361 filings públicos 2015–2023, cada entrada con string de evidencia, página del documento y etiquetas de empresa/sector/tipo (Coursiv) . Sus lecciones operativas son directamente transplantables: anotadores con experiencia financiera tras screening, revisión semanal del 10–20% de casos por anotador, adjudicación por un analista senior, y muestra de evaluación estratificada por tipo de tarea en vez de muestreo aleatorio puro (Coursiv) . Un hallazgo crítico de diseño: en contexto largo, presentar el filing primero y la pregunta al final mejoró drásticamente a los modelos evaluados (GPT-4-Turbo: 78% vs 25%) — el orden contexto-pregunta es una variable de regresión que debe fijarse en el dataset y en los gates de CI (Coursiv) . Como semillas y baselines públicos existen FinQA (8.281 pares de razonamiento numérico multi-paso, métrica execution accuracy), ConvFinQA (3.892 conversaciones), TAT-QA (16.552 preguntas híbridas tabla-texto) y DocFinQA para contexto largo de ~123.000 palabras (BenchLM) .

La receta práctica para construir el dataset propio tiene cinco pasos: (1) muestrear 100–1.000 trazas reales de producción y anonimizar PII antes de curar —obligatorio bajo GDPR—; (2) estratificar por tipo de tarea: extracción de cifra puntual, cálculo derivado (growth, márgenes), multi-hop entre secciones, tabla vs. texto y, críticamente, preguntas no contestables con el documento para medir la abstención; (3) anotar con expertos y QC del 10–20%; (4) versionar con splits (base / regression / adversarial) y etiquetar dificultad y origen; (5) convertir cada incidente de producción confirmado en caso de regresión permanente (Coursiv) .

La evaluación de agentes se hace en tres capas: respuesta final, trayectoria (secuencia de pasos y tool calls) y por turno en producción (Price Per Token) . Los programas maduros trackean 5–8 métricas de trayectoria por agente (Morioh) : (1) trajectory accuracy contra trayectoria dorada; (2) tool-call precision y recall; (3) path efficiency (pasos dados vs. camino más corto); (4) cost efficiency (tokens y wall-clock por trayectoria exitosa); (5) safety refusal rate; (6) recovery success rate ante fallos inyectados; (7) HITL gate adherence —proporción de acciones consecuentes escaladas a aprobación humana, métrica audit-critical en banca regulada—; y (8) loop detection rate. El replay testing complementa los goldens: capturar trazas reales, anonimizarlas, curar un dataset de replay de 100–1.000 trazas y re-ejecutarlo contra la nueva versión y la baseline, flaggeando trayectorias que divergen materialmente; los goldens cubren edge cases curados, el replay cubre la distribución real (Morioh) .

En la práctica institucional. Kensho (S&P Global) opera un framework multi-agente sobre LangGraph para retrieval de datos financieros cuya evaluación multi-etapa se apoya en exact-match de routing y de tool-calling: la pregunta no es "¿la respuesta suena bien?" sino "¿el agente seleccionó la herramienta correcta, con los argumentos correctos, y la cifra final coincide exactamente con la referencia?" (🦜️🔗 LangChain) . La razón es estructural: un juicio de LLM sobre una cifra de riesgo es circular —el evaluador comparte los modos de fallo del evaluado—. La similitud semántica tampoco sirve: un output que cambia "EPS $0,78" por "EPS $0,81" puntúa ~0,96 de coseno siendo un defecto material (Price Per Token) . Por eso el estándar institucional reserva LLM-as-judge para cualidades no numéricas (tono, completitud) y exige exact-match —tras normalización— para routing, tool-calling y cifras.

El exact-match numérico exige normalización previa: "$1,85 billion" y "1,850 million" deben reducirse a \(1{,}85 \times 10^{9}\) antes de comparar, con una política de tolerancias explícita (exact equality, rounding, aliases, tolerance con calificadores) (Price Per Token) . La execution accuracy de FinQA/ConvFinQA ejecuta el programa de razonamiento y compara el resultado, separando errores de extracción de errores aritméticos (BenchLM) . El siguiente snippet implementa un evaluador LangSmith de exact-match numérico y uno de trayectoria:

import re
from langsmith.schemas import Example, Run

_UNITS = {"billion": 1e9, "bn": 1e9, "million": 1e6, "mn": 1e6}

def normalize_number(text: str) -> float | None:
    """'$1.85 billion' y '1,850 million' -> 1.85e9."""
    m = re.search(r"\$?\s*([\d][\d.,]*)\s*(billion|bn|million|mn)?", text.lower())
    if not m:
        return None
    val = float(m.group(1).replace(",", ""))
    return val * _UNITS.get(m.group(2) or "", 1.0)

def exact_match_numeric(run: Run, example: Example) -> dict:
    got = normalize_number(run.outputs["answer"])
    ref = normalize_number(example.outputs["answer"])
    ok = got is not None and ref is not None and abs(got - ref) <= max(1e-9, 0.001 * abs(ref))
    return {"key": "exact_match_numeric", "score": float(ok)}

def trajectory_exact_match(run: Run, example: Example) -> dict:
    """Routing + tool-calling: secuencia de tools esperada vs. real."""
    expected = example.outputs["tool_sequence"]          # p.ej. ["xbrl_facts", "calc_eps"]
    actual = [s.name for s in run.child_runs if s.run_type == "tool"]
    return {"key": "trajectory_exact_match", "score": float(actual == expected)}

La última pieza es el CI/CD de prompts: el prompt es código —versionado, revisado en PR, con quality gate automático y rollback (BenchLM) . promptfoo (OSS) mantiene casos en YAML junto al código y devuelve exit code distinto de cero si fallan las assertions, de modo que el gate de PR son dos líneas en GitHub Actions; --pass-rate-threshold 0.9 tolera el ruido de modelo sin dejar pasar regresiones reales, y guardar el output como artefacto de CI crea el audit trail de cada cambio de prompt (Price Per Token) . Braintrust ofrece una GitHub Action dedicada que corre experimentos por PR, comenta el desglose (qué casos mejoraron o empeoraron y cuánto) y bloquea el merge bajo umbral (quantvps.com) . La suite mínima de PR en finanzas: exact-match del golden numérico, tasa de abstención en preguntas no contestables, ausencia de PII en outputs y schema validation de salidas estructuradas (Price Per Token) .

# promptfooconfig.yaml — gate de PR del agente de research
prompts:
  - file://prompts/research_v4.md
providers:
  - openai:gpt-5.6-sol
tests:
  - description: "EPS diluido FY25 ACME (regresión, incidente 2026-05)"
    vars: { question: "¿Cuál fue el EPS diluido de ACME en el FY25?" }
    assert:
      - type: javascript      # exact-match numérico normalizado
        value: Math.abs(extractNumber(output) - 0.78) < 1e-6
      - type: not-contains-any   # guardarraíl PII
        value: ["SSN", "IBAN", "cuenta 4021"]

# .github/workflows/prompt-gate.yml (extracto)
- name: Prompt regression gate
  run: npx promptfoo@latest eval --no-progress-bar --pass-rate-threshold 0.9
        # exit code != 0 => el merge queda bloqueado  [(Price Per Token)](https://pricepertoken.com/pricing-page/model/openai-gpt-5) 

La evaluación humana sigue siendo el árbitro final: FinanceBench evaluó 2.400 respuestas con revisión experta manual (Coursiv) , y los LLM-as-judge deben calibrarse contra el panel humano antes de delegar en ellos cualquier puntuación offline (questdb.com) . El muestreo para revisión debe ser estratificado por tipo de tarea, con sobremuestreo de casos de alto impacto —cifras que alimentan decisiones— y revisión obligatoria de todo lo flaggeado por los guardarraíles numéricos o de PII de la sección siguiente.

11.3 Guardarraíles y seguridad operacional

11.3.1 Frameworks, grounding numérico, PII, rate limiting, circuit breakers y sandboxing

La pila de guardarraíles en finanzas es una defensa en profundidad con dos frameworks de referencia, ambos Apache 2.0 (EvoLink) . Guardrails AI aporta validación y corrección de outputs con más de 50 validadores preconstruidos (schema, rangos, formato) y una latencia añadida de 50–200 ms por validación, con ejecución paralela de validadores; NVIDIA NeMo Guardrails controla el flujo conversacional con scripting Colang, más fuerte ante jailbreak y prompt injection, con 100–300 ms típicos (50–150 ms en infra NVIDIA optimizada) por las llamadas LLM extra de reconocimiento de intención (EvoLink) . El patrón observado en 2026 es usar ambos: NeMo para topic control —el asistente no opina sobre valores fuera de mandato ni da recomendación de inversión personalizada— y Guardrails AI para validación estructural y semántica de salidas, más validadores custom de dominio: unidades, magnitudes, signos y consistencia temporal (EvoLink) .

El modo de fallo más peligroso en finanzas no es la alucinación semántica sino la sustitución numérica: texto fluido y fiel con una cifra cambiada. El caso diagnóstico documentado —fuente "EPS $0,78", output "EPS $0,81"— puntúa ~0,96 de similitud de coseno, invisible para cualquier check semántico; un detector de grounding numérico que extrae cada claim numérico del output y lo coteja contra la fuente sí lo caza (Price Per Token) . El protocolo Proof-Carrying Numbers (PCN) del Banco Mundial lleva esta idea a su forma más estricta: la verificación se mueve al renderer, no al modelo; los spans numéricos se emiten ligados a claims estructurados; el verificador aplica políticas declaradas (exact equality, rounding, aliases, tolerance) con comportamiento fail-closed —"trust is earned only by proof": solo los números verificados mecánicamente se muestran como verificados, y la ausencia de marca comunica incertidumbre—; y es anti-spoofing: el modelo no puede marcarse a sí mismo como verificado (Vibe Engines) . Su audiencia explícita es financial reporting y regulatory compliance (Vibe Engines) . La limitación conocida de estos detectores es que marcan lo computado-correcto-pero-no-citado como ungrounded; por eso el pipeline correcto es detector → revisión humana con la derivación mostrada → publicación. Un pipeline financiero documentado redujo la tasa de alucinación de ~15% (LLM solo) a ~8% (RAG) y a ~2% añadiendo fact-checking post-generación (neuraltrust.ai) .

def numeric_grounding(output: str, source: str) -> dict:
    """Verificación mecánica de cifras contra la fuente. Política fail-closed."""
    claims = extract_numeric_claims(output)                    # regex + parser de magnitudes
    src = {normalize_number(t) for t in extract_numeric_claims(source)}
    grounded = [c for c in claims if c in src]
    ungrounded = [c for c in claims if c not in src]
    return {
        "grounding_rate": len(grounded) / max(1, len(claims)),
        "ungrounded": ungrounded,
        # Fail-closed: sin verificación mecánica completa no se publica;
        # el output se marca "no verificado" y pasa a revisión humana.
        "publish": len(ungrounded) == 0,
    }

Para PII y datos sensibles, el estándar self-hosted es Microsoft Presidio (MIT): el Analyzer detecta entidades combinando regex, checksums tipo Luhn, NER y palabras de contexto; el Anonymizer aplica operadores replace/mask/hash/redact/encrypt (Meet Parse) . La estrategia de referencia para pipelines financieros es por niveles de riesgo: Critical (SSN, tarjetas, IBAN → regex estricto + checksum, donde un falso negativo tiene el mayor coste regulatorio), High (teléfonos, cuentas → regex + NER contextual), Moderate (nombres → NER transformer) y Low (fechas, IDs genéricos) (technolynx.com) . Los recognizers custom —regex + context words para identificadores internos como números de cuenta propios— son la personalización más común (Meet Parse) . Dos reglas operativas: anonimizar antes de enviar al LLM con tags funcionales que preservan estructura ([US_SSN], [IBAN]), y anonimizar las trazas de producción antes de curar datasets de replay (Morioh) . Y una advertencia honesta: la detección de entidades "fuzzy" es probabilística; Presidio es "a strong risk-reduction control, not a compliance guarantee" — exige umbrales ajustados, recognizers propios, tests con datos reales y revisión humana en casos de alto riesgo (Meet Parse) .

El rate limiting de LLMs difiere del de APIs clásicas porque el coste por request es variable: una sola petición puede costar desde una fracción de céntimo hasta varios dólares (SumatoSoft) . Limitar solo requests es un error: hay que contar tokens (input + output + system prompt) y combinar límites de requests, tokens y coste, con token bucket multi-nivel (RPM + TPM + presupuesto), estimación previa (tiktoken o heurística de ~1,3 tokens por palabra) y registro del uso real (SumatoSoft) . El rollout seguro documentado toma cinco semanas: audit-only → token bucket en la clase de workload más arriesgada → cost-velocity breaker a 10× la tasa planificada → detector de loop-signature + fallback chains → steady state con re-tuneo trimestral (AI Today Brief) .

Nota de riesgo. Un agente puede encadenar más de 12 tool calls por instrucción; si la condición de parada falla, la facturación crece sin límite. Incidente documentado: un bucle de retry de LangChain escaló de \(127/semana a **\)47.000 en 11 días antes de que nadie lo notara (análisis ZenML de más de 1.200 despliegues de producción); otro bucle compartido públicamente costó $30.000 (Dmytro Klymentiev) . Los caps de gasto del proveedor no bastan: son mensuales, no identifican qué agente causó el pico y, al saltar, matan toda la cuenta —incluidos los agentes sanos— (Dmytro Klymentiev) . La taxonomía de circuit breakers exigida en producción: (1) step limits; (2) cost limits por sesión/día; (3) repetition/loop-signature detectors** (misma herramienta con argumentos idénticos N veces en ventana corta); (4) cost-velocity breaker a 10× la tasa planificada, que caza los runaways lentos que el token bucket no ve; (5) rate-threshold breaker —10.000 tokens/min sostenidos cazó un bucle en menos de 60 segundos, porque un agente sano raramente sostiene más de 3.000–4.000 tokens/min— (AI Today Brief) . Umbrales prácticos: medir baseline dos semanas; warning a 2,5× y halt a 5× el gasto diario medio; al disparar, alerta con desglose por agente y decisión humana en menos de 5 minutos (Meet Parse) .

from langchain.agents.middleware import wrap_model_call

class CostCircuitBreaker:
    """Kill-switch de coste por agente: halt al 100% del presupuesto diario."""

    def __init__(self, daily_limit_usd: float, p_in: float, p_out: float):
        self.limit, self.p_in, self.p_out = daily_limit_usd, p_in, p_out
        self.spent, self.recent_calls = 0.0, []

    @wrap_model_call
    def guard(self, request, handler):
        if self.spent >= self.limit:
            raise RuntimeError("Kill-switch: presupuesto diario agotado")
        sig = (request.messages[-1].content[:128])               # loop-signature
        self.recent_calls.append(sig)
        if len(self.recent_calls) >= 3 and len(set(self.recent_calls[-3:])) == 1:
            raise RuntimeError("Circuit breaker: bucle detectado (3 llamadas idénticas)")
        response = handler(request)
        u = response.usage_metadata or {}
        self.spent += (u.get("input_tokens", 0) * self.p_in
                       + u.get("output_tokens", 0) * self.p_out) / 1e6
        return response

Para agentes con acceso a ejecución financiera (órdenes, pagos), la lista es más estricta: allowlist de herramientas por agente, límites de notional por operación y por sesión, doble aprobación humana para acciones irreversibles, tool calls idempotentes con requestId único para evitar duplicados en retries, y kill-switch a nivel de gateway que revoque las credenciales de herramienta, no solo que deje de llamar al LLM (Morioh) . En LangGraph esto se implementa con interrupt_before en cada nodo que ejecuta una acción irreversible (arXiv.org) . Finalmente, el sandboxing de código generado por agentes: microVMs Firecracker (E2B) o gVisor/Kata, nunca un contenedor compartido; egress de red denegado por defecto con allowlist explícita; filesystem efímero; secrets inyectados por el host, nunca en el contexto del modelo; TTLs cortos y límites de CPU/memoria/tiempo por ejecución (stockcharts.com) . LangSmith Sandboxes (GA mayo 2026) factura por segundo ($0,0576/vCPU-hr) (quantitativebrokers.com) ; E2B cobra wall-clock completo incluido idle — ojo al modelar costes a escala (portfoliometrics.net) .

11.4 Economía de tokens y latencia

11.4.1 Precios, palancas de coste, presupuestos por arquitectura y la frontera de la latencia

Los precios de API cambian con frecuencia; toda cifra de este módulo va fechada a julio de 2026 con fuente, y debe verificarse contra las páginas oficiales antes de presupuestar (Bajaj Finserv) .

Tabla 11.2 — Precios de modelos por millón de tokens (a julio de 2026)

Fuentes: BenchLM sincronizado con las páginas oficiales de OpenAI, Anthropic y Google, sync 28-jul-2026 (Bajaj Finserv) .

La lectura de la tabla es una lección de arquitectura, no de compras. A nivel flagship, Gemini 3.1 Pro cuesta menos de la mitad que GPT-5.6 Sol y Claude Opus 5, lo que reconfigura el diseño de pipelines de research de alto volumen (Bajaj Finserv) . El spread intra-proveedor es más importante aún: dentro de OpenAI, de GPT-5 nano a GPT-5.5 Pro hay un factor de 600× (Bajaj Finserv) ; mandar todo al flagship es, en la distribución típica de dificultad de producción (60–75% queries simples, 15–25% medias, 5–15% duras), un sobrepago de hasta 50× en el bucket simple (ryanoconnellfinance.com) . El contexto largo tiene tarifa premium: meter el filing completo "porque cabe" duplica el precio, y el RAG selectivo suele ser simultáneamente más barato y más preciso (Bajaj Finserv) . Los tres proveedores ofrecen Batch API con −50% en input y output para trabajo asíncrono —suites de evaluación, extracción masiva de filings, generación nocturna— y prompt caching de hasta −90% en tokens de entrada repetidos; en Anthropic ambos descuentos son stackables (un cache hit batcheado de Opus 5 cuesta $0,25/M) (John Rothe, CMT | Investment Strategy) . Una advertencia de medición: el tokenizer de Claude 4.7+ produce ~30% más tokens para el mismo texto según Anthropic — las cuentas deben rehacerse con tokens medidos del modelo real, no heredados de otro proveedor (ryanoconnellfinance.com) .

Tabla 11.3 — Palancas de reducción de coste con efecto medido

Fuentes: (metricgate.com) .

Las palancas no son excluyentes: el caso del banco de Singapur —copiloto de compliance que redujo la factura mensual de $180.000 a $71.000 (−60%) en 90 días— combinó caché en system prompt y contexto regulatorio (−47%), cascada a modelo mid-tier para queries rutinarias (−25%) y un re-ranker que refinaba el contexto RAG (−12%), todo ello con aceptación de analistas sin cambios (APILayer BlogAPILayer Blog) . Es el patrón a replicar: primero medir la distribución de dificultad del propio tráfico, luego aplicar las palancas en orden de riesgo creciente —caché y batch son conservadores, el routing toca la calidad percibida—. La advertencia metodológica clave del routing: el umbral solo tiene sentido calibrado contra una barra de calidad medida en el propio tráfico, y la calidad debe revisarse por segmento, porque un segmento pequeño de alto riesgo puede degradarse en silencio mientras el agregado apenas se mueve (DailyTickers) . En finanzas esto se traduce en una regla dura: ninguna query regulatoria, de cifras o de cliente final se ruta a un modelo barato sin un eval de exact-match que lo respalde (DailyTickers) . Complementariamente, la métrica de diseño correcta para estrategias agénticas es accuracy-per-dollar: Tree-of-Thought alcanzó la máxima accuracy en aritmética compuesta de TAT-QA pero costó 7,2× más tokens por query que Plan-and-Solve, que ofreció el mejor accuracy-per-dollar en tareas puramente numéricas (metricgate.com) .

El presupuesto de tokens convierte estas palancas en disciplina de ingeniería: estimar antes, registrar después, contar los tres tipos de tokens (input, output, system), presupuesto por sesión/agente/día con alerta al 80% y halt al 100% (SumatoSoft) . El coste por decisión de una arquitectura agéntica se modela como:

donde \(n_{\text{calls}}\) es el número de llamadas LLM por decisión, \(T_{\text{in}}\) y \(T_{\text{out}}\) los tokens medios por llamada, y \(p_{\text{in}}\), \(p_{\text{out}}\) las tarifas por millón de tokens. El factor crítico es \(n_{\text{calls}}\): un swarm de 5 agentes puede triplicar el gasto de tokens frente a un monolito sobre la misma tarea, porque cada handoff añade overhead de contexto (CSDN博客) , y un análisis estilo TradingAgents consume ~30–50 llamadas LLM por ticker (Global Database) . La fiabilidad también decae con la cadena: un pipeline de 10 pasos con 90% de fiabilidad por paso entrega solo 34,9% de éxito end-to-end (MarketXLS) .

PRECIOS = {  # $/M tokens, a jul-2026  [(Bajaj Finserv)](https://www.bajajfinserv.in/investment/maximum-drawdown) 
    "gemini-3.1-pro": (2.0, 12.0),
    "claude-sonnet-5": (2.0, 10.0),   # tarifa intro hasta 31-ago-2026
    "gpt-5.6-terra": (2.5, 15.0),
}

def coste_decision(n_calls: int, tok_in: float, tok_out: float, modelo: str) -> float:
    p_in, p_out = PRECIOS[modelo]
    return n_calls * (tok_in * p_in + tok_out * p_out) / 1e6

# Presupuesto por arquitectura (12k tok in / 2k tok out por llamada, Gemini 3.1 Pro)
ARQ = {"single": 5, "debate": 15, "swarm": 40}   # llamadas LLM por decisión  [(CSDN博客)](https://blog.csdn.net/s060403072/article/details/160055663) 
for nombre, n in ARQ.items():
    c = coste_decision(n, 12_000, 2_000, "gemini-3.1-pro")
    print(f"{nombre:8s} {c:.3f} USD/decisión -> {c * 200 * 21:,.0f} USD/mes a 200 decisiones/día")
# single  0.240 USD/decisión -> 1,008 USD/mes
# debate  0.720 USD/decisión -> 3,024 USD/mes
# swarm   1.920 USD/decisión -> 8,064 USD/mes

La figura muestra el coste mensual estimado de inferencia para las tres arquitecturas a volúmenes de 50 a 2.000 decisiones/día, con los supuestos marcados en el propio gráfico (Gemini 3.1 Pro a precios jul-2026, 12k tokens de entrada y 2k de salida por llamada, 21 días de mercado/mes, sin caché ni batch ni routing). Tres lecturas: primero, a volumen de research diario de una mesa mediana (50–200 decisiones/día) incluso el swarm completo es asequible en términos absolutos —entre $2{,}016 y $8{,}064 al mes—; segundo, el multiplicador entre arquitecturas (3× de single a debate, 8× de single a swarm, por número de llamadas) es estructural y ninguna palanca de precio lo elimina, porque actúa sobre \(n_{\text{calls}}\) y no sobre las tarifas —y es además conservador: no incluye el overhead de contexto de hasta ~3× tokens por llamada que los handoffs de un swarm arrastran (Módulo 3, §3.4); tercero, a 2.000 decisiones/día el swarm roza los $81.000 mensuales, territorio donde el routing y la caché dejan de ser opcionales.

La latencia es la otra frontera, y es la que delimita dónde pueden operar los agentes. Un turno agéntico real son 2–5 hops LLM más tool calls, lo que compone una latencia de 3–10× sobre los benchmarks de un solo modelo (CNY終極指南：一篇搞懂香港開戶、增值、大灣區消費全攻略 – CHMFIA 中港澳金融資訊交流協會) :

Las palancas, ordenadas por impacto: reducir hops; prompt caching (60–80% de los tokens de entrada de un agente son cacheables: system prompt + tool definitions); paralelizar tool calls independientes (recorta 40–60% del tiempo de turno); mezclar modelos por hop (rápido para routing, fuerte para síntesis); streaming del hop final; timeouts por componente; y medir P99, no P50 —un P50 de 2 s con P99 de 12 s significa que 1 de cada 100 usuarios tiene una mala experiencia— (CNY終極指南：一篇搞懂香港開戶、增值、大灣區消費全攻略 – CHMFIA 中港澳金融資訊交流協會) . El framework de SLO de referencia sitúa a los agentes de research en un presupuesto de hasta 30 segundos por turno, frente a <3 s para chat interactivo (CNY終極指南：一篇搞懂香港開戶、增值、大灣區消費全攻略 – CHMFIA 中港澳金融資訊交流協會) .

De aquí se deriva la frontera práctica del curso (insight I7): agentes para research, riesgo diario y reporting; determinismo para ejecución intra-día. Un agente que tarda 8–30 segundos en componer su respuesta no tiene sitio en la ruta crítica de una orden sensible al tiempo, donde la ejecución exige FSM determinista con latencias de milisegundos; en cambio, ese mismo agente es perfectamente viable —y económico, según la figura anterior— para el análisis nocturno de una watchlist, la elaboración del informe de riesgo matinal o la investigación ad-hoc de un PM. La autonomía crece hacia arriba en la pila (research → decisión), nunca hacia la ejecución; entre decisión y orden siempre hay FSM determinista, interrupt HITL y checkpointer Postgres como audit log.

c_route = (0.70 * (12_000 * 0.10 + 2_000 * 0.40)
         + 0.25 * (12_000 * 2.0  + 2_000 * 10.0)
         + 0.05 * (12_000 * 5.0  + 2_000 * 25.0)) / 1e6
# 0,70 × $0,002 + 0,25 × $0,044 + 0,05 × $0,110 = $0,0179 por llamada

EXPANDE

La frontera práctica, en un mapa

Todo el módulo converge en una sola decisión de diseño — dónde va el agente y dónde el determinismo (insight I7). Este es el mapa de esa frontera con las cifras del módulo:

Tres cosas que el mapa no muestra y conviene tener presentes al hacer los ejercicios: la fiabilidad compuesta castiga las cadenas largas (10 pasos al 90% por paso → 34,9% de éxito end-to-end), la latencia se presupuesta en P99 y no en P50 (un P50 de 2 s con P99 de 12 s es una mala experiencia para 1 de cada 100 usuarios), y la autonomía crece hacia arriba en la pila —research → decisión— nunca hacia la ejecución: entre decisión y orden siempre hay FSM determinista, interrupt HITL y checkpointer como audit log.

Ejercicios

1. Golden dataset mínimo. Construir un golden dataset de 20 queries sobre dos 10-K reales siguiendo la receta FinanceBench: estratificar en cuatro cubos (extracción de cifra puntual, cálculo derivado, multi-hop entre secciones, no contestable con el documento —al menos 3 queries de este último tipo—), con respuesta de referencia, evidencia (documento + página) y justificación del cálculo. Subirlo a LangSmith con splits base y regression y metadata de tipo de tarea. (Coursiv)

2. Evaluador exact-match. Implementar el evaluador exact_match_numeric del snippet de §11.2 con normalización de magnitudes y política de tolerancias explícita (exact / rounding / tolerance 0,1%). Validarlo con casos adversariales: "$1,85 billion" vs "1,850 million" (debe pasar) y "EPS $0,81" vs "EPS $0,78" (debe fallar). Ejecutarlo con evaluate() sobre el dataset del ejercicio 1 y comparar su veredicto con el de un evaluador LLM-as-judge sobre los mismos 20 casos: documentar las discrepancias. (Price Per Token)

3. Gate de CI de prompts. Montar la suite promptfoo del §11.2 sobre el agente de research: exact-match del golden, tasa de abstención en no contestables, ausencia de PII y schema validation. Integrarla en GitHub Actions con --pass-rate-threshold 0.9, introducir deliberadamente una regresión en el prompt (p. ej. reordenar contexto-pregunta) y demostrar que el merge queda bloqueado con el desglose en el PR. Guardar el output como artefacto de CI. (Coursiv)

4. Presupuesto de tokens por arquitectura. Con la fórmula de coste por decisión y los precios de la Tabla 11.2, presupuestar tres arquitecturas (single 5 llamadas, debate 15, swarm 40) para un desk con 200 decisiones/día, bajo dos escenarios de modelo (todo Gemini 3.1 Pro vs. routing 70/25/5 sobre Flash-Lite/Sonnet 5/Opus 5). Cuantificar el ahorro del routing, aplicar después Batch API (−50%) al 40% del volumen nocturno, y defender la arquitectura elegida con la métrica accuracy-per-dollar. (metricgate.com)

5. Circuit breakers y kill-switch. Implementar el CostCircuitBreaker del §11.3 con los cinco tipos de breaker (step, cost, loop-signature, cost-velocity, rate-threshold). Simular un runaway (tool que devuelve siempre el mismo resultado parcial) y verificar que el loop-signature detector lo detiene en menos de 3 iteraciones idénticas. Fijar los umbrales warning/halt a 2,5×/5× sobre una baseline sintética de dos semanas y redactar el runbook: alerta → desglose por agente → decisión humana en <5 minutos → revocación de credenciales de herramienta. (AI Today Brief)

Módulo 11 de 15 — LangChain para Trading Cuantitativo. Datos y versiones verificados a julio de 2026; precios y cifras de mercado sujetos a cambio. LangChain 1.3.14 / langchain-core 1.5.2.