LLM Configuration & Prompt Design
De usar LLMs por default a una práctica de equipo con contexto propio, criterio de calidad y reglas claras.
Equipos que usan LLMs a diario suelen operar sin contexto propio, sin criterio de calidad compartido y sin haber definido qué tareas conviene delegar. El resultado: outputs genéricos que el equipo termina reescribiendo porque les falta priorización, justificación y un próximo paso concreto, y confianza en el modelo en tareas donde el criterio humano es irremplazable. Este track construye la práctica del equipo: qué delegar, con qué contexto, con qué contrato de output y con qué reglas. Sin cambiar de herramienta.
Qué cambia con el track
Uso por default
- Cada chat arranca de cero — el modelo opera sin el contexto, los ejemplos ni los criterios que el equipo ya tiene.
- Los outputs describen situaciones y listan opciones sin distinguir prioridad — el equipo tiene que priorizar, justificar y definir el próximo paso por su cuenta.
- No está definido qué tareas conviene delegar y cuáles no: el modelo se usa igual para redactar un email que para decidir una inversión.
- Las recomendaciones llegan como sugerencias genéricas: el equipo tiene que agregarles justificación, estimar impacto y esfuerzo, y diseñar el test a mano.
- El equipo no tiene criterio compartido para evaluar si un output es bueno: cada persona evalúa a ojo, y lo que falla se descubre cuando ya salió.
Práctica con método
- Cada tarea recurrente tiene su context pack en el espacio de trabajo del equipo: voz de marca, benchmarks propios, datos de producto y ejemplos aprobados.
- Los outputs diagnostican el cuello de botella, priorizan por impacto y cierran con el próximo paso.
- Hay un mapa de frontera: tareas que se delegan, tareas que exigen revisión a fondo y tareas que no se delegan.
- Cada recomendación sale como ticket de trabajo: qué cambiar, por qué, impacto y esfuerzo, test y métrica.
- Hay una rúbrica de calidad versionada, un golden set de outputs reales y dos personas calibradas para evaluar; lo que no llega al umbral no sale.
Qué construye el equipo
Cada módulo produce un entregable concreto. El equipo avanza sobre su propio contexto, no sobre ejercicios genéricos.
Mapa de tareas y frontera
Inventariamos las tareas recurrentes del equipo y las clasificamos: dónde el modelo suma, dónde exige revisión a fondo y dónde no conviene delegar, como las decisiones de negocio matizadas o cualquier tarea con datos confidenciales. Para las 2–3 tareas seleccionadas, el equipo arma un golden set de outputs reales y los puntúa: ese es el punto de partida contra el que se mide el resto del track.
Mapa de frontera del equipo + golden set puntuado para 2–3 tareas
Context pack y configuración
Lo que diferencia un output genérico de uno útil es lo que el modelo sabe del negocio. Para cada tarea, el equipo arma su context pack: voz de marca, benchmarks propios, datos de producto, restricciones y 2–3 ejemplos aprobados, cargados en el espacio de trabajo de su herramienta. Sobre eso escribe la instrucción a la altitud correcta: perspectiva concreta, método de análisis, criterios de éxito y estructura de entrega, con la respuesta principal primero. Las tareas largas se parten en cadena.
2–3 context packs con su configuración, probados sobre inputs reales
Contrato de output y discernimiento
El equipo define el formato que una decisión necesita y lo exige: cada recomendación con justificación, impacto y esfuerzo estimados, test propuesto y métrica; el cierre con el próximo paso priorizado. Convierte el scoring en un activo: rúbrica versionada junto con la configuración, dos personas calibradas evaluando el mismo golden set, un paso previo de QA para los blind spots que la configuración no cubre y un umbral de "listo". Configurar mejora lo que el prompt instruye y puede dejar fuera lo que no contempla; discernir es trabajo del equipo — el modelo propone, las personas deciden.
Contrato de output + rúbrica versionada + scoring antes/después con dos evaluadores calibrados
Reglas, rutina y adopción
Lo construido se sostiene con reglas y cadencia. El equipo fija qué datos no entran al modelo, qué outputs llevan doble revisión y quién responde por cada configuración. La librería queda con responsables y versiones, con una revisión semanal de 15 minutos y una práctica deliberada de 10 horas en tareas propias durante el track. Una regla explícita evita la homogeneización: el equipo diverge primero y usa el modelo para converger. El plan de extensión define cómo se suma una tarea nueva de punta a punta.
Reglas de uso + librería con responsables + rutina semanal + plan de extensión
Dónde se aplica
Herramientas que quedan
Lo que el equipo se lleva
Práctica de LLMs operando en las tareas recurrentes del equipo
- Mapa de frontera: qué se delega, qué se revisa a fondo, qué no
- 2–3 context packs con su configuración en el espacio de trabajo del equipo
- Golden set real, rúbrica versionada y dos evaluadores calibrados
- Contrato de output, reglas de uso y librería con responsables
- Construido por el equipo del cliente, no por Infinure
- Medido sobre outputs reales: scoring antes y después con el mismo golden set
- Sin cambiar de herramienta ni sumar tooling: la cuenta y el modelo que el equipo ya usa
- El equipo sabe sumar una tarea nueva de punta a punta: frontera, contexto, contrato, rúbrica, responsable
Perfiles que más aprovechan este track
Equipos de marketing y growth
Personas que usan LLMs a diario y reescriben outputs genéricos porque la herramienta opera sin contexto propio ni criterio del equipo.
Analistas y equipos de CRM y performance
Roles que necesitan análisis con método y recomendaciones priorizadas sobre datos propios, y hoy los arman a mano después de cada chat.
Líderes de área
Sponsors que quieren un estándar compartido para el uso de LLMs en el equipo: qué se delega, qué datos no entran y quién revisa antes de que un output llegue a un cliente o a una decisión.