Francisco MinguezDatos e IA

Servicios

Servicios concretos de datos e IA, con alcance y límites explícitos.

Estas ofertas cubren RAG Reliability Audit, trabajo con pipelines de datos y ML o analítica aplicada. Cada una indica tipos de problema, entregables habituales, criterios de encaje y lo que queda fuera de alcance.

El alcance depende de los datos disponibles, del sistema actual, de la decisión que importa y de la evidencia necesaria para valorar el trabajo.

RAG Reliability Audit

Auditar un sistema RAG existente o un prototipo para detectar evidencia obsoleta, conflictiva o insuficiente, medir el comportamiento de respuesta indebida y de diferimiento, diseñar criterios de respuesta/diferimiento y producir recomendaciones prácticas priorizadas.

Problemas que puede abordar

  • Un prototipo RAG o un candidato a producción responde cuando la evidencia está obsoleta, en conflicto o es insuficiente.
  • La calidad de recuperación y de respuesta no se mide con criterios explícitos de precisión, cobertura y diferimiento.
  • Los equipos carecen de un conjunto de evaluación representativo o de una política clara de respuesta/abstención.
  • Las respuestas indebidas se observan de forma anecdótica, sin una taxonomía estructurada de fallos.
  • Cuesta separar problemas de modelo, de recuperación y del ciclo de vida de documentos.

Entregables habituales

  • RAG Reliability Audit del camino actual de recuperación y respuesta.
  • Hallazgos sobre conflicto, obsolescencia y suficiencia de evidencia.
  • Análisis de respuesta indebida y de diferimiento.
  • Recomendaciones de política de abstención.
  • Diseño de dataset de evaluación y métricas cuando haga falta.
  • Recomendaciones priorizadas de remediación y de piloto limitado.
  • Documentación técnica para interlocutores de ingeniería y producto.

Buen encaje

  • Existe un prototipo RAG, un corpus o un objetivo de evaluación.
  • Se pueden compartir ejemplos, documentos, logs o preguntas de prueba representativos mediante un proceso aprobado.
  • El equipo puede definir cuándo el sistema debe responder, aclarar o abstenerse.
  • Se pueden discutir abiertamente limitaciones y compromisos.

No es un buen encaje

  • Se espera calidad o corrección de respuesta garantizada sin datos representativos.
  • La petición es solo añadir un LLM sin un problema de usuario definido.
  • No se puede acceder al material fuente confidencial mediante un proceso aprobado.
  • Se requiere una certificación de cumplimiento normativo, un visto bueno legal o una auditoría de seguridad.
  • Se espera un SaaS gestionado en producción o una API pública como entregable inmediato.

Estudio sintético publicado

El estudio RAG Reliability documenta un gate de respuesta/diferimiento preregistrado sobre un holdout sintético congelado, con métricas explícitas de precisión, cobertura y respuesta indebida, y con limitaciones. Los resultados se aplican solo a ese benchmark y no afirman validación en producción.

Capacidad profesional

Experiencia diseñando y evaluando flujos de RAG, LLM y modelos multimodales en entornos profesionales. Empleador, cliente y artefactos internos de evaluación siguen siendo confidenciales.

Ver caso de estudio relacionado

Modernización de pipelines de datos y calidad

Migrar o mejorar flujos analíticos con transformaciones reproducibles, validación explícita, controles de calidad de datos y traspaso práctico.

Problemas que puede abordar

  • Un proceso recurrente SQL, SAS o ETL es lento o difícil de mantener.
  • Los problemas de calidad de datos se detectan tarde o se gestionan a mano.
  • La lógica heredada está poco documentada y es difícil de reconciliar.
  • La adopción de PySpark o Databricks carece de un plan de migración controlado.

Entregables habituales

  • Auditoría técnica del estado actual.
  • Plan de migración y reconciliación.
  • Implementación del flujo en PySpark o Databricks.
  • Componentes de transformación reutilizables y parametrizados.
  • Controles automatizados de calidad de datos y validación.
  • Documentación operativa y guía de traspaso.

Buen encaje

  • Ya existe un flujo concreto y salidas esperadas.
  • Se pueden comparar los resultados heredados y los resultados de destino.
  • Hay acceso a los datos y una responsabilidad técnica claramente asignada.
  • La organización acepta una migración por etapas con validación.

No es un buen encaje

  • Se espera sustituir toda la plataforma sin una fase de diagnóstico.
  • Nadie puede explicar las reglas de negocio existentes.
  • No se puede acceder a los datos fuente ni perfilarlos.
  • Se esperan las mismas ganancias de rendimiento que en otro caso de estudio.

Caso de estudio publicado

El caso de estudio de modernización de pipeline analítico documenta la migración verificada, componentes PySpark reutilizables, controles de calidad automatizados y el cambio reportado de semanas a aproximadamente dos horas.

Ver caso de estudio relacionado

ML aplicado, NLP y analítica para decisiones

Desarrollar flujos analíticos o de machine learning que conecten un problema de decisión definido con preparación de datos, evaluación y salidas utilizables.

Problemas que puede abordar

  • Un problema de predicción, priorización, segmentación o automatización carece de una línea base estructurada.
  • La revisión manual de documentos o analítica es difícil de escalar.
  • Las métricas de negocio y las salidas del modelo están desconectadas.
  • Los interlocutores necesitan análisis listo para decidir, no un notebook aislado.

Entregables habituales

  • Encuadre del problema y definición de línea base.
  • Análisis exploratorio y diagnóstico de datos.
  • Flujo de modelado predictivo, NLP o segmentación.
  • Diseño de evaluación y análisis de errores.
  • Salidas u reporting orientados a la decisión.
  • Documentación técnica y material de comunicación para interlocutores.

Buen encaje

  • Se puede describir una decisión concreta o un flujo operativo.
  • Existen datos históricos o etiquetados representativos.
  • Se puede acordar una línea base y un criterio de evaluación.
  • El resultado puede revisarse con interlocutores técnicos y de negocio.

No es un buen encaje

  • Se solicita un modelo antes de definir el problema de decisión.
  • Se exige un rendimiento de predicción garantizado.
  • Los datos disponibles no pueden respaldar legal o éticamente el uso propuesto.
  • Se espera que un dashboard por sí solo resuelva la propiedad o calidad de datos poco clara.

Capacidad profesional

Experiencia en clasificación, regresión, clustering, NLP, analítica, automatización de reporting y entrega orientada a interlocutores en entornos profesionales. Los artefactos específicos de la organización siguen siendo confidenciales.

Cómo puede empezar un encargo

  1. 01

    Diagnóstico acotado

    Una revisión limitada del problema, los datos, el sistema y la evidencia actuales, que termina en hallazgos y un plan priorizado de siguientes pasos.

  2. 02

    Implementación de alcance fijo

    Un incremento definido de construcción o migración con entradas, salidas, criterios de aceptación, validación y traspaso acordados.

  3. 03

    Apoyo externo integrado

    Contribución a tiempo parcial o por plazo fijo dentro de un equipo existente de datos, IA, analítica o producto, con responsabilidades y límites de comunicación claramente definidos.

Información útil antes de la primera conversación

  • El flujo, sistema o prototipo actual.
  • La decisión o el proceso que hay que mejorar.
  • Datos, documentos, logs o ejemplos disponibles.
  • Línea base, métricas o salidas esperadas existentes.
  • Restricciones técnicas, de seguridad y de confidencialidad.
  • Interlocutores que evaluarán u operarán el resultado.

Lo que este portfolio no promete

  • Resultados de modelo o de negocio garantizados.
  • Preparación para producción sin evaluación técnica y operativa.
  • Certificación de seguridad o de cumplimiento normativo.
  • Resultados idénticos con datos, sistemas u organizaciones diferentes.
  • Una implementación centrada en la herramienta sin un problema definido y un enfoque de evaluación.

Empieza por el problema y la evidencia disponible.

Un primer mensaje útil explica qué existe hoy, qué hay que mejorar, quién usará el resultado y qué restricciones importan.

Hablar de un proyecto