Skip to content

README.md

Latest commit

 

History

History
44 lines (33 loc) · 4.71 KB

README.md

File metadata and controls

44 lines (33 loc) · 4.71 KB
Raw

Prueba Técnica HICAPPS

Introducción

Hola! Te damos la bienvenida a la prueba técnica para formar parte del equipo técnico de HICAPPS.

El objetivo de esta prueba es evaluar tus habilidades para diseñar, implementar y ejecutar un framework de pruebas automatizadas aplicado a la validación de LLMs. En el mundo de la IA, el software no es determinista, por lo que buscamos entender cómo afrontas el reto de testear respuestas dinámicas utilizando un enfoque de LLM-as-a-Judge (un LLM evaluando a otro LLM).

Contenido de la evaluación

El Escenario

Imagina que HICAPPS está desarrollando un asistente virtual médico para una clínica. El objetivo del chatbot es ayudar a los pacientes a consultar el estado de sus exámenes de laboratorio, explicar términos médicos complejos de forma sencilla y agendar citas de seguimiento si es necesario.

Al ser un entorno de salud, la precisión, la empatía, el manejo de la frustración y, sobre todo, la estricta privacidad de los datos médicos son fundamentales.

Para esta prueba, te proporcionaremos dos API Keys de OpenRouter con accesos restringidos:

  • API Key A (Modelo Generador): Tiene acceso exclusivo al modelo amazon/nova-lite-v1 (o similar permitido). Este modelo actuará como el asistente médico de la clínica y generará las respuestas basadas en un set de datos (prompts) que tú definirás.
  • API Key B (Modelo Evaluador / Judge): Tiene acceso exclusivo al modelo google/gemini-1.5-flash (o similar permitido). Este modelo actuará como tu "oráculo" de QA, evaluando de forma lógica si el output del Modelo A cumple con los criterios de calidad y seguridad clínica.

Tus Tareas:

  1. Diseño de Test Cases (Datasets): Crea un archivo de datos (JSON o CSV) con al menos 5 casos de prueba (Prompts de usuario). Debes incluir escenarios felices (preguntas normales sobre resultados) y escenarios negativos o de riesgo (intentos de jailbreak, insultos, o solicitudes que violen la privacidad del paciente).
  2. Automatización del Flujo: Crea un script en el lenguaje de tu elección (Python o JavaScript/TypeScript) que implemente de forma aislada ambas credenciales:
    • Conexión A: Inicializa el cliente API usando la API Key A para enviar el prompt del paciente al Modelo A (Generador) y capturar su respuesta médica.
    • Conexión B: Inicializa un cliente API independiente usando la API Key B para enviar la respuesta del Modelo A junto con un prompt estructurado al Modelo B (El Juez), solicitando su evaluación bajo los criterios definidos.
  3. Framework de Testing: Integra este flujo con un framework de pruebas (ej. PyTest para Python, o Jest/Playwright/Mocha para JavaScript). Los asserts del test deben basarse en el veredicto del Modelo B.
  4. Reportabilidad: El framework debe generar un reporte claro de qué pruebas pasaron y cuáles fallaron según el criterio del juez. Puede ser en CSV o JSON.

Instrucciones de entrega

  1. Código Fuente: Sube tu solución a un repositorio privado de GitHub/GitLab y comparte el acceso con el equipo técnico de HICAPPS (te daremos los usuarios por correo).
  2. Archivo README.md: El repositorio debe incluir un archivo de documentación con:
    • Requisitos previos e instrucciones claras de instalación y ejecución.
    • Explicación de la arquitectura/herramientas elegidas (por qué elegiste ese framework).
    • Breve análisis de cómo manejarías los falsos positivos/negativos del Modelo Juez en un entorno de producción real dentro del sector salud.
  3. Manejo de Variables de Entorno: NO dejes las API Keys hardcodeadas en el código. El proyecto debe leerlas desde un archivo .env utilizando variables como OPENROUTER_API_KEY_A y OPENROUTER_API_KEY_B. Te enviaremos estas llaves de manera segura.
  4. Plazo: Tienes un plazo de 3 días hábiles a partir de la recepción de las credenciales para entregar la prueba.

Qué y cómo medimos?

En HICAPPS no solo buscamos que el código "funcione", evaluaremos tu solución de forma cualitativa basado en parámetros como:

  • Calidad de código entregado: Organización, modularidad y buenas prácticas del lenguaje elegido.
  • Estrategia de Asserts y Manejo de Errores: Cómo parseas la respuesta del Juez para ejecutar los asserts y cómo manejas las excepciones de la API (timeouts, caídas de OpenRouter).
  • Robustez del Prompt Engineering: La claridad de las instrucciones dadas al Modelo B para que actúe como un juez consistente y estructurado (forzando formatos de respuesta estables como JSON).
  • Uso de herramientas: Correcta implementación del framework de pruebas seleccionado.
  • Capacidad de explicar y comentar adecuadamente el código: Claridad en la documentación del repositorio.