Las cuatro métricas que importan primero
Hay muchas métricas que puede rastrear. Cuatro merecen los asientos de primera fila.
Retraso de frescura
¿Cuánto tiempo transcurre entre la publicación de la fuente y la ingestión exitosa en su almacén canónico? Esto debe medirse por regulador, por tipo de archivo e idealmente por percentil, no solo por promedio. Un retraso medio puede parecer saludable mientras que una cola de archivos retrasados arruina silenciosamente la puntualidad.
Tasa de éxito de análisis
De los documentos candidatos descubiertos, ¿qué fracción se analiza con éxito en los campos requeridos? Realice un seguimiento por fuente y versión del analizador. Una caída repentina generalmente significa que la fuente cambió de formato, no que los "insiders" corporativos olvidaron colectivamente cómo funcionan los formularios.
Tasa de candidatos duplicados
¿Cuántos artefactos obtenidos se resuelven en identidades de documentos o eventos ya conocidos? Esta métrica ayuda a ajustar las ventanas de retrospectiva y las reglas de deduplicación. Un valor demasiado bajo puede significar que no se está reescaneando lo suficiente. Un valor demasiado alto puede significar que su programador es ruidoso o que su índice de origen es inestable.
Presupuesto de errores de origen
¿Cuántos fallos son aceptables antes de que una fuente se considere degradada? Esto incluye errores de transporte, respuestas vacías cuando se espera una no vacía y cambios estructurales. Los presupuestos de errores son útiles porque fuerzan la escalada antes de que los usuarios se conviertan en su sistema de monitoreo.
El registro debe preservar el valor forense
Los registros de aplicaciones a menudo se escriben para desarrolladores en medio de un incidente. Los registros de presentación también deben ser útiles seis meses después, cuando alguien cuestione un registro histórico.
Esto significa registros estructurados con:
- versión de origen y adaptador
- ID de ejecución del programador
- URL de la solicitud o clave de punto final
- estado de la respuesta y latencia
- suma de comprobación del artefacto en bruto
- resultado del análisis
- ID de registro canónicos emitidos
- razón de la decisión de deduplicación
Esto no es excesivo. Así es como se reconstruye lo que sucedió cuando una fuente cambió su comportamiento un lunes festivo y su analizador fingió cortésmente no darse cuenta.
Las alertas deben ser conscientes de la fuente
Una única alerta global de "falla de la tubería" es casi inútil. Le dice que algo anda mal, en algún lugar, eventualmente. Las alertas mejores son conscientes de la fuente y basadas en umbrales:
- Retraso de frescura de AMF por encima del umbral
- Éxito de análisis de SEC por debajo del umbral
- Una fuente que devuelve cero documentos durante una ventana normalmente activa
- Pico en la tasa de duplicados después de un cambio de programador
- Detección de enmiendas inusualmente baja o alta
El objetivo no es generar más alertas. Es generar menos, pero mejores. Los equipos de operaciones no necesitan más ruido. Necesitan evidencia.
El análisis sintáctico es donde la teoría se encuentra con un PDF lleno de opiniones
La discusión sobre la arquitectura puede sonar impecable hasta que el análisis sintáctico entra en escena. Entonces la situación se complica.
Las fuentes estructuradas son un regalo, no una garantía
La infraestructura de presentación electrónica de la SEC es comparativamente estructurada. Eso ayuda. No elimina la necesidad de validación, normalización y manejo de excepciones. Las presentaciones estructuradas aún contienen nombres inconsistentes, códigos de transacción de casos extremos y formularios enmendados que requieren atención.
Las fuentes europeas bajo el marco del Reglamento sobre el Abuso de Mercado pueden estar más fragmentadas operativamente porque la publicación se realiza a través de las autoridades nacionales competentes y los canales específicos de cada mercado. ESMA puede armonizar la interpretación hasta cierto punto, pero no logra que cada punto final de publicación se comporte como una API disciplinada.
Los PDF y HTML requieren una extracción defensiva
Para fuentes semiestructuradas o no estructuradas, el análisis sintáctico defensivo es importante:
- preservar el artefacto original
- extraer texto y diseño por separado cuando sea posible
- usar puntuaciones de confianza a nivel de campo
- validar contra rangos y enumeraciones esperados
- poner en cuarentena los análisis de baja confianza para revisión o publicación retrasada
A un analizador sintáctico se le debe permitir decir “no lo sé”. Los sistemas que fuerzan cada documento a un esquema completo tienden a fabricar certeza. Eso es excelente para el rendimiento y deficiente para la verdad.
Los esquemas canónicos necesitan espacio para las peculiaridades de la fuente
Un esquema común para las transacciones de iniciados suele incluir emisor, iniciado, rol, fecha de transacción, fecha de notificación, instrumento, tipo de transacción, precio, cantidad, moneda y metadatos de la fuente. Esa es la parte fácil.
Lo difícil es preservar los matices específicos de la fuente sin contaminar el modelo canónico hasta el punto de hacerlo inutilizable. Se necesitan campos de extensión o retención de la carga útil de la fuente para que los atributos inusuales no se descarten. De lo contrario, cada decisión de normalización se vuelve irreversible, y las decisiones irreversibles tomadas bajo la incertidumbre del analizador son el origen de futuras discusiones.
La gobernanza, el linaje y la repetición son lo que hacen que los datos sean invertibles
Los datos de calidad para investigación no son meramente datos que existen. Son datos cuya procedencia puede explicarse y cuyas transformaciones pueden reproducirse.
