Cómo entrenar una IA con los datos de tu empresa

En qué consiste entrenar una IA

Cuando entrenamos una IA buscamos una mejora en sus resultados, una personalización de esos resultados, la especialización en un área concreta, que conteste en nuestro tono, o que consulte solo fuentes concretas (internas o externas) para evitar las alucinaciones. En cualquiera de los casos, para conseguirlo necesitaremos una combinación de estrategia y herramientas tecnológicas, algunas tradicionales y otras específicas del entrenamiento de IA:

RAG

No es un entrenamiento como tal, pero impacta en las respuestas de la IA. El modelo no cambia, pero le obligamos a consultar tu documentación en el momento de responder. ¿Cómo se ejecuta? Tu documentación de referencia (la que consultará el RAG) se trocea en fragmentos, y cada fragmento se vectoriza: se convierte en un vector numérico que captura su significado (los llamados embeddings). Además, se añaden etiquetas a cada fragmento que ayudarán a simplificar las búsquedas posteriores.

Esos vectores tienen un tamaño (más dimensiones = más matiz y más coste) y se guardan en una base de datos vectorial especializada, como Qdrant, Pinecone o pgvector.

La potencia de estas bases vectoriales reside en que esos vectores (expuestos como coordenadas en un espacio) concentran el significado de una oración, no su literalidad. Así, por poner un ejemplo, tendríamos que "Se admite a trámite la demanda" y "Se acepta la solicitud del demandante y se le dan 15 días al demandado para…" estarían muy cerca la una de la otra, porque en la práctica significan lo mismo: que se ha admitido la demanda.

Esto permite tener una base de datos en la que ya no necesitas un índice estático que solo te deja consultar entre fechas, importes, clientes y elementos predeterminados. Gracias al RAG y a los embeddings, la búsqueda se enriquece al máximo. Ahora, en lugar de hacer una query pidiendo "Todos los expedientes de entre 1.000 € y 3.000 € cerrados entre 2018 y 2022 del cliente X", podemos decir "Dame los expedientes en los que el deudor alegó que la notificación no le había llegado bien", esté escrito como esté en cada uno: "indefensión", "falta de emplazamiento", "nulidad de actuaciones por defecto en la notificación"… Todas dicen lo mismo y ninguna comparte las palabras. Un índice por campos no las junta jamás; el RAG sí.

Los resultados de esa búsqueda se explotan de diferentes maneras:

Inyectar

Se inyectan en el prompt a la IA como referencias. De esta manera acompañaremos nuestra petición del protocolo de actuación, del mejor ejemplo posible de nuestra BBDD, de las reglas específicas que hay que cumplir para un caso como ese… conseguimos que la IA responda con la documentación idónea delante. Lo que impacta radicalmente en su respuesta.

Validación

Cuando recibamos el resultado podemos vectorizarlo y compararlo contra el de casos similares. Por ejemplo, interpretando notificaciones procesales recibimos una inadmisión; pues podemos compararla contra un pool de inadmisiones vectorizadas, y si no se parece mucho a ninguna, disparar una alerta.

Agentes conversacionales

Un agente sin RAG es un mono con dos pistolas; el RAG le permite consultar en caliente procedimientos, situaciones similares y cómo se resolvieron, el tono de la conversación…

Búsqueda

Necesito encontrar, de mi base de 10.000 contratos, solo aquellos que contienen una cláusula que hace referencia a X, porque hay un cambio legislativo que me obliga a actualizarlos. Pero ojo, esa cláusula puede estar escrita de muchísimas maneras diferentes, o incluso solo deducirse de otra. Vectorizando esos contratos encontraríamos los afectados por esa cláusula.

Fine-tuning

Aquí se ajusta el propio modelo. Se le dan ejemplos tuyos: una instrucción («extrae el importe y el plazo»), una entrada (la parte dispositiva de una notificación, la incidencia de un cliente…) y la respuesta correcta. Con ellos aprende a responder a tu manera. El criterio queda dentro del modelo, sin recordárselo en cada llamada. Es lo que se llama instruction fine-tuning, y sirve cuando la salida tiene que ser siempre estable, con tu formato y tu criterio. Es la gran palanca cuando trabajas con un modelo open source, porque tienes los pesos y puedes reescribir su comportamiento a fondo; con un modelo de mercado muchas veces basta con RAG y system prompt, y el fine-tuning, cuando lo permiten, va más limitado.

Le das unos cuantos cientos de pares como este (la misma clase de documento, resuelto como lo resuelve tu equipo) y el modelo aprende a devolver siempre esa estructura, con tus campos y tu criterio, sin explicárselo en cada llamada.

System prompt

Las instrucciones fijas que recibe el modelo en cada llamada: qué papel juega, con qué tono responde, qué puede hacer y qué no, y en qué formato entrega el resultado. Es la forma más ligera de dirigirlo (se escribe en texto, no toca el modelo) y suele ser lo primero que se afina. Junto a él se ajustan parámetros de la llamada como la temperatura (cuánta libertad tiene el modelo al responder), que en procesos documentales se fija baja para que la misma entrada dé siempre la misma salida. Es un ajuste menor, pero conviene conocerlo (algunos modelos de razonamiento recientes ya la fijan y no dejan tocarla).

El trabajo previo

Sin embargo, entrenar un modelo de IA excede en mucho el uso de estas herramientas. De hecho, sin todo el trabajo previo son más bien una fuente de caos. Un RAG con referencias mal pensadas y mal etiquetadas nos dará, en lugar del mejor ejemplo posible, el peor, y lo que conseguiremos es que la IA responda peor que sin RAG. Un fine-tuning erróneo directamente estropea el modelo entero, no un caso: todas las respuestas salen tocadas.

Para evitar esto necesitamos:

1. Propósito. Qué casos de uso quieres resolver con tu IA entrenada.
2. Selección del dato. Qué parte de tu histórico entra y qué no.
3. Normalización y preparación. Limpiar, homogeneizar y desduplicar lo que suele venir desordenado.
4. Etiquetado. Con tus criterios y codificadores, recogiendo cómo lo resuelve tu equipo.
5. Estructurado del dato. En fragmentos para el RAG, en ejemplos (entrada → respuesta) para el fine-tuning. Misma materia prima, estructurada según la herramienta.
6. Estrategia de prompts. Prompts anidados, prompts con variables, cuándo consulta el RAG, cómo debe ser la salida…
7. Construcción y lanzamiento de lotes de prueba. Separando lo que entrena de lo que se reserva para evaluar.
8. Validación de los lotes. Midiendo el acierto por campo y por tipo documental, y aplicando reglas de validación que viven fuera de la IA para desnudar los resultados dudosos: un campo que falta, un formato incorrecto, dos valores que se contradicen… y a revisión.
9. Recopilación de errores. Dónde falla, cuánto y por qué.
10. Reentrenamiento e iteración. Corregir y repetir hasta cumplir los SLA acordados.

Cuando sigues estos pasos de principio a fin, entrenar un modelo de IA pasa de ser una aventura incierta a un camino empírico, robusto, científico y predecible. En Cómo Entrenar mi Robot tenemos:

• Un equipo que lleva haciendo este proceso desde 2020 con Machine Learning y que, por tanto, conoce todos los obstáculos, grandes y pequeños, que hay que sortear ante este reto.
• Y una plataforma (la primera que conocemos) que permite diseñar, ejecutar y monitorizar el proceso completo: desde la normalización del dato hasta la comprobación automática de resultados, pasando por el entrenamiento.

Preguntas frecuentes

¿Cuántos datos necesito para entrenar una IA?

Menos de los que te imaginas. Para la mayoría de casos documentales se empieza a ver calidad con unos cientos de ejemplos bien elegidos, no con millones. Importa mucho más que estén bien resueltos que que sean muchos: mil documentos con el criterio correcto valen más que cien mil sin revisar.

¿Cuánto tarda en estar funcionando?

Un entorno de pruebas con tus documentos reales se monta en días, no en meses. La puesta en marcha completa depende del caso de uso y de la calidad del histórico, y se organiza por hitos: cada entrega tiene que valer por sí sola antes de seguir.

¿Necesito servidores y GPUs propias?

Depende del camino. Si usas un modelo open source, necesitas una máquina que lo aloje, ya sea en tu infraestructura o en un entorno privado contratado. Si trabajas con un modelo de mercado, no: se consume por API y no montas infraestructura.

¿Y si mis datos son confidenciales?

Con un modelo open source, el modelo es tuyo y vive donde tú decidas, así que tus datos no salen de tu entorno. Con un modelo de mercado, lo que le envías o con lo que lo entrenas no se usa para entrenar los modelos de otros, siempre que elijas bien el proveedor y la configuración. La confidencialidad se resuelve por los dos caminos.

¿Modelo de código abierto o modelo de mercado?

No es una decisión de entrada. Para probar un modelo open source primero hay que entrenarlo, así que muchas veces se empieza con un modelo de mercado y, cuando el caso ya funciona, se migra a open source dejando el de mercado como respaldo. Se decide con resultados delante, no de antemano.

¿Una IA entrenada tiene alucinaciones?

Muchas menos que un modelo generalista. El RAG y el fine-tuning reducen muchísimo las alucinaciones, porque el modelo responde con tu documentación y tu criterio delante. Pero el punto clave son las reglas de validación: si algo falla, se detecta y se dispara una alerta. Ese es el verdadero reto: no solo conseguir que casi nunca falle, sino que, cuando falle, se detecte.