Fantasy Copilot

El problema

Antes de cada jornada, los analistas de LaLiga Fantasy publican en YouTube horas de vídeo con sus recomendaciones. Verlo todo para decidir un once no es viable, y lo que sirve está repartido entre vídeos y canales. Además, los subtítulos automáticos deforman los nombres de los jugadores, así que el texto tampoco se puede usar tal cual.

Qué hice yo

Es un proyecto personal: el diseño y todo el código son míos. Lo empecé dentro de un programa de Ingeniería de IA y lo mantengo en abierto.

• Construí el pipeline completo: descubrimiento de los vídeos de la jornada, descarga de transcripciones, limpieza y troceado, extracción de recomendaciones por jugador, normalización de nombres e indexación en una base de datos vectorial.
• Implementé el agente que, con la plantilla del usuario, resume lo que se dice de cada jugador y propone un once.
• Añadí un chat que responde preguntas sobre la jornada con RAG (recuperación de información para dar contexto al modelo) y function calling.

Decisiones clave

Extraer datos estructurados en lugar de indexar la transcripción

Lo habitual en un RAG es trocear el texto e indexarlo tal cual. Aquí un mismo fragmento habla de varios jugadores, y la pregunta casi siempre es por uno. Por eso el modelo extrae antes una recomendación por jugador, con su acción (alinear o evitar), su confianza, el motivo y la cita del analista, usando structured outputs. Lo que se indexa son esas recomendaciones, no el texto en bruto.

Normalizar los nombres contra la lista oficial y descartar en caso de duda

Los subtítulos escriben «Chamenamení» donde el analista dice Tchouaméni. Cada nombre se compara con la lista oficial de jugadores mediante coincidencia aproximada, y el modelo decide entre los candidatos con function calling. Si no hay certeza, la recomendación se elimina: atribuirla a otro jugador estropea el once sin que se note, y perderla solo deja un hueco visible.

Guardar el resultado de cada etapa

Cada etapa deja su salida en un fichero que la siguiente lee, y no se repite si el fichero ya existe. Frente a ejecutarlo todo de principio a fin, permite retocar una etapa sin volver a pagar las llamadas al modelo ni volver a descargar las transcripciones.

Medir antes de reescribir

El prototipo vive en un notebook y lo estoy convirtiendo en un servicio. En lugar de empezar por las mejoras de calidad, el primer paso es una línea base con datos etiquetados: sin ella no se puede saber si un cambio mejora o empeora la recomendación.

Resultado

• A partir de los vídeos de una jornada, el sistema propone un once para la plantilla del usuario y responde preguntas en un chat.
• El repositorio incluye el código, la documentación de cada etapa con sus errores conocidos y el plan de trabajo por issues y milestones.
• El siguiente paso es convertir el notebook en un paquete de Python con tests y evaluación, y después añadir persistencia, una API y trazas.