Capítulo 10: Herramientas, búsqueda y RAG

Visión general#

Un asistente de documentación recibe una pregunta, busca en una base de datos vectorial y envía veinte pasajes al modelo. Los dos primeros contienen la respuesta; el resto están relacionados pero sobran. La búsqueda puede ser barata, pero el modelo sigue procesando cada token devuelto.

Los costes de RAG abarcan la ingesta, los embeddings, el almacenamiento, la recuperación, el reranking, el contexto añadido al prompt y la respuesta final del modelo. La búsqueda web de pago, el OCR y otras herramientas pueden sumar cargos aparte. Optimizar solo la consulta vectorial o solo el modelo de generación pasa por alto cómo interactúan los dos.

Práctica#

Contabiliza por separado los costes en tiempo de consulta y en tiempo de ingesta. Una base de conocimiento casi estática que recibe millones de preguntas tiene una economía distinta a la de un archivo que se actualiza a menudo y recibe pocas consultas.

No trates top_k, el número de pasajes recuperados que se envían al modelo, como un mando universal de calidad. A 500 tokens por pasaje, veinte pasajes añaden unos 10.000 tokens de entrada; cinco añaden 2.500. A 2 $ por millón de tokens de entrada sin caché, la diferencia es de 0,015 $ por petición, o 1.500 $ en 100.000 peticiones. Pero si la respuesta depende del pasaje ocho, recortar a ciegas a cinco es un falso ahorro.

Otra opción es recuperar de forma amplia y después filtrar con metadatos fiables, búsqueda híbrida o reranking antes de enviar la evidencia al modelo de generación. El reranking tiene su propio coste y solo compensa si recorta suficiente contexto o mejora suficiente la calidad.

No todas las tareas necesitan recuperación. Reformatear la respuesta que acabas de generar probablemente no requiere otra búsqueda vectorial, y el estado de un pedido conocido quizá se obtenga mejor directamente de la API de la aplicación que hace de fuente de verdad que deduciéndolo de documentos.

Para fijar top_k a partir de evidencia, registra dos cosas por petición: los pasajes recuperados, con su posición, y los pasajes que la respuesta usó de verdad. Las citas de la respuesta te dan la segunda lista de forma barata; para las respuestas sin citas, revisa una muestra a mano o con un evaluador. A partir de esos registros, sigue la posición del pasaje más profundo que necesitó cada respuesta, agrupada por tipo de consulta. Si las preguntas sobre políticas casi siempre tiran de los tres primeros pasajes mientras que las de resolución de problemas a menudo llegan a la posición ocho o nueve, da a cada tipo su propio top_k en lugar de enviar diez pasajes a todo. Vuelve a comprobar las cifras después de cualquier cambio en el chunking, el modelo de embeddings o el reranker, porque las posiciones se desplazan.

Ledgerline. El agente de investigación enviaba 20 pasajes recuperados con cada pregunta. Registrar qué pasajes citaban de verdad los informes mostró que la mayoría de los tipos de consulta nunca usaba nada más allá del octavo. Con top_k fijado por tipo de consulta, y las consultas amplias aún con 20 permitidos, la investigación baja de 640 $ a 560 $ al mes.

En profundidad#

El tamaño de los chunks afecta tanto a la calidad de la respuesta como al coste. Los chunks diminutos pueden separar una definición de su excepción, y los grandes pueden arrastrar secciones irrelevantes. Conserva los encabezados, las tablas, los bloques de código y las versiones de los documentos allí donde esos límites importen.

Si la respuesta es incorrecta, revisa lo que se recuperó antes de pasar a un modelo de generación mayor. Un modelo más grande no puede razonar de forma fiable a partir de un párrafo de una política que nunca le llegó. Una mala recuperación también tiende a provocar búsquedas adicionales y reintentos caros.

Un conjunto de referencia pequeño y estable que reutilizan todas las peticiones puede salir más barato como contexto de prompt en caché (Tokens, contexto y caché de prompts) que como un flujo de recuperación aparte. Una colección grande o que se actualiza a menudo suele beneficiarse de una recuperación selectiva.

Costes de los embeddings#

Los embeddings se pagan en dos momentos. La ingesta genera el embedding de cada chunk del corpus; el tiempo de consulta genera el de cada pregunta que llega. Los embeddings de consulta son cortos y crecen con el tráfico. Los de ingesta crecen con el tamaño del corpus y con la frecuencia con la que lo reconstruyes.

Los vectores de modelos de embeddings distintos no se pueden comparar, y unos límites de chunk nuevos producen chunks nuevos, así que cambiar el modelo de embeddings o el chunking supone volver a generar los embeddings de todo el corpus. Cada reconstrucción es un coste puntual, pero vuelve cada vez que cambias uno de los dos. Versiona el índice por modelo de embeddings y configuración de chunking, construye la nueva versión junto a la antigua y cambia el tráfico solo cuando pase tus comprobaciones de recuperación.

Ilustrativo: un corpus de 2 millones de chunks de 400 tokens cada uno supone 2.000.000 × 400 = 800 millones de tokens que procesar en cada reconstrucción completa, antes de cualquier consulta.

El almacenamiento y el tamaño del índice crecen con el número de chunks y las dimensiones de los vectores. Un vector float32 ocupa 4 bytes por dimensión.

Ilustrativo: con 1.536 dimensiones, un vector ocupa 1.536 × 4 = 6.144 bytes, y 2 millones de chunks necesitan 6.144 × 2.000.000 ≈ 12,3 GB de vectores en bruto antes de la sobrecarga del índice. Con 768 dimensiones, el tamaño en bruto se reduce a la mitad, a unos 6,1 GB.

Genera los embeddings de ingesta en lotes grandes en lugar de una petición por chunk; si tu proveedor ofrece procesamiento asíncrono con descuento, la ingesta encaja de forma natural (Inferencia por lotes y asíncrona). Guarda un hash del contenido por documento o por chunk y genera embeddings solo de lo que haya cambiado desde la última ejecución, para que una actualización diaria no vuelva a procesar la mayoría que no ha cambiado.

Los modelos de embeddings más pequeños a menudo bastan para la recuperación y reducen a la vez los costes de ingesta, de consulta y de almacenamiento. No lo des por hecho en ningún sentido: ejecuta tu propio conjunto de evaluación (Elige el modelo que necesita la tarea) y compara con qué frecuencia los pasajes que necesita la respuesta caen entre los primeros resultados.

Referencias: Búsqueda web de OpenAI, Búsqueda en ficheros de OpenAI, Precios de OpenAI (llamadas a herramientas y almacenamiento), Embeddings y dimensiones de OpenAI.