Elegir entre RAG o fine tuning depende de lo que tu asistente deba hacer. RAG, abreviatura de retrieval-augmented generation, aporta material de referencia pertinente cuando el modelo responde; el fine tuning consiste en seguir entrenando un modelo con ejemplos. Empieza probando una instrucción clara para la tarea, o prompt. Después, usa el resultado para decidir si debes investigar la falta de material de referencia, la incoherencia de la salida o ambas antes de encargar trabajo adicional.
Un proveedor propone entrenar un sistema de IA para tu empresa, mientras que otro propone una base de conocimiento consultable. Esas descripciones no definen la tarea que debe realizar el sistema terminado ni qué se consideraría un resultado fallido. Nosotros empezamos por esa tarea escrita. Así tienes algo concreto que comparar cuando lleguen las propuestas.
¿Qué cambia con el RAG o el fine tuning?
El RAG cambia el material que se aporta para una respuesta; el fine tuning cambia el modelo mediante entrenamiento. La guía de OpenAI sobre precisión separa la falta de contexto del comportamiento incoherente. Es una distinción inicial útil para quien compra, siempre que se deje margen para necesidades solapadas. Un asistente basado en documentos también puede necesitar una forma coherente de redactar su respuesta.
Según la explicación de Amazon Bedrock sobre las bases de conocimiento, la recuperación selecciona material pertinente y lo incluye en la entrada de generación. Para un asistente propuesto que responda preguntas sobre una política de devoluciones, pide ver qué pasaje aprobado respalda la respuesta. Una referencia a la fuente todavía debe contrastarse con lo que dice la respuesta.
El fine tuning usa ejemplos para seguir entrenando a un modelo sobre cómo responder. La guía de OpenAI lo describe como una opción para mejorar el comportamiento en una tarea. Piensa en una nota de traspaso deseada con una estructura acordada: el proveedor necesita ejemplos de notas aceptables y las entradas utilizadas para producirlas. Es un entregable distinto de una carpeta de documentos de políticas.
Ninguna de las dos etiquetas te dice si la demostración cumple tus requisitos. Pide al proveedor que identifique qué cambia el componente propuesto, que muestre el material que utiliza y que explique cómo comprobarás el resultado. Mantén la conversación ligada al trabajo real que estás comprando.
Empieza con una tarea y una demostración sencilla
Describe la entrada y la salida aceptable antes de elegir un enfoque. La guía de Anthropic sobre prompts empieza por criterios de éxito claros, una prueba con ejemplos y un borrador de prompt. Usamos ese orden para preparar un pliego de compra: redacta la instrucción, aporta material aprobado y examina qué puede hacer la configuración propuesta más sencilla. Este es nuestro método de evaluación sugerido, no un estudio comparativo realmente realizado.
En un asistente de devoluciones ilustrativo, la entrada podría ser la pregunta de un cliente y la política aplicable. Un borrador aceptable responde solo a lo que respalda esa política y deriva las excepciones a una persona. En un traspaso comercial ilustrativo, la entrada podría ser una consulta y un formato de nota aprobado. La salida debería conservar el significado de la consulta y dejar sin completar los datos que falten.
Haz que la persona responsable del proceso escriba qué hace aceptable cada salida. Incluye una solicitud que el asistente deba rechazar o derivar. Usa material que tengas permiso para compartir y elimina los datos personales innecesarios. Una demostración que dependa de información que no puedes proporcionar todavía no es una propuesta viable.
Si ya tienes un asistente que da respuestas poco fiables, utiliza la guía independiente para comprobar por qué la IA da respuestas incorrectas antes de decidir qué encargar.
Elige la siguiente prueba según la carencia restante
Usa el fallo observado para elegir qué probar a continuación. AWS recomienda empezar con la recuperación para preguntas que hagan referencia a documentos personalizados y señala la dificultad de mantener el entrenamiento alineado con material que cambia con frecuencia. También permite combinar recuperación y fine tuning. La tabla siguiente sugiere una próxima prueba para la carencia que hayas encontrado en la demostración.
| Lo que aún necesita la demostración | Qué probar a continuación |
|---|---|
| Información de documentos aprobados que cambian | Recuperación que aporte el material vigente pertinente |
| Una salida repetible que siga siendo incoherente tras usar instrucciones y ejemplos más claros | Entrenamiento con ejemplos aceptados, si el modelo elegido lo admite |
| Material de referencia y una respuesta más coherente | Una configuración combinada, con una comprobación para cada requisito |
Cuando la demostración más sencilla ya cumpla los requisitos, conserva esa opción en la comparación. Pregunta qué problema adicional resolvería el entrenamiento o el sistema de recuperación propuesto. La elección también puede seguir abierta mientras preparas las entradas que faltan.
AWS señala que el fine tuning no está disponible para todos los modelos. Pide al proveedor que indique el proveedor tecnológico y el modelo, explique dónde y cómo se ejecutará el sistema y confirme la compatibilidad vigente con el entrenamiento y el despliegue propuestos.
¿Quién mantiene el sistema después del lanzamiento?
Compara las responsabilidades que cada propuesta deja a tu equipo. Para la recuperación, designa a la persona que aprueba los documentos fuente y comprueba que las actualizaciones lleguen al asistente. Para el entrenamiento, designa quién prepara los ejemplos aceptados y revisa los cambios posteriores. Registra quién concede acceso, quién gestiona los fallos y cómo devuelve el personal la tarea al proceso manual cuando el sistema no sea adecuado.
Incluimos esas preguntas en la planificación de la implantación de IA antes de elegir componentes. Un pliego útil registra:
- La tarea, las entradas permitidas y la salida esperada.
- Las fuentes autorizadas, su responsable y su proceso de actualización.
- Ejemplos de trabajo aceptable y de omisiones o adiciones inaceptables.
- Las condiciones para rechazar una solicitud o derivarla a una persona.
- Las comprobaciones de aceptación, la persona revisora y el material que deberá entregarse.
Para trabajos que impliquen un pedido activo o un registro de contacto, pregunta cómo obtendrá el sistema propuesto el registro vigente permitido. Incluye ese requisito en la parte de integración con el CRM del pliego. Una propuesta para entrenar con registros exportados todavía debe explicar cómo se gestionarán los cambios posteriores.
Pregunta dónde se almacenarán los documentos, las copias consultables, los ejemplos y las salidas, quién podrá acceder a ellos y cómo se gestionará su eliminación. Registra las respuestas para el despliegue real. No trates el nombre de ninguna arquitectura como una decisión sobre alojamiento o permisos.
Comprueba la propuesta con solicitudes inéditas
Mantén las solicitudes de prueba fuera del material utilizado para configurar o entrenar el sistema propuesto. Pide a cada proveedor que ejecute esas solicitudes con los mismos criterios de aceptación. Haz que la persona responsable del proceso examine las salidas, las entradas empleadas para producirlas y las correcciones necesarias. Esto comprueba la propuesta en tu tarea; no demuestra el rendimiento en todas las solicitudes futuras.
- Conserva una referencia. Guarda lo que producen el proceso manual y el prompt más sencillo, junto con sus entradas y notas de revisión.
- Comprueba una actualización de la fuente. Cambia un documento de prueba aprobado y repite la pregunta afectada. Pide al proveedor que muestre qué versión se utilizó y cómo llegó la actualización hasta ella.
- Comprueba las reglas de salida. Reformula una solicitud y omite alguna información. Examina si la nota mantiene la estructura exigida sin inventar ningún dato.
- Prueba el acceso y el alcance. Intenta realizar una solicitud fuera del alcance acordado y con un usuario que no debería recibir un documento restringido. Examina el rechazo o la derivación reales.
- Registra el trabajo que tu equipo debe seguir haciendo. Anota las correcciones, el tiempo de revisión y quién debe mantener los materiales. Compáralos con la referencia antes de ampliar el trabajo.
Cuando falle una comprobación, registra el requisito incumplido y pide una demostración revisada. No pagues por un enfoque más elaborado solo porque su nombre suene más capaz. Acepta el alcance que puedas verificar o mantén la tarea en manos de personas mientras se resuelven las condiciones que faltan.
Cómo intervenimos
Empezamos redactando contigo la tarea, los datos permitidos y las comprobaciones de aceptación. Después comparamos los enfoques propuestos con ese pliego y documentamos quién mantendrá las fuentes, los ejemplos y la evaluación. Un primer paso útil es redactar una solicitud real y aprobar un ejemplo del resultado que necesitas.
