El método de doble vía
Cada informe de Clave se estructura alrededor de una sola pregunta: ¿cuál es la distancia entre lo que un actor declara públicamente y lo que verificablemente hace? Ese gap — puntuado de 0 a 10 por dominio — es donde se genera el riesgo geopolítico y donde ocurre la mala valoración del mercado.
Cómo se produce un informe
Cada informe de Clave se produce mediante un pipeline híbrido: recuperación y generación automatizadas, seguidas de revisión editorial humana. Lo declaramos explícitamente porque la transparencia sobre el método es parte de la credibilidad.
El pipeline
1. Recuperación — RAG sobre un corpus curado. Una base vectorial que indexa aproximadamente 11.000 fragmentos en más de 50 documentos fuente (Informes Anuales de la NATO, IMF World Economic Outlook, IEA WEO, BIS, Stanford HAI AI Index, investigaciones de red de ENTSO-E, textos regulatorios de la UE, briefings de defensa industrial de EPRS / MERICS / Carnegie / Bruegel / Atlantic Council / CSIS, USGS Mineral Commodity Summaries, Cochilco, gacetas de MOFCOM, entre otros) se consulta para encontrar evidencia relevante por tema. Los fragmentos mejor recuperados se convierten en contexto para la siguiente capa.
2. Generación — API de LLM frontera con un prompt editorial versionado. Los fragmentos del corpus recuperados más un prompt editorial estructurado — que define la estructura del informe ejecutivo, las secciones de doble vía, los escenarios, las predicciones formales y las convenciones de etiquetado de fuente — se envían a una API de modelo grande de lenguaje de un proveedor externo. El prompt está versionado en git y se refina con cada lección por informe; hoy contiene un conjunto versionado de reglas editoriales — entre ellas: cada informe debe contener predicciones falsables, debe articular su contribución primaria, y el encuadre estructural sigue prioridades de inversor europeo. El modelo escribe el borrador en prosa en inglés y español.
3. Aseguramiento de calidad — seis capas, heurísticas por diseño. La veracidad se aborda en capas, no en un único disparo. Cada capa atiende a un modo de fallo distinto y cada una tiene varianza medible:
- Capa 1 — heurística de contrato de cita. Una verificación automática sobre afirmaciones numéricas sustantivas comprueba que cada una lleve una etiqueta de fuente adyacente. Se dispara como advertencia cuando el conteo de afirmaciones no citadas supera el umbral.
- Capa 2 — integridad de URL. Cada URL citada se sondea con HEAD para verificar accesibilidad.
- Capa 3 — LLM-judge. La capa de judge evalúa cada borrador contra un pequeño conjunto nombrado de criterios estructurales — entre ellos si la tesis central está articulada, si la lógica de secuenciación se sostiene, si las predicciones son falsables, si la voz es neutral, y si el análisis es defensible frente a output genérico de LLM. Algunos criterios bloquean publicación; otros se exponen como advertencias durante calibración. Cada veredicto se registra en un ledger público con razonamiento y confianza. La capa LLM-judge tiene varianza medible — el mismo borrador puede puntuar de forma distinta en ejecuciones consecutivas — y la tratamos como heurística con telemetría, no como gate determinista.
- Capa 4 — verificación externa por afirmación. Las afirmaciones numéricas se buscan contra fuentes externas en el momento de promover, con el LLM-judge corroborando proximidad numérica. El runner aplica criterios de bloqueo más estrictos al contenido de alto riesgo (verdict box, predicciones formales) que al análisis de soporte.
- Capa 5 — registro de hechos críticos. Un registro curado de hechos donde informes anteriores han mostrado deriva — incluyendo umbrales y cronologías que recurren entre temas. Cada entrada lleva patrones prohibidos y guardas de contexto; las coincidencias bloquean publicación.
- Capa 6 — retrospectiva semanal. Un agente programado lee cada fallo de calidad de la semana, agrupa patrones y recomienda nuevas reglas de prompt o entradas de registro. Los informes aterrizan en el directorio público de reportes; el humano revisa — no hay auto-aplicación.
El runner aplica mecánicamente múltiples capas de controles bloqueantes y de advertencia en cada borrador. Los borradores que pasan aterrizan en staging. El editor humano revisa entonces cada informe antes de promover staging → published: lee el resumen ejecutivo entero, verifica las cifras más importantes contra fuentes primarias, confirma que las predicciones son falsables, firma.
Honestidad sobre los límites
Los modelos grandes de lenguaje pueden alucinar — inventar cifras concretas, atribuir afirmaciones a fuentes que no las hicieron, o desalinear fechas. La pila de calidad de seis capas captura la mayor parte de esto. Algo se escapa. La capa LLM-judge en particular tiene varianza medible: cuando el mismo borrador se juzga varias veces, los veredictos pueden variar, por lo que publicamos el ledger de veredictos y tratamos el gate como heurística con telemetría en lugar de pass/fail determinista. Cuando algo se escapa, publicamos una errata sobre el informe afectado y registramos el incidente; las correcciones pasadas son visibles en el historial de git de /briefs/.
El mecanismo duradero de credibilidad no es la pila de gates — los gates son andamiaje necesario — sino el ledger público de predicciones, donde cada umbral observable que publicamos se rastrea contra su resultado y el Brier score acumulado se calcula a medida que las predicciones se resuelven. Un lector que quiera evaluar esta publicación debería mirar el ledger, no el número de gates.
Declaramos el pipeline no como disculpa sino como contrato: la automatización en capas aporta consistencia y cobertura a escala que ningún analista individual puede igualar; el revisor humano aporta juicio de dominio y rendición de cuentas que ningún modelo puede aportar; y el ledger de predicciones aporta la única credencial que no se puede fabricar — el marcador público de aciertos pasados. Para los decisores institucionales, este marcador junto con el ledger público de veredictos y el CHANGELOG constituyen el rastro de evidencia para decisiones: los artefactos que hacen defendible la dependencia analítica frente a LPs, consejos y auditorías.
Jerarquía de fuentes
Cada afirmación factual en un informe de Clave lleva una etiqueta de fuente estructurada adyacente a la afirmación — antes de la puntuación de cierre de la frase. La etiqueta permite la verificación post-publicación sin mediación editorial. Las fuentes se ponderan en este orden de prioridad:
- Corpus autoritativo. Documentos primarios indexados — BIS, IMF, NATO, IEA, ENTSO-E, OECD, publicaciones de bancos centrales, registros de reguladores, gacetas oficiales. Mayor peso. Citados en línea como
[SOURCE | DOC | PAGE]. - Fuentes web de autoridad. Sitios oficiales de reguladores y actores primarios consultados en la fecha del análisis — DG COMP / EUR-Lex, La Moncloa, BOE, Bundesanzeiger, MOFCOM, Federal Register, etc. Citados como
[WEB: fuente]con URL. - Prensa financiera Tier-1. FT, Reuters, Bloomberg, Wall Street Journal — cuando adelantan un desarrollo regulatorio o corporativo antes de la publicación primaria. Citados como
[WEB: medio]con URL. - Datos de encuestas. Encuestadora nombrada, fecha nombrada, metodología verificada cuando es ambigua. Citados como
[POLL: encuestadora]. - Inferencia a partir de las anteriores. Juicio del analista derivado de las capas superiores. Menor autoridad. Citada como
[INFERENCE: based on X + Y]con la base nombrada explícitamente. Una etiqueta[INFERENCE]sin base declarada es rechazada por el runner.
El runner aplica un límite máximo a la proporción de afirmaciones etiquetadas como inferencia respecto al total de números-ancla. Si la proporción supera el umbral, el informe no puede promover — un análisis dominado por inferencia es estructuralmente indistinguible de comentario, y mantenemos la línea sobre esa diferencia.
Etiquetas de fuente
Una afirmación etiquetada [INFERENCE] es el juicio del analista — puede estar equivocada. Una afirmación etiquetada [WEB] con URL puede verificarse en 30 segundos. El sistema de etiquetado existe para que los lectores puedan cuestionar cada afirmación de forma independiente.
Transparencia
Cada capa descrita arriba es verificable. El código fuente del runner y los judges, el registro de veredictos que registra cada decisión de gate, el registro de predicciones con fechas de falsabilidad, y el CHANGELOG con cada cambio metodológico están servidos desde el endpoint público de archivos del sitio en /api/file/<ruta> (manifiesto completo en /api/files). Los recibos son la credencial. Ver Acerca → Lo que es público para la lista completa y la lista (más corta) de lo que es deliberadamente no público.
Historial de predicciones
Cada umbral observable publicado en un informe de Clave se rastrea contra resultados. Para los primeros informes — el inicio de esta serie — no existen predicciones previas que verificar. A medida que la serie se desarrolla, esta sección acumulará tanto predicciones verificadas como fallidas. Ambas se publican.
El registro también es un canal de retroalimentación. Cuando una clase de predicciones falla sistemáticamente — tres o más fallos con una característica común, no ruido — se examina la causa y se aplica una de cuatro correcciones: se revisa una regla del prompt editorial, se añade una entrada al registro de hechos críticos, la clase de predicción se retira por no ser falsable en la forma previamente usada, o el gate que debería haberlo detectado se recalibra. Sin tuning automático; cada ajuste es revisado por el editor y fechado. El CHANGELOG público registra cada modificación, de modo que los lectores pueden verificar que las mejoras siguieron a los fallos, no los precedieron.