un artículo sobre ingeniería excesiva de un sistema RAG, agregando cosas sofisticadas como optimización de consultas, fragmentación detallada con vecinos y claves, además de expandir el contexto.
El argumento en contra de este tipo de trabajo es que, por algunos de estos complementos, todavía terminas pagando entre un 40% y un 50% más en latencia y costo.
Entonces, decidí probar ambas canalizaciones, una con optimización de consultas y expansión de vecinos, y otra sin ellas.
La primera prueba que realicé utilizó preguntas de corpus simples generadas directamente a partir de los documentos y los resultados fueron mediocres. Pero luego seguí probándolo con preguntas más complicadas y con preguntas aleatorias del mundo real, y mostró algo diferente.
De esto es de lo que hablaremos aquí: de dónde pueden funcionar bien funciones como la expansión de vecinos y de dónde el costo puede no valer la pena.
Revisaremos la configuración, el diseño del experimento, tres ejecuciones de evaluación diferentes con diferentes conjuntos de datos, cómo entender los resultados y la relación costo/beneficio.
Tenga en cuenta que este experimento utiliza métricas sin referencias y jueces de LLM, con los que siempre debe tener cuidado. Puedes ver el desglose completo en este documento de Excel.
Si se siente confundido en algún momento, hay dos artículos, aquí y aquí, anteriores a este, aunque este debería ser independiente.
la introducción
La gente continúa agregando complejidad a sus procesos de RAG, y hay una razón para ello. El diseño general es defectuoso, por lo que seguimos parcheando correcciones para hacer algo que sea más robusto.
La mayoría de las personas han introducido la búsqueda híbrida, BM25 y semántica, junto con reclasificadores en sus configuraciones RAG. Esto se ha convertido en una práctica habitual. Pero hay funciones más complejas que puedes agregar.
La canalización que estamos probando aquí presenta dos características adicionales, optimización de consultas y expansión de vecinos, y prueba su eficiencia.
Usamos jueces de LLM y diferentes conjuntos de datos para evaluar métricas automatizadas como la fidelidad, junto con pruebas A/B de calidad, para ver cómo las métricas se mueven y cambian para cada una.
La introducción recorrerá la configuración y el diseño del experimento.
la configuración
Primero repasemos la configuración, cubriendo brevemente la fragmentación detallada y la expansión de vecinos, y lo que defino como complejo versus ingenuo para los propósitos de este artículo.
La canalización que he ejecutado aquí utiliza métodos de fragmentación muy detallados, si leyó mi artículo anterior.
Esto significa analizar los archivos PDF correctamente, respetar la estructura del documento, utilizar lógica de fusión inteligente, detección inteligente de límites, manejo de fragmentos numéricos y contexto a nivel de documento (es decir, aplicar encabezados para cada fragmento).
Decidí no ceder en esta parte, aunque obviamente es la parte más difícil de construir un canal de recuperación.
Al procesar, también divide las secciones y luego hace referencia a los fragmentos vecinos en los metadatos. Esto nos permite ampliar el contenido para que el LLM pueda ver de dónde viene.
Para esta prueba, usamos los mismos fragmentos, pero eliminamos la optimización de consultas y la expansión de contexto para la canalización ingenua para ver si los complementos sofisticados realmente están funcionando.
También debo mencionar que el caso de uso para esto fueron los artículos científicos del RAG. Este es un caso semi-difícil y, como tal, para casos de uso más fáciles esto puede no aplicarse (pero también llegaremos a eso más adelante).
Puede ver los artículos que este canal ha absorbido aquí y leer sobre el caso de uso aquí.
Para concluir: la configuración utiliza la misma fragmentación, el mismo reranker y el mismo LLM. La única diferencia es optimizar las consultas y expandir los fragmentos a los vecinos.
El diseño del experimento.
Tenemos tres conjuntos de datos diferentes que se ejecutaron a través de varias métricas automatizadas, luego a través de un juez cara a cara, además de examinar los resultados para validar y comprender los resultados.
Comencé creando un conjunto de datos con 256 preguntas generadas a partir del corpus. Esto significa preguntas como "¿Cuál es el propósito principal del modelo Step-Audio 2?"
Esta puede ser una buena forma de validar que su canalización funciona, pero si está demasiado limpia puede darle una falsa sensación de seguridad.
Tenga en cuenta que no especifiqué cómo se deben generar las preguntas. Esto significa que no le pedí que generara preguntas que una sección completa pudiera responder, o que solo una parte pudiera responder.
El segundo conjunto de datos también se generó a partir del corpus, pero intencionalmente le pedí al LLM que generara preguntas confusas como "¿cuáles son los tres tipos de funciones de recompensa que se usan en eviomni?"
El tercer conjunto de datos, y el más importante, fue el conjunto de datos aleatorio.
Le pedí a un agente de IA que investigara diferentes preguntas de RAG que la gente tenía en línea, como "¿los mejores puntos de referencia de evaluación de RAG y por qué?" y "¿cuándo el uso de títulos/resúmenes supera a la recuperación de texto completo?".
Recuerde, el oleoducto solo había absorbido alrededor de 150 artículos científicos de septiembre/octubre que mencionaban RAG. Así que no sabemos si el corpus tiene siquiera las respuestas.
Para ejecutar las primeras evaluaciones, utilicé métricas automatizadas como fidelidad (la respuesta se mantiene basada en el contexto) y relevancia de la respuesta (responde a la consulta) de RAGAS. También agregué algunas métricas de DeepEval para observar la relevancia del contexto, la estructura y las alucinaciones.
Si desea obtener una descripción general de estas métricas, consulte mi artículo anterior.
Ejecutamos ambos canales a través de los diferentes conjuntos de datos y luego a través de todas estas métricas.
Luego agregué otro juez cara a cara para realizar pruebas A/B de la calidad de cada canalización para cada conjunto de datos. Este juez no vio el contexto, sólo la pregunta, la respuesta y las métricas automatizadas.
¿Por qué no incluir el contexto en la evaluación? Porque no puedes sobrecargar a estos jueces con demasiadas variables. Esta es también la razón por la que las evaluaciones pueden resultar difíciles. Debe comprender la métrica clave que desea medir para cada uno.
Debo señalar que esta puede ser una forma poco confiable de probar sistemas. Si la puntuación de la alucinación es principalmente vibraciones, pero eliminamos un punto de datos debido a ello antes de enviarlo al siguiente juez que evalúa la calidad, podemos terminar con datos muy poco confiables una vez que comenzamos a agregarlos.
Para la parte final, analizamos la similitud semántica entre las respuestas y examinamos las que tenían las mayores diferencias, junto con casos en los que un canal claramente venció al otro.
Pasemos ahora a ejecutar el experimento.
Ejecutando el experimento
Dado que tenemos varios conjuntos de datos diferentes, debemos revisar los resultados de cada uno. Los dos primeros conjuntos de datos resultaron bastante mediocres, pero nos mostraron algo, por lo que vale la pena cubrirlos.
El conjunto de datos aleatorios mostró los resultados más interesantes hasta el momento. Este será el enfoque principal y profundizaré un poco en los resultados para mostrar dónde falló y dónde tuvo éxito.
Recuerde, estoy tratando de reflejar la realidad aquí, que a menudo es mucho más confusa de lo que la gente quiere que sea.
Preguntas limpias del corpus.
El corpus limpio mostró resultados bastante idénticos en todas las métricas. El juez pareció preferir uno sobre el otro basándose en preferencias superficiales, pero nos mostró el problema de confiar en conjuntos de datos sintéticos.
La primera ejecución se realizó en el conjunto de datos del corpus. Recuerde las preguntas claras que se generaron a partir de los documentos que el canal había absorbido.
Los resultados de las métricas automatizadas fueron inquietantemente similares.
Incluso la relevancia del contexto fue prácticamente la misma, ~0,95 para ambos. Tuve que comprobarlo varias veces para confirmarlo. Como he tenido gran éxito con el uso de la expansión de contexto, los resultados me inquietaron un poco.
Aunque, en retrospectiva, es bastante obvio que las preguntas ya están bien formateadas para su recuperación y un pasaje puede responder a la pregunta.
Pensé en por qué la relevancia del contexto no disminuía para la tubería ampliada si un pasaje era lo suficientemente bueno. Esto se debió a que los contextos adicionales provienen de la misma sección que los trozos de semillas, lo que los hace semánticamente relacionados y RAGAS no los considera "irrelevantes".
La prueba A/B de calidad que realizamos tuvo resultados similares. Ambos ganaron por las mismas razones: exhaustividad, precisión y claridad.
En los casos en los que ganó la ingenuidad, al juez le gustó la concisión, la claridad y el enfoque de la respuesta. Penalizó el complejo proceso por detalles más periféricos (casos extremos, citas adicionales) que no fueron solicitados directamente.
Cuando ganó lo complejo, le gustó la integridad/extensión de la respuesta sobre la ingenua. Esto significaba tener números/métricas específicas, mecanismos paso a paso y explicaciones del "por qué", no solo del "qué".
Sin embargo, estos resultados no indicaron ningún fracaso. Esto fue más una cuestión de preferencia que de puras diferencias de calidad, a ambos les fue excepcionalmente bien.
Entonces, ¿qué aprendimos de esto? En un mundo perfecto, no necesita ningún complemento sofisticado de RAG, y usar un conjunto de prueba del corpus es muy poco confiable.
Preguntas confusas del corpus
A continuación, probamos el segundo conjunto de datos, que mostró resultados similares al primero, ya que se había generado sintéticamente, pero comenzó a moverse en otra dirección, lo cual fue interesante.
Recuerde que presenté anteriormente las preguntas más complicadas generadas a partir del corpus. Este conjunto de datos se generó de la misma manera que el primero, pero con una redacción desordenada (“¿puedes explicar cómo, por favor…”).
Los resultados de las métricas automatizadas mostraron que los resultados seguían siendo muy similares, aunque la relevancia del contexto comenzó a disminuir en el complejo mientras que la fidelidad comenzó a aumentar ligeramente.
Para aquellos que no cumplieron con las métricas, hubo algunos falsos positivos de RAGAS.
Pero también hubo algunas fallas en preguntas que habían sido formateadas sin especificidad en el conjunto de datos sintéticos, como "¿cuántas publicaciones, por cierto, se usaron para el conjunto de datos?" o "¿en cuántos conjuntos de datos probaron?"
Hubo algunas preguntas que el optimizador de consultas ayudó al eliminar la entrada ruidosa. Pero me di cuenta demasiado tarde de que las preguntas que se habían generado estaban demasiado dirigidas a pasajes específicos.
Esto significaba que empujarlos hacia adentro tal como estaban funcionaba bien en el lado de recuperación. Es decir, las preguntas con nombres específicos (como “¿cómo se compara CLÁUSULA…”) coincidían bien con los documentos y el optimizador de consultas simplemente empeoró las cosas.
Hubo ocasiones en las que la optimización de la consulta falló por completo debido a la forma en que se formularon las preguntas.
Por ejemplo, la pregunta: "¿cómo funciona la fase de verificación previa en ac-rag y por qué es importante?" donde la búsqueda directa encontró el documento AC-RAG directamente, ya que la pregunta se generó a partir de allí.
Al pasarlo por el juez A/B, los resultados favorecieron el proceso avanzado mucho más que en el primer corpus.
El juez favoreció la concisión y la brevedad de la ingenuidad, mientras que favoreció la complejidad del proceso por su exhaustividad y exhaustividad.
La razón por la que vemos el aumento de victorias para el complejo proceso es que esta vez el juez eligió cada vez más "aspectos completos pero detallados" en lugar de "aspectos breves pero potencialmente faltantes".
Fue entonces cuando pensé en lo inútil que es la calidad de las respuestas como métrica. Estos jueces de LLM a veces tienen vibraciones.
En esta ejecución, no pensé que las respuestas fueran lo suficientemente diferentes como para justificar la diferencia en los resultados. Así que recuerde, usar un conjunto de datos sintéticos como este puede brindarle cierta información, pero puede ser bastante poco confiable.
Conjunto de datos de preguntas aleatorias
Por último, repasaremos los resultados del conjunto de datos aleatorio, que mostró resultados mucho más interesantes. Las métricas comenzaron a moverse con un margen más alto aquí, lo que nos dio algo en qué profundizar.
Hasta este punto no tenía nada que mostrar sobre esto, pero este último conjunto de datos finalmente me dio algo interesante en lo que profundizar.
Vea los resultados del conjunto de datos aleatorios a continuación.
En preguntas aleatorias, de hecho vimos una caída en la fidelidad y la relevancia de las respuestas para la línea de base ingenua. La relevancia del contexto era aún mayor, junto con la estructura, pero esto ya lo habíamos establecido para el complejo proceso en el artículo anterior.
Inevitablemente se producirá ruido en el complejo, ya que estamos hablando de 10 veces más fragmentos. La estructura de las citas puede resultar más difícil para el modelo cuando el contexto aumenta (o el juez tiene problemas para juzgar el contexto completo).
Sin embargo, el juez A/B le dio una puntuación muy alta en comparación con otros conjuntos de datos.
Lo ejecuté dos veces para comprobarlo, y cada vez favoreció al complejo sobre el ingenuo por un margen enorme.
¿Por qué el cambio? Esta vez hubo muchas preguntas que un pasaje no pudo responder por sí solo.
Específicamente, el complejo oleoducto obtuvo buenos resultados en cuestiones de compensación y comparación. El juez razonó “más completo” en comparación con el ingenuo oleoducto.
Un ejemplo fue la pregunta "¿Cuáles son las ventajas y desventajas de RAG híbrido versus gráfico de conocimiento para consultas vagas?" Naive tenía muchas afirmaciones sin fundamento (faltan métricas GraphRAG, HybridRAG, EM/F1).
En este punto, necesitaba entender por qué ganó y por qué Naive perdió. Esto me daría información sobre dónde estaban realmente ayudando las características sofisticadas.
Mirando los resultados
Ahora bien, sin profundizar en los resultados, no se puede saber completamente por qué algo está ganando. Dado que el conjunto de datos aleatorios mostró los resultados más interesantes, aquí es donde decidí centrarme.
Primero, el juez tiene problemas reales para evaluar el contexto más completo. Por eso nunca podría crear un juez para evaluar cada contexto frente al otro. Preferiría ser ingenuo porque cognitivamente es más fácil de juzgar. Esto es lo que hizo que esto fuera tan difícil.
Sin embargo, podemos señalar algunos de los verdaderos fracasos.
Aunque la métrica de alucinaciones mostró resultados decentes, al profundizar en ella, pudimos ver que el ingenuo conducto fabricaba información con más frecuencia.
Podríamos localizar esto observando las bajas puntuaciones de fidelidad.
Para darle un ejemplo, para la pregunta "¿Cómo pruebo los riesgos de inyección rápida si el texto incorrecto está dentro de los archivos PDF recuperados?" El ingenuo conducto llenó los vacíos en el contexto para proporcionar la respuesta.
Pregunta: ¿Cómo pruebo los riesgos de inyección rápida si el texto incorrecto está dentro de los archivos PDF recuperados? Respuesta ingenua: enumera los pasos estándar de prueba de inyección rápida (PoisonedRAG, instrucciones adaptativas, envenenamiento con múltiples saltos), pero sintetiza una receta de evaluación genérica que no está totalmente respaldada por las secciones específicas recuperadas e implícitamente llena los vacíos con el conocimiento previo. Respuesta compleja: deriva pasos de prueba directamente de las secciones de experimentos y modelos de amenazas recuperados, incluidos ataques activados por múltiples saltos, medición de sesgo de generación de texto único, ataques rápidos adaptativos e informes de tasa de éxito, manteniéndose dentro de lo que realmente describen los artículos citados. Fidelidad: Ingenuo: 0.0 | Complejo: 0,83 Qué pasó: a diferencia de la respuesta ingenua, no se trata de inventar ataques, métricas o técnicas de la nada. PoisonedRAG, ataques basados en disparadores, perturbaciones estilo Hotflip, ataques multisalto, ASR, DACC/FPR/FNR, PC1–PC3 aparecen en los documentos proporcionados. Sin embargo, el complejo oleoducto se está sobrepasando sutilmente y tiene un caso de inflación de alcance.
El contenido ampliado agregó las métricas de evaluación que faltaban, lo que aumentó la puntuación de fidelidad en un 87 %.
Sin embargo, el complejo oleoducto se sobrepasó sutilmente y tuvo un caso de inflación de alcance. Esto podría ser un problema con el generador LLM, donde debemos ajustarlo para asegurarnos de que cada afirmación esté explícitamente vinculada a un artículo y marcar la síntesis entre artículos como tal.
Para la pregunta "¿cómo comparo las indicaciones que obligan al modelo a enumerar las contradicciones explícitamente?" Una vez más, el ingenuo tiene muy pocas métricas y, por lo tanto, inventa métricas, invierte hallazgos y colapsa los límites de las tareas.
Pregunta: ¿Cómo comparo las indicaciones que obligan al modelo a enumerar las contradicciones explícitamente? Respuesta ingenua: Menciona MAGIA por su nombre y señala vagamente “conflictos” y “evaluaciones comparativas”, pero carece de mecanismos concretos. No hay una descripción clara de la generación de conflictos, ni una separación entre detección y localización, ni un protocolo de evaluación real. Llena los vacíos inventando pasos que suenan genéricos y que no se basan en los contextos proporcionados. Respuesta compleja: se alinea explícitamente con la metodología del artículo MAGIC. Describe la generación de conflictos basada en KG, conflictos de un solo salto versus múltiples saltos y 1 versus N, indicaciones de pocos disparos a nivel de subgrafo, indicaciones paso a paso (detectar y luego localizar) y las métricas de ID/LOC reales utilizadas en múltiples ejecuciones. También incorpora correctamente PC1-PC3 como componentes auxiliares del mensaje y explica su función, de acuerdo con las secciones citadas. Fidelidad: Ingenua: 0,35 | Complejo: 0,73 Qué pasó: El complejo ducto tiene mucha más superficie, pero la mayor parte está anclada a secciones reales del documento MAGIC y al trabajo de los componentes rápidos relacionados. En resumen: la respuesta ingenua alucina por necesidad debido a la falta de contexto, mientras que la respuesta compleja es detallada pero materialmente sustentada. Sobresintetiza y prescribe en exceso, pero en general se mantiene dentro del ámbito fáctico. La puntuación de fidelidad más alta está haciendo su trabajo, incluso si ofende la paciencia humana.
En el caso de lo complejo, sin embargo, sobresintetiza y prescribe en exceso, pero se mantiene dentro de la información fáctica.
Este patrón aparece en múltiples ejemplos. El proceso ingenuo carece de suficiente información para algunas de estas preguntas, por lo que recurre al conocimiento previo y a la finalización del patrón. Mientras que el complejo proceso se sobresintetiza bajo una falsa coherencia.
Esencialmente, lo ingenuo falla al inventar cosas, y lo complejo falla al decir cosas verdaderas de manera demasiado amplia.
Esta prueba trataba más bien de determinar si estas características sofisticadas ayudan, pero nos indicó que necesitábamos trabajar en el alcance de las reclamaciones: obligar al modelo a decir "El papel A muestra X; el papel B muestra Y", etc.
Puede profundizar en algunas de estas preguntas en la hoja aquí.
Antes de pasar al análisis de costo/latencia, también podemos intentar aislar el optimizador de consultas.
¿Cuánto ayudó el optimizador de consultas?
Como no probé cada parte de la canalización para cada ejecución, tuvimos que observar diferentes cosas para estimar si el optimizador de consultas estaba ayudando o perjudicando.
En primer lugar, observamos la superposición de fragmentos de semilla para el canal complejo versus el ingenuo, que mostró una superposición semántica del 8,3 % en el canal aleatorio, frente a más del 50 % de superposición para el canal de corpus.
Ya sabemos que todo el proceso ganó en el conjunto de datos aleatorio, y ahora también pudimos ver que aparecieron diferentes documentos gracias al optimizador de consultas.
La mayoría de los documentos eran diferentes, por lo que no pude determinar si la calidad se degradaba cuando había poca superposición.
También le pedimos a un juez que estimara la calidad de las consultas optimizadas en comparación con las originales, en términos de preservar la intención y ser lo suficientemente diversas, y ganó con un margen del 8%.
Una pregunta en la que destacó fue "¿por qué todo el mundo dice que RAG no escala? ¿Cómo están solucionando eso?".
Original: ¿por qué todo el mundo dice que RAG no escala? ¿Cómo está solucionando eso la gente? Optimizado (1): Retos de escalabilidad de RAG (híbrido) Optimizado (2): Soluciones para la escalabilidad de RAG (híbrido)
Mientras que una pregunta ingenua que funcionó bien por sí sola fue "¿qué configuraciones de recuperación ayudan a reducir la aguja en un pajar?" y otras preguntas que estaban muy bien formateadas desde el principio.
Sin embargo, podríamos deducir razonablemente que las preguntas múltiples y las preguntas más complicadas funcionaron mejor con el optimizador, siempre que no fueran de un dominio específico. El optimizador fue excesivo para preguntas bien formateadas.
También funcionó mal cuando los documentos subyacentes ya entendían la pregunta, en los casos en que alguien pregunta algo específico del dominio que el optimizador de consultas no entiende.
Puede consultar algunos ejemplos en el documento de Excel.
Esto nos enseña lo importante que es asegurarnos de que el optimizador esté bien adaptado a las preguntas que harán los usuarios. Si sus usuarios siguen preguntando con una jerga específica del dominio que el optimizador ignora o filtra, no funcionará bien.
Podemos ver aquí que está rescatando algunas preguntas y fallando en otras al mismo tiempo, por lo que necesitaría trabajo para este caso de uso.
vamos a discutirlo
Los he sobrecargado con una gran cantidad de datos, por lo que ahora es el momento de analizar la relación costo/latencia, discutir lo que podemos y no podemos concluir y las limitaciones de este experimento.
La compensación costo/latencia
Al analizar las compensaciones entre costo y latencia, el objetivo aquí es establecer cifras concretas sobre lo que cuestan estas características y de dónde provienen realmente.
El coste de funcionamiento de este oleoducto es muy reducido. Estamos hablando de $0,00396 por ejecución y esto no incluye el almacenamiento en caché. La eliminación del optimizador de consultas y la expansión de vecinos reduce los costos en un 41 %.
No es más que eso porque las entradas de tokens, lo que aumenta con el contexto agregado, son bastante baratas.
Lo que realmente cuesta dinero en este proceso es el reclasificador de Cohere, que utilizan tanto los ingenuos como los completos.
Para el oleoducto ingenuo, el reordenador representa el 70% del costo total. Por lo tanto, vale la pena analizar cada parte del proceso para determinar dónde se podrían implementar modelos más pequeños para reducir costos.
Sin embargo, con alrededor de 100.000 preguntas, estaría pagando $400,00 por el proceso completo y $280,00 por el ingenuo.
También está el caso de la latencia.
Medimos un aumento de +49 % en la latencia con el proceso complejo, que equivale a aproximadamente 6 segundos, impulsado principalmente por el optimizador de consultas que utiliza GPT-5-mini. Aquí es posible utilizar un modelo más rápido y más pequeño.
Para la expansión vecina, medimos que el aumento promedio fue de 2 a 3 segundos más. Tenga en cuenta que esto no escala linealmente.
4,4 veces más tokens de entrada solo agregaron un 24% más de tiempo.
Puedes ver el desglose completo en la ficha aquí.
Lo que esto muestra es que la diferencia de costo es real pero no extrema, mientras que la diferencia de latencia es mucho más notable. La mayor parte del dinero todavía se gasta en reclasificar, no en agregar contexto.
Lo que podemos concluir
Centrémonos en lo que funcionó, lo que falló y por qué. Vemos que la expansión vecina puede influir cuando las preguntas son difusas, pero cada tubería tiene sus propios modos de falla.
El hallazgo más claro de este experimento es que la expansión vecina se mantiene cuando la recuperación se vuelve difícil y un fragmento no puede responder la pregunta.
Hicimos una prueba en el artículo anterior que analizaba qué parte de la respuesta se generaba a partir de los fragmentos expandidos y, en preguntas de corpus limpio, solo el 22 % del contenido de la respuesta procedía de vecinos ampliados. También vimos que los resultados A/B aquí en este artículo mostraron un empate.
En preguntas complicadas, esto aumentó al 30% con un margen de 10 puntos para la prueba A/B. En preguntas aleatorias, alcanzó el 41% (usado según el contexto) con un margen de 44 puntos para la prueba A/B. Este patrón es innegable.
Lo que sucede debajo es una diferencia en los modos de falla. Cuando la ingenuidad fracasa, fracasa por omisión. El LLM no tiene suficiente contexto, por lo que da una respuesta incompleta o fabrica información para llenar los vacíos.
Vimos esto claramente en el ejemplo de la inyección rápida, donde los ingenuos obtuvieron una puntuación de 0,0 en fidelidad porque se extralimitaron en los hechos.
Cuando el complejo falla, falla por la inflación. Tiene tanto contexto que el LLM sobresintetiza y hace afirmaciones más amplias de lo que respalda cualquier fuente única. Pero al menos esas afirmaciones se basan en algo.
Las puntuaciones de fidelidad reflejan esta asimetría. Naive toca fondo en 0,0 o 0,35, mientras que los peores casos de complejo todavía rondan 0,73.
Es más difícil llamar al optimizador de consultas. Ayudó en el 38% de las preguntas, perjudicó al 27% y no hizo ninguna diferencia en el 35%. Las victorias fueron dramáticas cuando ocurrieron, rescatando preguntas como "¿por qué todos dicen que RAG no escala?" donde la búsqueda directa no arrojó nada.
Pero las pérdidas tampoco fueron grandes, como cuando la redacción del usuario ya coincidía con el vocabulario del corpus y el optimizador introdujo una deriva.
Esto probablemente sugiere que usted querrá ajustar el optimizador cuidadosamente para sus usuarios, o encontrar una manera de detectar cuándo es probable que la reformulación ayude o perjudique.
En cuanto a costo y latencia, los números no fueron los que esperaba. Agregar 10 veces más fragmentos solo aumentó el tiempo de generación en un 24% porque leer tokens es mucho más barato.
El verdadero generador de costos es el reranker, que representa el 70% del total del ingenuo oleoducto.
El optimizador de consultas aporta la mayor latencia, con casi 3 segundos por pregunta. Si estás optimizando la velocidad, ahí es donde debes buscar primero, junto con el reclasificador.
Por lo tanto, más contexto no significa necesariamente caos, pero sí significa que es necesario controlar el LLM en mayor medida. Cuando la pregunta no necesita tanta complejidad, el canal ingenuo prevalecerá, pero una vez que las preguntas se vuelven difusas, el canal más complejo puede comenzar a ejercer su influencia.
Hablemos de limitaciones
Tengo que cubrir las principales limitaciones del experimento y con qué debemos tener cuidado al interpretar los resultados.
La obvia es que los jueces de LLM funcionan con vibraciones.
Las métricas avanzaron en la dirección correcta en todos los conjuntos de datos, pero no confiaría lo suficiente en las cifras absolutas como para establecer umbrales de producción.
El corpus desordenado mostró un margen de 10 puntos para complejo, pero, sinceramente, las respuestas no fueron lo suficientemente diferentes como para justificar esa brecha. Podría ser ruido.
Tampoco aislé lo que sucede cuando los médicos realmente no pueden responder la pregunta.
El conjunto de datos aleatorio incluía preguntas en las que no sabíamos si los artículos tenían contenido relevante, pero traté los 66 de la misma manera. Aunque busqué entre los ejemplos, aún es posible que algunas de las victorias del complejo oleoducto se debieran a ser mejor en admitir la ignorancia en lugar de ser mejor en encontrar información.
Finalmente, probé dos características juntas, optimización de consultas y expansión de vecinos, sin aislar completamente la contribución de cada una. El análisis de superposición de semillas nos dio alguna señal en el optimizador, pero un experimento más limpio las probaría de forma independiente.
Por ahora, sabemos que la combinación ayuda en preguntas difíciles y que el costo es un 41% más por consulta. Que esa compensación tenga sentido depende enteramente de lo que realmente pregunten los usuarios.
Notas
Creo que podemos concluir de este artículo que hacer evaluaciones es difícil, y es aún más difícil poner un experimento como este en papel.
Ojalá pudiera darte una respuesta clara, pero es complicado.
Sin embargo, personalmente diría que inventar es peor que ser demasiado detallado. Pero aún así, si su corpus está increíblemente limpio y cada respuesta generalmente apunta a un fragmento específico, la expansión vecina es excesiva.
Esto simplemente le indica que estas características sofisticadas son una especie de seguro.
Sin embargo, espero que haya sido informativo, déjame saber lo que piensas conectándote conmigo en LinkedIn, Medium o a través de mi sitio web.
❤
Recuerda que puedes ver el desglose completo y las cifras aquí.