RAG vs Fine-Tuning ¿Cuál es la mejor herramienta para potenciar tu solicitud para un LLM?

RWG vs Ajuste Fino ¿Cuál es la Mejor Herramienta para Potenciar tu Solicitud para un LLM?

 

Prólogo

 

A medida que aumenta la ola de interés en los Modelos de Lenguaje Grande (LLMs), muchos desarrolladores y organizaciones se dedican a construir aplicaciones aprovechando su poder. Sin embargo, cuando los LLMs pre-entrenados no funcionan como se esperaba, surge la pregunta de cómo mejorar el rendimiento de la aplicación de LLM. Y eventualmente llegamos al punto en el que nos preguntamos: ¿Deberíamos usar la Generación con Recuperación Mejorada (RAG) o el ajuste fino del modelo para mejorar los resultados?

Antes de adentrarnos más, aclaremos estos dos métodos:

• Investigadores de IA de Bytedance y la King Abdullah University of Science and Technology presentan un marco novedoso para animar el movimiento del cabello en fotos fijas de retratos
• Comparando técnicas de procesamiento de lenguaje natural RNNs, Transformers, BERT
• Desatando el potencial de la IA El auge de las GPU en la nube

RAG: Este enfoque integra el poder de la recuperación (o búsqueda) en la generación de texto del LLM. Combina un sistema recuperador, que obtiene fragmentos de documentos relevantes de un corpus grande, y un LLM, que produce respuestas utilizando la información de esos fragmentos. En esencia, RAG ayuda al modelo a “buscar” información externa para mejorar sus respuestas.

  

Ajuste fino: Este es el proceso de tomar un LLM pre-entrenado y entrenarlo aún más en un conjunto de datos más pequeño y específico para adaptarlo a una tarea particular o mejorar su rendimiento. Al ajustarlo finamente, estamos ajustando los pesos del modelo basados en nuestros datos, haciéndolo más adaptado a las necesidades únicas de nuestra aplicación.

  

Tanto RAG como el ajuste fino sirven como herramientas poderosas para mejorar el rendimiento de las aplicaciones basadas en LLM, pero abordan diferentes aspectos del proceso de optimización, y esto es crucial a la hora de elegir uno sobre el otro.

Anteriormente, solía sugerir a las organizaciones que experimentaran con RAG antes de adentrarse en el ajuste fino. Esto se basaba en mi percepción de que ambos enfoques lograban resultados similares pero variaban en cuanto a complejidad, coste y calidad. Incluso solía ilustrar este punto con diagramas como este:

 

En este diagrama, diversos factores como complejidad, coste y calidad se representan a lo largo de una sola dimensión. ¿La conclusión? RAG es más sencillo y menos costoso, pero su calidad puede no ser igualmente buena. Mi consejo solía ser: comiencen con RAG, evalúen su rendimiento y, si no es suficiente, cambien al ajuste fino.

Sin embargo, mi perspectiva ha evolucionado desde entonces. Creo que es una simplificación excesiva ver a RAG y al ajuste fino como dos técnicas que logran el mismo resultado, donde una es simplemente más barata y menos compleja que la otra. Son fundamentalmente distintas, en lugar de co-lineales son realmente ortogonales, y satisfacen diferentes requisitos de una aplicación de LLM.

Para que esto quede más claro, consideremos una simple analogía del mundo real: cuando nos hacen la pregunta “¿Debería usar un cuchillo o una cuchara para comer mi comida?”, la contrapregunta más lógica es: “Bueno, ¿qué estás comiendo?” Hice esta pregunta a amigos y familiares y todos respondieron instintivamente con esa contrapregunta, indicando que no ven el cuchillo y la cuchara como intercambiables o uno como una variante inferior del otro.

¿De qué se trata esto?

 

En esta publicación de blog, nos adentraremos en los matices que diferencian a RAG y al ajuste fino en diversas dimensiones que, en mi opinión, son cruciales para determinar la técnica óptima para una tarea específica. Además, examinaremos algunos de los casos de uso más populares de las aplicaciones de LLM y utilizaremos las dimensiones establecidas en la primera parte para identificar qué técnica podría ser la más adecuada para cada caso de uso. En la última parte de esta publicación de blog, identificaremos aspectos adicionales que deben considerarse al construir aplicaciones de LLM. Cada uno de ellos podría merecer su propia publicación de blog y, por lo tanto, solo podremos tocarlos brevemente en el alcance de esta publicación.

¿Por qué debería importarte?

Elegir la técnica adecuada para adaptar modelos de lenguaje grandes puede tener un gran impacto en el éxito de tus aplicaciones de procesamiento del lenguaje natural. Seleccionar el enfoque incorrecto puede llevar a:

• Pobre rendimiento del modelo en tu tarea específica, resultando en salidas inexactas.
• Aumento de los costos computacionales para el entrenamiento y la inferencia del modelo si la técnica no está optimizada para tu caso de uso.
• Tiempo adicional de desarrollo e iteración si necesitas cambiar a una técnica diferente más adelante.
• Retraso en implementar tu aplicación y ponerla frente a los usuarios.
• Falta de interpretabilidad del modelo si eliges un enfoque de adaptación demasiado complejo.
• Dificultad para implementar el modelo en producción debido a restricciones de tamaño o computacionales.

Las sutilezas entre RAG y afinación abarcan la arquitectura del modelo, los requisitos de datos, la complejidad computacional y más. Ignorar estos detalles puede descarrilar tu línea de tiempo y presupuesto del proyecto.

Esta publicación de blog tiene como objetivo evitar esfuerzos desperdiciados al exponer claramente cuándo cada técnica es ventajosa. Con estas ideas, puedes comenzar a trabajar con el enfoque de adaptación correcto desde el primer día. La comparación detallada te equipará para tomar la elección tecnológica óptima para alcanzar tus objetivos empresariales e IA. Esta guía para seleccionar la herramienta adecuada para el trabajo preparará tu proyecto para el éxito.

¡Así que vamos a sumergirnos!

Consideraciones clave para mejorar el rendimiento

Antes de elegir entre RAG y afinación, debemos evaluar los requisitos de nuestro proyecto LLM en algunas dimensiones y hacernos algunas preguntas.

¿Nuestro caso de uso requiere acceso a fuentes de datos externas?

Cuando elegimos entre afinar un LLM o usar RAG, una consideración clave es si la aplicación requiere acceso a fuentes de datos externas. Si la respuesta es sí, es probable que RAG sea la mejor opción.

Por definición, los sistemas RAG están diseñados para ampliar las capacidades de un LLM recuperando información relevante de fuentes de conocimiento antes de generar una respuesta. Esto hace que esta técnica sea adecuada para aplicaciones que necesiten consultar bases de datos, documentos u otros repositorios de datos estructurados/no estructurados. Los componentes de recuperación y generación se pueden optimizar para aprovechar estas fuentes externas.

En contraste, aunque es posible afinar un LLM para aprender algún conocimiento externo, hacerlo requiere un gran conjunto de datos etiquetados de preguntas y respuestas del dominio objetivo. Este conjunto de datos debe actualizarse a medida que cambian los datos subyacentes, lo que lo hace poco práctico para fuentes de datos que cambian con frecuencia. Además, el proceso de afinación no modela explícitamente los pasos de recuperación y razonamiento involucrados en la consulta de conocimiento externo.

Entonces, en resumen, si nuestra aplicación necesita aprovechar fuentes de datos externas, utilizar un sistema RAG probablemente sea más efectivo y escalable que intentar “incorporar” el conocimiento requerido solo mediante afinación.

¿Necesitamos modificar el comportamiento del modelo, el estilo de escritura o el conocimiento específico del dominio?

Otro aspecto muy importante a considerar es cuánto necesitamos que el modelo ajuste su comportamiento, su estilo de escritura o personalice sus respuestas para aplicaciones específicas del dominio.

La afinación sobresale en su capacidad para adaptar el comportamiento de un LLM a matices específicos, tonos o terminologías. Si queremos que el modelo suene más como un profesional médico, escriba con estilo poético o use el argot de una industria específica, la afinación en datos específicos del dominio nos permite lograr estas personalizaciones. Esta capacidad para influir en el comportamiento del modelo es esencial para aplicaciones donde la alineación con un estilo particular o la experiencia en el dominio son vitales.

RAG, aunque es poderoso al incorporar conocimiento externo, se centra principalmente en la recuperación de información y no se ajusta de manera inherente a su estilo lingüístico o a su especificidad de dominio en función de la información recuperada. Extraerá contenido relevante de las fuentes de datos externas, pero es posible que no exhiba los matices personalizados o la experiencia en el dominio que un modelo afinado puede ofrecer.

Entonces, si nuestra aplicación demanda estilos de escritura especializados o una profunda alineación con la jerga y las convenciones específicas del dominio, la afinación ofrece una ruta más directa para lograr esa alineación. Ofrece la profundidad y personalización necesarias para resonar genuinamente con una audiencia específica o un área de experiencia, asegurando que el contenido generado se sienta auténtico y bien fundamentado.

Recapitulación rápida

 

Estos dos aspectos son, con mucho, los más importantes a considerar al decidir qué método utilizar para mejorar el rendimiento de la aplicación de LLM. Curiosamente, son, en mi opinión, ortogonales y pueden utilizarse de forma independiente (y también combinarse).

  

Sin embargo, antes de adentrarnos en los casos de uso, hay algunos aspectos clave más que debemos considerar antes de elegir un método:

 

¿Qué tan crucial es suprimir las alucinaciones?

 

Uno de los inconvenientes de los LLM es su tendencia a la alucinación, inventando hechos o detalles que no tienen base en la realidad. Esto puede ser altamente problemático en aplicaciones donde la precisión y la veracidad son fundamentales.

El ajuste fino puede ayudar a reducir las alucinaciones hasta cierto punto al basar el modelo en los datos de entrenamiento de un dominio específico. Sin embargo, el modelo aún puede fabricar respuestas cuando se enfrenta a entradas desconocidas. Es necesario reentrenar con nuevos datos para minimizar continuamente las falsas fabricaciones.

En contraste, los sistemas RAG son inherentemente menos propensos a la alucinación porque basan cada respuesta en la evidencia recuperada. El recuperador identifica hechos relevantes de la fuente de conocimiento externa antes de que el generador construya la respuesta. Este paso de recuperación actúa como un mecanismo de verificación de hechos, reduciendo la capacidad del modelo para fabular. El generador está obligado a sintetizar una respuesta respaldada por el contexto recuperado.

Por lo tanto, en aplicaciones donde suprimir falsedades y fabricaciones imaginativas es vital, los sistemas RAG proporcionan mecanismos incorporados para minimizar las alucinaciones. La recuperación de evidencia de apoyo antes de la generación de la respuesta le da a RAG una ventaja para garantizar salidas precisas y veraces desde el punto de vista factual.

 

¿Cuántos datos de entrenamiento etiquetados están disponibles?

 

Cuando se decide entre RAG y ajuste fino, un factor crucial a considerar es el volumen de datos de entrenamiento etiquetados específicos del dominio o tarea que tenemos a nuestra disposición.

El ajuste fino de un LLM para adaptarse a tareas o dominios específicos depende en gran medida de la calidad y cantidad de los datos etiquetados disponibles. Un conjunto de datos completo puede ayudar al modelo a comprender profundamente los matices, las complejidades y los patrones únicos de un dominio particular, lo que le permite generar respuestas más precisas y contextualmente relevantes. Sin embargo, si estamos trabajando con un conjunto de datos limitado, las mejoras del ajuste fino pueden ser marginales. En algunos casos, un conjunto de datos escaso incluso puede provocar un ajuste excesivo, donde el modelo funciona bien con los datos de entrenamiento pero tiene dificultades con entradas no vistas o del mundo real.

Por el contrario, los sistemas RAG son independientes de los datos de entrenamiento porque aprovechan fuentes de conocimiento externas para recuperar información relevante. Incluso si no tenemos un conjunto de datos etiquetados extensos, un sistema RAG aún puede funcionar de manera competente al acceder e incorporar ideas de sus fuentes de datos externas. La combinación de recuperación y generación asegura que el sistema se mantenga informado, incluso cuando los datos de entrenamiento específicos del dominio son escasos.

En esencia, si tenemos una gran cantidad de datos etiquetados que capturan los matices del dominio, el ajuste fino puede ofrecer un comportamiento del modelo más personalizado y refinado. Pero en escenarios donde estos datos son limitados, un sistema RAG ofrece una alternativa sólida, asegurando que la aplicación se mantenga informada por los datos y contextualmente consciente a través de sus capacidades de recuperación.

 

¿Qué tan estática/dinámica es la información?

 

Otro aspecto fundamental a considerar al elegir entre RAG y ajuste fino es la naturaleza dinámica de nuestros datos. ¿Con qué frecuencia se actualizan los datos y qué tan imperativo es que el modelo se mantenga actualizado?

Ajustar fino un LLM en un conjunto de datos específico significa que el conocimiento del modelo se convierte en una instantánea estática de esos datos en el momento del entrenamiento. Si los datos se actualizan, cambian o se expanden con frecuencia, esto puede hacer que el modelo rápidamente quede obsoleto. Para mantener el LLM actualizado en entornos tan dinámicos, tendríamos que reentrenarlo con frecuencia, un proceso que puede llevar tiempo y ser intensivo en recursos. Además, cada iteración requiere una supervisión cuidadosa para asegurarse de que el modelo actualizado siga funcionando bien en diferentes escenarios y no haya desarrollado nuevos sesgos o lagunas en la comprensión.

En contraste, los sistemas RAG poseen inherentemente una ventaja en entornos con datos dinámicos. Su mecanismo de recuperación constantemente consulta fuentes externas, asegurando que la información que obtienen para generar respuestas esté actualizada. A medida que las bases de conocimiento externas o las bases de datos se actualizan, el sistema RAG integra estos cambios de manera fluida, manteniendo su relevancia sin la necesidad de un frecuente reentrenamiento del modelo.

En resumen, si nos encontramos lidiando con un panorama de datos en constante evolución, RAG ofrece una agilidad difícil de igualar con el afinado tradicional. Al estar siempre conectado a los datos más recientes, RAG asegura que las respuestas generadas estén en sintonía con el estado actual de la información, lo que lo convierte en una opción ideal para escenarios de datos dinámicos.

 

¿Qué grado de transparencia/interpretabilidad necesita nuestra aplicación LLM?

 

El último aspecto a considerar es el grado en que necesitamos comprender el proceso de toma de decisiones del modelo.

El afinado de un LLM, aunque increíblemente poderoso, opera como una caja negra, lo que hace que el razonamiento detrás de sus respuestas sea más opaco. A medida que el modelo interioriza la información del conjunto de datos, se vuelve desafiante discernir la fuente exacta o el razonamiento detrás de cada respuesta. Esto puede dificultar que los desarrolladores o usuarios confíen en las salidas del modelo, especialmente en aplicaciones críticas donde comprender el “por qué” detrás de una respuesta es vital.

Por otro lado, los sistemas RAG ofrecen un nivel de transparencia que no se encuentra típicamente en modelos simplemente afinados. Dada la naturaleza de dos pasos de RAG, recuperación y generación, los usuarios pueden observar el proceso. El componente de recuperación permite inspeccionar qué documentos externos o puntos de datos se seleccionan como relevantes. Esto proporciona un rastro tangible de evidencia o referencia que se puede evaluar para comprender la base en la que se construye una respuesta. La capacidad de rastrear la respuesta de un modelo hasta fuentes de datos específicas puede ser invaluable en aplicaciones que exigen un alto grado de responsabilidad o cuando es necesario validar la precisión del contenido generado.

En esencia, si la transparencia y la capacidad de interpretar los fundamentos de las respuestas de un modelo son prioridades, RAG ofrece una clara ventaja. Al descomponer la generación de respuestas en etapas distintas y permitir la comprensión de su recuperación de datos, RAG fomenta una mayor confianza y comprensión en sus salidas.

 

Resumen

 

Elegir entre RAG y el afinado se vuelve más intuitivo al considerar estas dimensiones. Si necesitamos inclinarnos hacia el acceso al conocimiento externo y valorar la transparencia, RAG es nuestra opción. Por otro lado, si trabajamos con datos etiquetados estables y queremos adaptar el modelo más estrechamente a necesidades específicas, el afinado es la mejor opción.

  

En la siguiente sección, veremos cómo podemos evaluar casos de uso populares de LLM en función de estos criterios.

 

Casos de uso

 

Veamos algunos casos de uso populares y cómo se puede utilizar el marco mencionado anteriormente para elegir el método adecuado:

 

Resumen (en un dominio especializado y/o un estilo específico)

 

1. ¿Se requiere conocimiento externo? Para la tarea de resumir en el estilo de resúmenes anteriores, la fuente principal de datos serían los propios resúmenes anteriores. Si estos resúmenes están contenidos en un conjunto de datos estático, hay poca necesidad de recuperación continua de datos externos. Sin embargo, si hay una base de datos dinámica de resúmenes que se actualiza con frecuencia y el objetivo es alinear continuamente el estilo con las entradas más nuevas, RAG podría ser útil aquí.

2. ¿Se requiere adaptación del modelo? El núcleo de este caso de uso gira en torno a la adaptación a un dominio especializado o un estilo de escritura específico. El afinado es particularmente hábil para capturar matices estilísticos, variaciones tonales y vocabularios de dominio específicos, lo que lo convierte en una opción óptima para esta dimensión.

3. ¿Es crucial minimizar las alucinaciones? Las alucinaciones son problemáticas en la mayoría de las aplicaciones de LLM, incluida la summarización. Sin embargo, en este caso de uso, el texto a resumir suele estar provisto como contexto. Esto hace que las alucinaciones sean menos preocupantes en comparación con otros casos de uso. El texto fuente limita al modelo, reduciendo las fabricaciones imaginativas. Si bien siempre es deseable la precisión factual, suprimir las alucinaciones es una prioridad menor para la resumización dada la fundamentación contextual.

4. ¿Hay datos de entrenamiento disponibles? Si hay una colección sustancial de resúmenes anteriores que están etiquetados o estructurados de manera que el modelo pueda aprender de ellos, el afinado se vuelve una opción muy atractiva. Por otro lado, si el conjunto de datos es limitado y nos basamos en bases de datos externas para la alineación estilística, RAG podría desempeñar un papel, aunque su fortaleza principal no es la adaptación de estilo.

5. ¿Qué tan dinámicos son los datos? Si la base de datos de resúmenes anteriores es estática o se actualiza con poca frecuencia, es probable que el conocimiento del modelo perfeccionado siga siendo relevante durante más tiempo. Sin embargo, si los resúmenes se actualizan con frecuencia y es necesario que el modelo se alinee continuamente con los cambios estilísticos más nuevos, RAG podría tener una ventaja debido a sus capacidades de recuperación de datos dinámicos.

6. ¿Se requiere transparencia/interpretación? El objetivo principal aquí es la alineación estilística, por lo que el “por qué” detrás de un estilo de resumen en particular puede ser menos crítico que en otros casos de uso. Dicho esto, si existe la necesidad de rastrear y comprender qué resúmenes anteriores influenciaron una salida en particular, RAG ofrece un poco más de transparencia. Sin embargo, esto podría ser una preocupación secundaria para este caso de uso.

Recomendación: Para este caso de uso, parece más adecuada la opción de perfeccionamiento. El objetivo principal es la alineación estilística, una dimensión en la que el perfeccionamiento brilla. Suponiendo que haya una cantidad decente de resúmenes anteriores disponibles para el entrenamiento, perfeccionar un LLM permitiría una adaptación profunda al estilo deseado, capturando los matices e intrincados del dominio. Sin embargo, si la base de datos de resúmenes es extremadamente dinámica y hay valor en rastrear las influencias, se podría considerar un enfoque híbrido o inclinarse hacia RAG.

Sistema de preguntas/respuestas sobre conocimiento organizacional (es decir, datos externos)

 

1. ¿Se requiere conocimiento externo? Un sistema de preguntas/respuestas que dependa de las bases de conocimiento organizacional requiere inherentemente acceso a datos externos, en este caso, las bases de datos internas y los repositorios de documentos de la organización. La eficacia del sistema depende de su capacidad para aprovechar y recuperar información relevante de estas fuentes para responder consultas. En este sentido, RAG destaca como la opción más adecuada para esta dimensión, ya que está diseñado para mejorar las capacidades de LLM mediante la recuperación de datos pertinentes de fuentes de conocimiento.

2. ¿Se requiere adaptación del modelo? Dependiendo de la organización y su campo, puede haber requisitos para que el modelo se alinee con terminologías, tonos o convenciones específicas. Si bien RAG se centra principalmente en la recuperación de información, el perfeccionamiento puede ayudar al LLM a ajustar sus respuestas al lenguaje interno de la empresa o a los matices de su dominio. Por lo tanto, para esta dimensión, según los requisitos específicos, el perfeccionamiento podría jugar un papel.

3. ¿Es crucial minimizar las alucinaciones? Las alucinaciones son una preocupación importante en este caso de uso, debido al límite de conocimiento de los LLMs. Si el modelo no puede responder una pregunta en función de los datos en los que ha sido entrenado, casi seguramente inventará una respuesta plausible pero incorrecta (total o parcialmente).

4. ¿Hay datos de entrenamiento disponibles? Si la organización cuenta con un conjunto de datos estructurado y etiquetado de preguntas respondidas anteriormente, esto puede reforzar el enfoque de perfeccionamiento. Sin embargo, no todas las bases de datos internas están etiquetadas o estructuradas con fines de entrenamiento. En escenarios donde los datos no están claramente etiquetados o donde el enfoque principal es recuperar respuestas precisas y relevantes, la capacidad de RAG para acceder a fuentes de datos externas sin necesidad de un vasto conjunto de datos etiquetados lo convierte en una opción convincente.

5. ¿Qué tan dinámicos son los datos? Las bases de datos internas y los repositorios de documentos en las organizaciones pueden ser altamente dinámicos, con actualizaciones, cambios o adiciones frecuentes. Si esta dinamicidad es característica de la base de conocimiento de la organización, RAG ofrece una ventaja distintiva. Realiza consultas continuas a las fuentes externas, asegurando que sus respuestas se basen en los datos más recientes disponibles. El perfeccionamiento requeriría un entrenamiento regular para mantenerse al día con dichos cambios, lo que podría resultar impráctico.

6. ¿Se requiere transparencia/interpretación? Para aplicaciones internas, especialmente en sectores como finanzas, salud o legal, comprender el razonamiento o la fuente detrás de una respuesta puede ser fundamental. Dado que RAG proporciona un proceso de recuperación y luego generación, ofrece inherentemente una mayor claridad sobre qué documentos o puntos de datos influyeron en una respuesta en particular. Esta trazabilidad puede ser invaluable para las partes interesadas internas que puedan necesitar validar o investigar aún más las fuentes de ciertas respuestas.

Recomendación: Para este caso de uso, parece más adecuada la opción de un sistema RAG. Dada la necesidad de acceso dinámico a las bases de datos internas en evolución de la organización y la posible necesidad de transparencia en el proceso de respuesta, RAG ofrece capacidades que se ajustan bien a estas necesidades. Sin embargo, si se hace hincapié en adaptar el estilo lingüístico del modelo o en adaptarse a matices específicos del dominio, se podría considerar la incorporación de elementos de perfeccionamiento.

Automatización del Soporte al Cliente (es decir, chatbots automatizados o soluciones de servicio de asistencia que brindan respuestas instantáneas a consultas de clientes)

 

1. ¿Se requiere conocimientos externos? El soporte al cliente a menudo requiere acceso a datos externos, especialmente cuando se trata de detalles de productos, información específica de cuentas o bases de datos de solución de problemas. Si bien muchas consultas se pueden resolver con conocimientos generales, algunas pueden requerir extraer datos de bases de datos de la empresa o preguntas frecuentes de productos. Aquí, la capacidad de RAG para recuperar información pertinente de fuentes externas sería beneficiosa. Sin embargo, cabe destacar que muchas interacciones de soporte al cliente también se basan en scripts o conocimientos predefinidos, que se pueden abordar de manera efectiva con un modelo ajustado.

2. ¿Se requiere adaptación del modelo? Las interacciones con los clientes demandan un cierto tono, cortesía y claridad, y también pueden requerir terminologías específicas de la empresa. La adaptación fina es especialmente útil para garantizar que el modelo de LLM se adapte a la voz, la marca y las terminologías específicas de la empresa, asegurando una experiencia de cliente constante y alineada con la marca.

3. ¿Es crucial minimizar las alucinaciones? Para los chatbots de soporte al cliente, evitar la información falsa es esencial para mantener la confianza del usuario. La adaptación fina sola deja a los modelos propensos a alucinaciones cuando se enfrentan a consultas desconocidas. En cambio, los sistemas RAG suprimen las fabricaciones al basar las respuestas en evidencia recuperada. Esta dependencia de hechos obtenidos permite que los chatbots de RAG minimicen falsedades perjudiciales y proporcionen a los usuarios información confiable cuando la precisión es vital.

4. ¿Hay datos de entrenamiento disponibles? Si una empresa tiene un historial de interacciones con clientes, esos datos pueden ser invaluables para la adaptación fina. Se puede utilizar un conjunto de datos rico en consultas anteriores de clientes y sus resoluciones para entrenar al modelo para manejar interacciones similares en el futuro. Si esos datos son limitados, RAG puede proporcionar una alternativa al recuperar respuestas de fuentes externas como documentación de productos.

5. ¿Qué tan dinámicos son los datos? El soporte al cliente puede tener que abordar consultas sobre nuevos productos, políticas actualizadas o cambios en los términos de servicio. En escenarios donde la línea de productos, las versiones de software o las políticas de la empresa se actualizan con frecuencia, la capacidad de RAG para obtener dinámicamente los últimos documentos o bases de datos es ventajosa. Por otro lado, para dominios de conocimiento más estáticos, la adaptación fina puede ser suficiente.

6. ¿Se requiere transparencia/interpretabilidad? Si bien la transparencia es esencial en algunos sectores, en el soporte al cliente, el enfoque principal se centra en respuestas precisas, rápidas y corteses. Sin embargo, para el monitoreo interno, el aseguramiento de calidad o la resolución de disputas con clientes, tener trazabilidad en cuanto a la fuente de una respuesta podría ser beneficioso. En tales casos, el mecanismo de recuperación de RAG ofrece un nivel adicional de transparencia.

Recomendación: Para la automatización del soporte al cliente, un enfoque híbrido podría ser óptimo. La adaptación fina puede garantizar que el chatbot se alinee con la marca, el tono y los conocimientos generales de la empresa, manejando la mayoría de las consultas de los clientes. RAG puede servir como un sistema complementario, interviniendo en consultas más dinámicas o específicas, asegurando que el chatbot pueda obtener información de los últimos documentos o bases de datos de la empresa y, de esta manera, minimizar las alucinaciones. Al integrar ambos enfoques, las empresas pueden proporcionar una experiencia de soporte al cliente integral, oportuna y consistente con la marca.

 

Aspectos adicionales a considerar

 

Como se mencionó anteriormente, hay otros factores que se deben tener en cuenta al decidir entre RAG y la adaptación fina (o ambos). No podemos profundizar en ellos, ya que todos son multifacéticos y no tienen respuestas claras como algunos de los aspectos anteriores (por ejemplo, si no hay datos de entrenamiento, la adaptación fina simplemente no es posible). Pero eso no significa que debamos ignorarlos:

 

Escalabilidad

 

A medida que una organización crece y sus necesidades evolucionan, ¿qué tan escalables son los métodos en cuestión? Los sistemas RAG, dado su enfoque modular, podrían ofrecer una escalabilidad más sencilla, especialmente si la base de conocimientos crece. Por otro lado, adaptar finamente un modelo con frecuencia para adaptarse a conjuntos de datos en expansión puede ser computacionalmente exigente.

 

Latencia y Requisitos en Tiempo Real

 

Si la aplicación requiere respuestas en tiempo real o casi en tiempo real, debes considerar la latencia introducida por cada método. Los sistemas RAG, que implican recuperar datos antes de generar una respuesta, pueden introducir más latencia en comparación con un LLM finoajustado que genera respuestas basadas en conocimiento internalizado.

 

Mantenimiento y Soporte

 

Debes pensar en el largo plazo. ¿Qué sistema se alinea mejor con la capacidad de la organización para proporcionar un mantenimiento y soporte consistentes? RAG puede requerir mantenimiento de la base de datos y el mecanismo de recuperación, mientras que el finoajuste requeriría esfuerzos constantes de reentrenamiento, especialmente si los datos o los requisitos cambian.

 

Robustez y Confiabilidad

 

¿Qué tan robusto es cada método frente a diferentes tipos de entradas? Mientras que los sistemas RAG pueden extraer conocimientos de fuentes externas y manejar una amplia variedad de preguntas, un modelo bien finoajustado puede ofrecer más consistencia en ciertos dominios.

 

Consideraciones Éticas y de Privacidad

 

El almacenamiento y la recuperación de bases de datos externas pueden plantear preocupaciones de privacidad, especialmente si los datos son sensibles. Por otro lado, un modelo finoajustado, aunque no consulta bases de datos en vivo, aún puede producir salidas basadas en sus datos de entrenamiento, lo cual podría tener implicaciones éticas propias.

 

Integración con Sistemas Existentes

 

Las organizaciones podrían tener infraestructura existente. La compatibilidad de RAG o del finoajuste con los sistemas existentes, ya sean bases de datos, infraestructuras en la nube o interfaces de usuario, puede influir en la elección.

 

Experiencia del Usuario

 

Considera a los usuarios finales y sus necesidades. Si requieren respuestas detalladas respaldadas por referencias, RAG puede ser preferible. Si valoran la rapidez y la experiencia específica en un dominio, un modelo finoajustado podría ser más adecuado.

 

Costo

 

El finoajuste puede ser costoso, especialmente para modelos muy grandes. Pero en los últimos meses, los costos han disminuido significativamente gracias a técnicas eficientes de parámetros como QLoRA. Configurar RAG puede ser una inversión inicial grande, que abarque la integración, el acceso a la base de datos, e incluso tarifas de licencia, pero también hay que tener en cuenta el mantenimiento regular de esa base de conocimientos externa.

 

Complejidad

 

El finoajuste puede volverse complejo rápidamente. Aunque muchos proveedores ahora ofrecen finoajuste con un solo clic, donde solo necesitamos proporcionar los datos de entrenamiento, llevar un seguimiento de las versiones del modelo y asegurarse de que los nuevos modelos sigan funcionando bien en general es un desafío. Por otro lado, RAG también puede volverse complejo rápidamente. Está la configuración de múltiples componentes, asegurarse de que la base de datos se mantenga actualizada y garantizar que las piezas, como la recuperación y la generación, encajen correctamente.

 

Conclusión

 

Como hemos explorado, elegir entre RAG y finoajuste requiere una evaluación sutil de las necesidades y prioridades únicas de una aplicación LLM. No existe una solución única que sirva para todo; el éxito radica en alinear el método de optimización con los requisitos específicos de la tarea. Al evaluar los criterios clave, como la necesidad de datos externos, la adaptación del comportamiento del modelo, la disponibilidad de datos de entrenamiento, la dinámica de los datos, la transparencia de los resultados y más, las organizaciones pueden tomar una decisión informada sobre el mejor camino a seguir. En ciertos casos, un enfoque híbrido que aproveche tanto RAG como finoajuste puede ser óptimo.

La clave está en evitar suposiciones de que un método es universalmente superior. Como cualquier herramienta, su idoneidad depende del trabajo que se esté realizando. La falta de alineación entre el enfoque y los objetivos puede obstaculizar el progreso, mientras que el método correcto lo acelera. A medida que una organización evalúa opciones para impulsar las aplicaciones LLM, debe resistir la simplificación excesiva y no ver RAG y el finoajuste como intercambiables, sino elegir la herramienta que empodera al modelo para cumplir con sus capacidades alineadas con las necesidades del caso de uso. Las posibilidades que estos métodos desbloquean son asombrosas, pero la posibilidad por sí sola no es suficiente: la ejecución lo es todo. Las herramientas están aquí: ahora pongámoslas a trabajar.

  Heiko Hotz es el Fundador de NLP London, una consultoría de IA que ayuda a las organizaciones a implementar procesamiento de lenguaje natural e IA conversacional. Con más de 15 años de experiencia en la industria tecnológica, Heiko es experto en aprovechar la IA y el aprendizaje automático para resolver desafíos comerciales complejos.

 Original. Reposteado con permiso. 

[Heiko Hotz](https://www.linkedin.com/in/heikohotz/) es el Fundador de NLP London, una consultora de IA que ayuda a las organizaciones a implementar el procesamiento de lenguaje natural y la IA conversacional. Con más de 15 años de experiencia en la industria tecnológica, Heiko es un experto en aprovechar la IA y el aprendizaje automático para resolver desafíos empresariales complejos.

We will continue to update Zepes; if you have any questions or suggestions, please contact us!