Una empresa quiere adaptar un modelo a su negocio. A menudo se proponen tres soluciones: mejorar el prompt, conectar una base documental mediante RAG o entrenar el modelo con ejemplos. No resuelven el mismo problema.
El prompt da instrucciones al momento de la llamada. El RAG recupera información externa y la añade al contexto. El ajuste fino ajusta los parámetros del modelo para reforzar un comportamiento. Una arquitectura madura puede combinar los tres, pero solo después de haber identificado la causa de los errores.
Comenzar con una línea base
Antes de añadir una tecnología, construir una versión mínima con:
- un modelo de referencia;
- un prompt claro;
- una salida estructurada si es necesario;
- veinte a cien casos de prueba representativos;
- métricas;
- un análisis de errores.
Sin una línea base, es imposible saber si el RAG o el ajuste fino aportan una mejora. El equipo corre el riesgo de medir una impresión sobre algunas demostraciones favorables.
La ingeniería de prompts: delimitar la tarea
Un buen prompt especifica:
- el papel esperado;
- la tarea;
- las entradas;
- las limitaciones;
- el formato de salida;
- los criterios de rechazo;
- ejemplos si son útiles;
- las herramientas disponibles.
El prompt es adecuado cuando el conocimiento necesario ya está en el modelo o se proporciona en la entrada. Es conveniente para transformar un texto, extraer campos, clasificar, resumir o aplicar un procedimiento corto.
Sus ventajas son la rapidez, el bajo costo de implementación y la facilidad de iteración. Sus límites aparecen cuando las instrucciones se vuelven muy largas, contradictorias o difíciles de mantener. Un prompt no actualiza los conocimientos internos del modelo y no garantiza una información empresarial exacta.
El RAG: aportar el conocimiento en el momento de la respuesta
La Generación Aumentada por Recuperación busca pasajes pertinentes en fuentes y luego los transmite al modelo. Es adecuado cuando la información:
- cambian regularmente;
- pertenecen a la empresa;
- deben ser citadas;
- son demasiado numerosas para un prompt fijo;
- poseen derechos de acceso;
- deben ser retiradas sin reentrenar.
Un RAG no es una simple base vectorial. Hay que gestionar la ingestión, el corte, los metadatos, la búsqueda, el reordenamiento, los derechos, las citas, la evaluación y la actualización.
Sus defectos provienen a menudo de la investigación, no del modelo: documento incorrecto, fragmento incompleto, filtro de acceso, vocabulario diferente o información ausente.
El ajuste fino: aprender un comportamiento
El fine-tuning entrena el modelo en pares de ejemplos para aumentar la probabilidad de un comportamiento. Puede ser relevante para:
- respetar un formato preciso;
- adoptar un estilo constante;
- clasificar según una taxonomía estable;
- mejorar un idioma o jerga;
- reducir la longitud del prompt;
- aprender decisiones repetitivas a partir de ejemplos de calidad.
Generalmente no es la mejor solución para memorizar una documentación cambiante. Los hechos se vuelven difíciles de actualizar y citar. Un modelo afinado también puede reproducir errores, sesgos o datos sensibles del corpus.
El esfuerzo principal reside en la selección, la anotación, los derechos, la separación entrenamiento/prueba y la evaluación, no en el lanzamiento del comando de entrenamiento.
La cuestión central: ¿conocimiento o comportamiento?
Cuando el modelo no conoce el procedimiento del día, carece de conocimiento: el RAG suele ser prioritario. Cuando conoce los elementos pero no sigue un formato o confunde una taxonomía, el comportamiento es el problema: el prompt o el ajuste fino pueden ayudar.
Algunos problemas son mixtos. Un asistente de soporte debe encontrar el procedimiento correcto y luego redactar una respuesta conforme al tono de la empresa. El RAG proporciona el contenido; el prompt o el fine-tuning enmarcan la forma.
Árbol de decisión entre prompt, RAG, ajuste fino y enfoque híbrido según el conocimiento, el comportamiento, la actualidad y las pruebas.
Comparar los enfoques
| Criterio | Prompt | RAG | Ajuste fino |
|---|---|---|---|
| Implementación | rápida | media a importante | importante |
| Actualización de hechos | en cada llamada | mediante reindexación | nuevo entrenamiento |
| Citas | limitadas a las fuentes proporcionadas | naturales si están diseñadas | no nativas |
| Datos requeridos | algunos ejemplos | documentos utilizables | ejemplos supervisados de calidad |
| Control de acceso | en la aplicación | hasta la búsqueda | difícil a nivel del conocimiento aprendido |
| Coste de operación | contexto a veces largo | búsqueda + contexto | modelo personalizado + inferencia |
| Depuración | prompt y salida | búsqueda y luego generación | datos, entrenamiento e inferencia |
| Portabilidad | relativamente alta | depende de la cadena | depende del proveedor y del formato |
Esta tabla ofrece tendencias. El punto de referencia real en la tarea sigue siendo decisivo.
El contexto largo no siempre reemplaza al RAG
Los modelos aceptan contextos cada vez más largos. Es tentador enviar todos los documentos. Este enfoque puede funcionar para un expediente puntual, pero tiene límites: costo, latencia, ruido, control de acceso, repetición de datos y dificultad para garantizar que se utilice el pasaje correcto.
El RAG reduce el contexto a los elementos pertinentes y permite un índice compartido. Para conjuntos pequeños, una estrategia híbrida puede primero filtrar por metadatos y luego enviar varios documentos completos.
El RAG no corrige todos los comportamientos
Agregar más documentos no resuelve un modelo que rechaza mal, no respeta el JSON o adopta un tono incorrecto. Hay que separar las métricas:
- recordatorio y precisión de la investigación;
- fidelidad a las fuentes;
- exactitud de la respuesta;
- formato;
- estilo;
- rechazo;
- latencia;
- costo.
Esta descomposición muestra qué palanca modificar.
El ajuste fino exige un corpus gobernado
Los ejemplos deben ser:
- representativos de la producción;
- correctos;
- coherentes entre los anotadores;
- autorizados;
- libres de datos innecesarios;
- separados del conjunto de prueba;
- versionados.
Un corpus de respuestas históricas puede contener los malos hábitos que se desean eliminar. Debe ser depurado, no simplemente exportado.
Prever un modelo de tarjeta interno: versión básica, datos, parámetros, límites, resultados, riesgos y procedimiento de retiro.
Una estrategia híbrida frecuente
Una aplicación robusta puede seguir esta cadena:
- un prompt del sistema corto define las reglas;
- un clasificador o enrutador elige la tarea;
- el RAG recupera las fuentes autorizadas;
- un modelo eventualmente ajustado produce el formato esperado;
- un validador controla el esquema y las citas;
- un humano aprueba los casos sensibles.
Cada ladrillo debe justificar su complejidad. Añadir un modelo ajustado antes de haber estabilizado los errores hace que la arquitectura sea más difícil de mantener.
Construir una experiencia comparativa
La decisión puede ser tomada en cuatro iteraciones.
Iteración 1: prompt de referencia
Medir la calidad sin recuperación ni entrenamiento. Identificar los errores de conocimiento, formato, razonamiento y seguridad.
Iteración 2: RAG mínimo
Indexar un corpus limitado, definir preguntas de referencia y medir la recuperación y luego la respuesta. No empezar con toda la documentación.
Iteración 3: ajuste fino dirigido
Sólo si un comportamiento repetitivo resiste a los prompts y si los ejemplos están disponibles. Comparar con la línea base en un juego nunca visto.
Iteración 4: combinación y explotación
Medir la latencia, el costo, la deriva, la reversibilidad y la capacidad de actualización. La mejor calificación fuera de producción no siempre es la mejor solución operable.
Cuándo no usar el fine-tuning
Evitar afinar cuando:
- los hechos cambian cada semana;
- hay que citar la fuente;
- el corpus es pequeño o contradictorio;
- los derechos son inciertos;
- el error proviene de la investigación;
- la necesidad puede resolverse mediante un esquema de salida;
- no existe ninguna evaluación fiable.
Cuándo no construir un RAG
Un RAG es excesivo para una tarea de transformación sin conocimiento externo, unas pocas reglas estables o un documento único proporcionado en cada llamada. Añade ingestión, índice, seguridad y monitoreo.
Guiado por el costo por tarea realizada
Comparar el costo total: preparación de datos, infraestructura, llamadas, anotaciones, reindexación, entrenamiento, pruebas, incidentes y mantenimiento. Una solución más barata por token puede costar más si falla con mayor frecuencia o requiere una revisión humana intensa.
La métrica útil es el costo por tarea aceptada, con el nivel de calidad esperado.
Elegir un método reversible
Conservar prompts, corpus, evaluaciones y esquemas independientemente del proveedor. Versionar las configuraciones y prever una capa de adaptación. Un modelo o una API puede evolucionar, ser retirado o cambiar de precio.
Partitech puede construir la línea base, el pipeline RAG, el corpus de ajuste fino y la evaluación comparativa. La decisión entonces no se basa ni en una moda ni en una demostración aislada, sino en errores medidos, datos controlados y un costo de explotación realista.
Hablemos de su proyecto
Construir un benchmark comparando prompt, RAG y fine-tuning en sus datos con Partitech. Contacte a Partitech.