Propuestas de proyecto · LLM Engineer Club

Cinco proyectos listos para adoptar. Los cinco cumplen los requisitos del capstone (corpus con volumen suficiente para que el RAG tenga mérito, un agente cuyas herramientas no sean decorativas, y un caso de uso que da juego en la defensa). Elige por afinidad con el dominio: vas a pasar 6 semanas dentro.

Criterio común de tamaño de corpus: entre 200 y 2.000 documentos-fuente (o 1.000–20.000 chunks). Menos, y el retrieval es trivial (un grep serviría); más, y la ingestión se come el calendario.

1. Asistente de normativa técnica — "¿Cumple mi proyecto el CTE?"#

Dominio. Consultas sobre el Código Técnico de la Edificación español (o un cuerpo normativo equivalente: RGPD + AEPD, normativa de tráfico, convenios colectivos de un sector).

Corpus. Los Documentos Básicos del CTE son PDFs públicos, largos (varios cientos de páginas cada uno), con tablas, fórmulas y referencias cruzadas entre secciones. Es un corpus difícil en el sentido correcto: pondrá a prueba tu extracción de PDF, el chunking de tablas y el manejo de referencias ("según se establece en el DB-SI 3, apartado 4").

Herramientas del agente.

buscar_normativa(query, documento_basico?) — retrieval sobre el índice, con filtro opcional por DB.
calcular(expresion, contexto) — evaluador de fórmulas normativas (ocupación, recorridos de evacuación, dotación mínima de aseos) con las constantes de la norma; obliga al agente a decidir cuándo la respuesta requiere cálculo y no solo cita.
verificar_vigencia(seccion) — consulta contra una tabla de modificaciones/derogaciones que tú mantienes (los DB tienen versiones); enseña al agente a no responder con normativa derogada.

Por qué es buen capstone. El dominio castiga las alucinaciones de forma visible (citar un artículo inexistente es un fallo objetivo, no de gusto), lo que hace que faithfulness sea la métrica estrella y da material excelente para la defensa. El dataset de evaluación se construye bien: preguntas con respuesta literal en la norma.

Riesgo a vigilar. La extracción de tablas de PDF puede comerse la semana 2. Haz un spike de extracción con 3 documentos antes de comprometerte; si Docling/unstructured no sacan las tablas decentemente, cambia a un cuerpo normativo en HTML (BOE consolidado).

2. Copiloto de soporte sobre documentación de producto real#

Dominio. Soporte técnico nivel 1–2 sobre la documentación pública de un producto software concreto (elige uno con docs grandes y buenas: PostgreSQL, Kubernetes, Stripe, Terraform, Home Assistant).

Corpus. La documentación oficial completa, rastreada e ingerida (Markdown/HTML, mucho código embebido). Entre 500 y 2.000 páginas según el producto. El chunking de bloques de código junto a su prosa es el reto técnico diferencial.

Herramientas del agente.

buscar_docs(query, version?) — retrieval con filtro por versión del producto (las respuestas válidas para PG 16 pueden ser erróneas en PG 12).
ejecutar_snippet(codigo) — sandbox (contenedor efímero o servicio tipo Piston) donde el agente valida que el ejemplo que va a dar realmente funciona; es la herramienta que más impresiona en demo.
buscar_issues(query) — búsqueda en los issues de GitHub del producto vía API, para preguntas del tipo "¿es un bug conocido?".

Por qué es buen capstone. Es el caso de uso más contratable del mercado (todo SaaS quiere esto) y permite comparar tus respuestas contra una fuente de verdad externa: las respuestas aceptadas de Stack Overflow sobre el mismo producto sirven para validar tu dataset de evaluación.

Riesgo a vigilar. ejecutar_snippet es un vector de seguridad real: sandbox obligatorio, timeout, sin red. Si no vas a hacerlo bien, sustitúyela por validar_config(fichero) (lint estático de configuración), que es más segura y sigue siendo útil.

3. Analista de expedientes de contratación pública#

Dominio. Preguntas sobre licitaciones públicas: "¿qué solvencia técnica piden?", "¿cuál es el criterio de adjudicación con más peso?", "compárame estos dos pliegos".

Corpus. Pliegos (PCAP y PPT) descargados de la Plataforma de Contratación del Sector Público, filtrados por un sector (p. ej. servicios TI). 200–500 expedientes, cada uno con 2–4 PDFs. Datos públicos, cero problema legal.

Herramientas del agente.

buscar_pliegos(query, filtros) — retrieval con metadatos (órgano, importe, CPV, fecha).
extraer_estructurado(expediente_id) — extracción con structured outputs (Pydantic) de los campos clave del pliego: presupuesto, plazos, criterios y pesos, solvencia. Conecta directamente con lo aprendido en el módulo 2.
comparar_expedientes(ids) — genera una tabla comparativa a partir de las extracciones estructuradas; herramienta de composición, no de retrieval, lo que demuestra orquestación real.

Por qué es buen capstone. Combina RAG con extracción estructurada (dos disciplinas evaluables por separado), el usuario objetivo es clarísimo (empresas que licitan) y el análisis de costes tiene una narrativa de negocio natural: cada pliego analizado a mano cuesta horas de un técnico.

Riesgo a vigilar. Heterogeneidad brutal entre pliegos (cada órgano escribe el suyo). Acótalo: un solo tipo de contrato y un solo sector. La homogeneidad del corpus es tu amiga en 6 semanas.

4. Segundo cerebro médico-deportivo sobre literatura de entrenamiento#

Dominio. Preguntas sobre evidencia en ciencias del deporte y nutrición: "¿qué dice la evidencia sobre entrenar en ayunas?", "dosis de creatina con respaldo".

Corpus. Abstracts y papers en abierto de PubMed Central sobre un subcampo acotado (p. ej. entrenamiento de fuerza + suplementación), 500–1.500 papers. La API de PubMed hace la ingestión programática y reproducible.

Herramientas del agente.

buscar_evidencia(query, tipo_estudio?) — retrieval con filtro por tipo (RCT, metaanálisis, observacional).
evaluar_calidad(paper_id) — devuelve señales de calidad del estudio (n, tipo, año, si es metaanálisis) desde metadatos que indexaste; el agente debe ponderar la evidencia, no solo citarla.
buscar_pubmed_reciente(query) — consulta en vivo a la API de PubMed para literatura posterior a tu corte de ingestión; demuestra la combinación índice-propio + fuente-viva, un patrón de arquitectura muy defendible.

Por qué es buen capstone. Obliga a un guardrail serio y demostrable: el sistema debe negarse a dar consejo médico personalizado y ceñirse a resumir evidencia con citas. Ese guardrail, atacado en demo con prompts adversarios, es oro para la defensa. Además, faithfulness sobre literatura científica es un caso de evaluación muy limpio.

Riesgo a vigilar. La tentación de que el agente "recomiende". Define la frontera exacta (informar sí, prescribir no) en un ADR y testéala con un dataset de prompts adversarios desde la semana 3.

5. Ingeniero de guardia junior — asistente de runbooks e incidentes#

Dominio. Asistente de on-call sobre la documentación operativa de una infraestructura: "Redis está a 95% de memoria, ¿qué hago?", "¿qué servicios dependen del gateway de pagos?".

Corpus. Si tienes acceso a runbooks reales (anonimizados), perfecto. Si no: genera un corpus sintético-realista de una empresa ficticia (40–60 runbooks, 30 postmortems, docs de arquitectura de 15–20 servicios) usando un LLM con revisión manual tuya, y decláralo abiertamente. Un corpus sintético bien construido y documentado es defendible; uno improvisado, no.

Herramientas del agente.

buscar_runbooks(query, servicio?) — retrieval sobre runbooks y postmortems.
estado_servicio(nombre) — consulta métricas en vivo de una infraestructura de juguete que tú despliegas (2–3 contenedores con Prometheus); permite demos espectaculares: rompes un servicio en vivo y el agente lo diagnostica.
crear_incidente(resumen, severidad) — abre un issue en GitHub con la plantilla de incidente rellenada; herramienta de escritura con confirmación humana, lo que te obliga a implementar human-in-the-loop de verdad.

Por qué es buen capstone. Es el único de los cinco donde el agente actúa sobre el mundo (no solo lee), así que el manejo de errores, los permisos por herramienta y el human-in-the-loop dejan de ser teoría. La demo con incidente en vivo es la más memorable de las cinco propuestas.

Riesgo a vigilar. Doble despliegue (el sistema del capstone + la infra de juguete monitorizada). Mantén la infra de juguete mínima: docker-compose con 3 servicios en la misma VM barata basta.

¿Prefieres proponer tu propio proyecto?#

Adelante, suele salir mejor si el dominio es tuyo. Debe pasar este filtro antes de la semana 1 (respóndelo por escrito; es la primera página de tu documento de arquitectura):

Corpus: ¿existe ya, es legal usarlo, y está en la banda 200–2.000 documentos? Si tienes que fabricarlo, ¿cabe fabricarlo bien en menos de una semana?
Mérito del retrieval: ¿hay preguntas cuya respuesta exige combinar o localizar información no trivial? Si toda pregunta se responde con el primer resultado de una búsqueda por palabras clave, el RAG no lucirá.
Tres herramientas con papeles distintos: como mínimo una de retrieval, una de cómputo/transformación y una de acción o fuente externa viva. Tres variantes de búsqueda no cuentan como tres herramientas.
Evaluación objetiva: ¿puedes escribir 50 preguntas con respuesta de referencia verificable contra el corpus? Si la calidad de las respuestas es cuestión de opinión, RAGAS no te va a salvar.
Usuario nombrable: ¿puedes decir en una frase quién lo usaría y qué le cuesta hoy no tenerlo? (Lo necesitarás para el análisis de costes y para la defensa.)
Demo en 20 minutos: ¿el caso de uso se entiende sin explicar 10 minutos de contexto de dominio?

Si dudas entre dos, elige la de corpus más aburrido y herramientas más claras. Los capstones mueren por corpus exóticos, no por dominios sosos.