Enseñarle a un Modelo a Razonar Sobre Negocios, No Solo a Hablar de Ellos
Resumen
La gente me pregunta si entrené mi propio modelo para negocios. La respuesta honesta es más interesante que un sí o un no: lo difícil de un LLM de negocios no es la escala, es el criterio. Un modelo general escribe una respuesta hermosa, segura y genérica. El razonamiento de negocios necesita consistencia, evidencia y rendición de cuentas que la fluidez por sí sola no da. La palanca está en especializar con estructura — darle al modelo una forma disciplinada y repetible de descomponer un problema de negocio — fundamentar cada afirmación en evidencia de origen, enseñarle desde ejemplos validados por expertos en lugar de la web abierta, y evaluarlo contra el criterio experto en lugar de benchmarks genéricos. Dejo a propósito los internos propietarios fuera de esto — lo que sigue es la metodología, no el motor.
Algunas veces al mes, alguien me pregunta alguna versión de: "¿Entrenaste tu propio modelo?" Quieren un sí o un no. La respuesta honesta es más interesante que cualquiera de los dos, y es la parte de la que sí puedo hablar sin entrar en nada propietario.
Lo difícil de construir un LLM especializado en negocios no es la escala. Es el criterio. Y casi todo lo que he aprendido haciéndolo regresa a un hecho incómodo: un modelo que suena como si entendiera de negocios no es lo mismo que un modelo que de verdad razona sobre ellos.
Déjame compartir algunas cosas — la metodología, no el motor.
La Fluidez No Es Criterio
Pídele a cualquier modelo general moderno que analice una empresa y obtendrás algo que se lee hermoso. Prosa nítida, estructura segura, el vocabulario correcto. Parece experiencia.
Luego hazle la misma pregunta dos veces y míralo darte dos respuestas distintas. Pregúntale qué partes están fundamentadas en los documentos que le diste y cuáles inventó para llenar el hueco, y no puede decírtelo. Pídele comparar dos empresas en los mismos términos, y los términos cambian silenciosamente entre una y otra.
La Trampa de la Confianza
El output más peligroso en la IA de negocios no es una respuesta incorrecta — es una respuesta incorrecta fluida. La fluidez se lee como competencia. Un párrafo pulido pero sutilmente sin fundamento terminará pegado en una presentación de directorio antes de que alguien verifique si de verdad es cierto.
La fluidez hoy es lo mínimo. También es un disfraz. Sobre estos outputs se toman decisiones de negocio — inversiones, contrataciones, reestructuraciones — y una respuesta genérica hermosa que cambia de forma cada vez que preguntas no es algo sobre lo que puedas construir una decisión. Todo el trabajo de la especialización es convertir lo fluido en lo responsable.
Especializa Con Estructura, No Solo Con Más Texto
El instinto que tiene la mayoría es "dale más texto de negocios". Más reportes, más casos de estudio, más documentos. Eso ayuda un poco y pierde el punto.
Lo que de verdad mueve la aguja es darle al modelo una forma disciplinada y repetible de pensar — una manera estructurada de descomponer cualquier situación de negocio en las mismas dimensiones, cada vez, para que su razonamiento sea consistente y comparable en lugar de basado en intuición. La estructura es lo que convierte a un escritor ingenioso en un analista confiable.
Modelo general Modelo especializado
────────────── ────────────────────
"Aquí va una opinión → "Aquí está esta situación,
reflexiva" descompuesta igual
• distinta cada vez cada vez
• sin dimensiones fijas • dimensiones estables
• no compara A vs B • comparable entre entidades
• suena bien • muestra su razonamiento"
Soy deliberadamente abstracto sobre cuál estructura — esa parte no me toca publicarla. Pero el principio es general y vale decirlo en voz alta: para el razonamiento de dominio, un marco consistente le gana a una pila más grande de texto. El marco es lo que hace que dos análisis de dos empresas distintas signifiquen de verdad lo mismo. Sin él, tienes a un practicante muy articulado que reinventa su método en cada tarea.
Fundamenta Cada Afirmación en Evidencia
Esta es la regla con la que soy más estricto. En un contexto de negocios, una afirmación sin respaldo no solo está mal — es un pasivo. Así que el modelo se sostiene contra un estándar simple: di lo que la evidencia respalda, marca lo que inferiste, y admite lo que no sabes.
Eso significa que cada declaración significativa rastrea de vuelta a una fuente. Significa distinguir entre "esto está en los documentos", "esto es una inferencia razonable" y "no tenemos suficiente para decirlo". Y significa que al modelo se le permite — se le incentiva — regresar con un "no hay suficiente aquí para responder eso de forma responsable."
Tres Niveles, Siempre Visibles
Fundamentado, inferido, desconocido. Cada afirmación lleva su nivel. Un lector nunca debería tener que adivinar si un número vino de un documento o de la imaginación del modelo — el sistema se lo dice, cada vez. Escribí más sobre por qué esto importa en Cuándo el Modelo Debería Decir "No Sé".
Un modelo que farolea con confianza es peor que ningún modelo en este dominio, porque gasta tu confianza más rápido de lo que la gana. Negarse a adivinar es una característica, no una limitación.
Enséñale Desde la Experiencia, No Desde la Web Abierta
El internet abierto es un buen maestro para la fluidez general y un pésimo maestro para el criterio especializado. La web está llena de escritura de negocios que es genérica, contradictoria o simplemente incorrecta. Si quieres que un modelo razone como un operador con experiencia, tienes que enseñarle desde material que de verdad refleje cómo razonan los operadores con experiencia.
Eso significa ejemplos curados y validados por expertos — no texto raspado de la web — y escenarios estructurados construidos deliberadamente para ejercitar los tipos de razonamiento que el dominio exige. La meta no es memorizar respuestas. Es destilar una forma de pensar: las preguntas que un experto hace, el orden en que las hace, la evidencia que exige antes de comprometerse con una conclusión. Bien hecho, obtienes esa disciplina aplicada de forma consistente a una escala que ningún humano solo podría cubrir.
El Conjunto de Evaluación Es la Especificación
Aquí está la parte que sorprende a la gente: el artefacto más valioso de todo el esfuerzo no es el modelo. Es el conjunto de evaluación.
Porque "buen razonamiento de negocios" es difuso hasta que lo haces concreto, y la forma de hacerlo concreto es recolectando ejemplos — situaciones reales, con el criterio que un experto de verdad aplicaría — y tratando esa colección como la especificación. Cada cambio de prompt, cada ajuste, se mide contra ella. No contra benchmarks públicos genéricos que no tienen nada que ver con el dominio. Contra el criterio de tus expertos, codificado como ejemplos.
Los Ejemplos Son el Contrato
Una especificación escrita en prosa queda abierta a interpretación. Una especificación escrita como unos cientos de ejemplos trabajados, no. El conjunto de evaluación es el contrato entre lo que los expertos quieren decir con 'correcto' y lo que el sistema de verdad hace. Profundizo en esta idea en El Conjunto de Evaluación Es la Especificación.
Mantén un Humano en el Bucle, y Mantenlo Auditable
El último principio es el que me deja dormir. Especializado o no, el modelo produce borradores y evaluaciones — no tiene la última palabra en nada que importe. Hay un humano en el bucle sobre el output consecuente, y hay un rastro: qué evidencia se usó, qué se infirió, sobre qué estuvo incierto el modelo. Si alguien pregunta "¿por qué concluyó eso?", la respuesta existe y puede inspeccionarse.
Esa auditabilidad no es burocracia. En los negocios — como en la salud, donde aprendí la lección por las malas — poder reconstruir por qué el sistema dijo lo que dijo es la diferencia entre una herramienta en la que la gente confía y una herramienta que la gente deja de usar en silencio.
Lo Que de Verdad Estoy Construyendo
Entonces, ¿entrené mi propio modelo? El encuadre que prefiero: estoy enseñándole a un modelo a razonar sobre negocios con la disciplina de un buen analista y la humildad de uno bueno — consistente cada vez, fundamentado en evidencia, honesto sobre sus límites, y siempre mostrando su trabajo.
El motor que lo hace funcionar es historia para otro día, y partes de él no me toca contarlas. Pero la filosofía no es ningún secreto, y creo que es la parte que de verdad importa: en un dominio serio, no ganas construyendo un modelo que lo sepa todo. Ganas construyendo uno que razone sobre tu dominio de la misma forma cuidadosa, cada vez — y que lo pueda demostrar.
Frequently Asked Questions
Artículos Relacionados
El Eval Set Es la Especificación
Para una feature de LLM, tu eval set codifica qué significa 'correcto' con más precisión que cualquier doc de producto. Cómo construir uno a partir de fallas reales, mantenerlo adversarial, versionarlo como verdad de producto, y dejar que él — no las opiniones — guíe cada cambio de prompt y modelo.
Cuándo el Modelo Debería Decir 'No Sé'
La incertidumbre calibrada como requisito ético en la IA de alto riesgo. Por qué las respuestas equivocadas con seguridad son el modo de falla más peligroso, cómo detectar la baja confianza, y cómo diseñar el producto para revelar 'no estoy seguro, pregunta a un humano' en vez de farolear.
Construyendo Sistemas RAG en Producción: Lecciones de IA en Salud
Guía práctica para construir sistemas de Generación Aumentada por Recuperación confiables para producción, con ejemplos reales de la construcción de MILA, un asistente LLM neonatal.
No te pierdas nada
Artículos sobre IA, ingeniería y las lecciones que aprendo construyendo cosas. Sin spam, lo prometo.
Osvaldo Restrepo
Senior Full Stack AI & Software Engineer. Building production AI systems that solve real problems.