Calculadora de costes RAG con Qwen3: embeddings y candidatos de reranking

En un sistema RAG que busca en una base de conocimiento de soporte, el coste de reordenar documentos puede depender más del número de pasajes candidatos que del tamaño del índice vectorial. En el presupuesto de este artículo, pasar de 20 a 100 candidatos multiplica por cinco el volumen de entrada del reranking. Pedir solo cinco resultados no significa, por sí solo, que el servicio haya evaluado únicamente cinco pasajes.

Esta guía combina los precios actuales de Orux para qwen3-embedding-8b y qwen3-reranker-8b con una calculadora Python que funciona sin conexión. Sirve para elegir un presupuesto inicial de candidatos y decidir qué medir después. Ejecutamos los cálculos localmente; no hicimos nuevas solicitudes a modelos ni pruebas de calidad de recuperación. Todas las cargas de trabajo son supuestos explícitos, no observaciones sobre tu aplicación.

Separa la indexación, los embeddings de consultas y el reranking

Un modelo de embeddings convierte texto en vectores comparables. Un reranker recibe una consulta y documentos candidatos y calcula su relevancia. Son tareas distintas: normalmente se genera el embedding de un documento sin cambios una vez, al construir el índice; el reranking ocurre cuando llega una consulta y ya se han seleccionado candidatos. Los modelos originales se describen en las fichas de Qwen Embedding y Qwen Reranker.

Mantén tres contadores para el presupuesto: tokens de documentos procesados al indexar o actualizar, tokens de consultas transformadas en embeddings y tokens de pares consulta-documento evaluados en el reranking. No multipliques todo el corpus por el número mensual de búsquedas salvo que realmente lo envíes completo cada vez. Tampoco cuentes la consulta una sola vez en una estimación por pares: acompaña a cada documento candidato.

El modelo de lenguaje que redacta la respuesta constituye un cuarto coste. El almacenamiento vectorial, la infraestructura de búsqueda, el tráfico y los impuestos aplicables tampoco están incluidos. Separarlos permite investigar una factura inesperada sin atribuir todos los cargos al modelo que genera la respuesta.

Precios actuales: compara la misma unidad

Estos son los precios públicos de entrada de Orux comprobados el 30 de octubre de 2026. Son precios del servicio, no tarifas oficiales de las API alojadas por los creadores ni una comparación de calidad. Un Credit equivale aproximadamente a $0.005. Un cero indica la configuración actual, sin prometer gratuidad permanente, capacidad ilimitada ni éxito en futuras solicitudes.

Desliza horizontalmente para ver toda la tabla.

Consulta las alternativas bge-m3 y bge-reranker-v2-m3. El precio cero justifica revisar la oferta actual, pero no demuestra que satisfagan tus necesidades de relevancia, latencia o idiomas. Comprueba acceso, límites y cotización antes de depender de una oferta.

Nuestra comparación del coste por solicitud LLM trata otra etapa: generar respuestas. La guía de precios de la API de DeepSeek también aborda generación de texto, no recuperación vectorial. Ninguna sustituye una tabla de precios de reranking.

Un presupuesto de búsqueda para soporte

Supongamos una base de 10,000 pasajes de 400 tokens cada uno. Durante el primer período se realizan 10,000 búsquedas con consultas de 40 tokens de media. Comparamos 20, 50 y 100 candidatos por búsqueda. Estas longitudes son datos de planificación: el idioma, el tokenizador, el formato y la composición documental pueden modificar el uso real.

La indexación inicial consume 10,000 × 400 = 4,000,000 tokens: 46.6668 Credits con la tarifa de embeddings Qwen. Las consultas consumen 10,000 × 40 = 400,000 tokens: 4.66668 Credits. Ambas etapas suman 51.33348 Credits. La indexación es un componente inicial, no un cargo recurrente por un corpus sin cambios.

La fórmula ilustrativa del reranking es búsquedas × candidatos × (tokens de documento + tokens de consulta). Con 20 candidatos son 10,000 × 20 × 440 = 88,000,000 tokens de entrada. Multiplicar 88 por 11.6667 da 1,026.6696 Credits. Es una estimación de capacidad, no un sustituto del uso medido ni de la liquidación del servicio, y excluye el formato adicional específico del modelo.

Desliza horizontalmente para ver toda la tabla.

El total incluye indexación inicial, embeddings de consultas y reranking, pero no generación de respuestas. Si el índice no cambia en el siguiente período, resta 46.6668 Credits. Si se actualiza parcialmente, sustituye esa cantidad por el coste de los tokens realmente procesados de nuevo. La tabla no debe presentarse como un resultado de latencia o precisión.

Bajo estos supuestos, pasar de 20 a 50 candidatos cuesta 2.5 veces más en reranking; pasar a 100 cuesta cinco veces más. Las proporciones proceden de la fórmula de carga, no de una mejora de calidad equivalente. El gráfico es un cálculo editorial, no una salida generada por el modelo.

Ejecuta la calculadora sin clave API

Guarda el código como budget.py y ejecuta python3 budget.py. Solo utiliza la biblioteca estándar de Python y no hace solicitudes de red. Decimal conserva la tarifa publicada sin convertir los importes mediante coma flotante binaria. Modifica la tarifa y la carga antes de aplicarlo a otra fecha o aplicación.

"""Scenario calculator, not a tokenizer or a measured API bill. No network calls."""
from decimal import Decimal
RATE = Decimal('11.6667')  # Credits per 1M input tokens, checked 2026-10-30
USD_PER_CREDIT = Decimal('0.005')
QUERIES, CHUNKS, DOCUMENT_TOKENS, QUERY_TOKENS = 10000, 10000, 400, 40

def credits(tokens):
    return Decimal(tokens) * RATE / Decimal(1000000)

def scenario(candidates):
    index_tokens = CHUNKS * DOCUMENT_TOKENS
    query_tokens = QUERIES * QUERY_TOKENS
    pair_tokens = QUERIES * candidates * (DOCUMENT_TOKENS + QUERY_TOKENS)
    rerank = credits(pair_tokens)
    total = credits(index_tokens + query_tokens) + rerank
    return pair_tokens, rerank, total, total * USD_PER_CREDIT

if __name__ == '__main__':
    assert credits(4000000) == Decimal('46.6668')
    assert scenario(20)[1] == Decimal('1026.6696')
    assert scenario(50)[1] / scenario(20)[1] == Decimal('2.5')
    assert scenario(100)[1] / scenario(20)[1] == Decimal('5')
    print('k | rerank tokens | rerank Credits | first-period Credits | USD equivalent')
    for k in (20, 50, 100):
        print(k, *scenario(k), sep=' | ')

Las aserciones comprueban la indexación y las dos proporciones entre candidatos. La salida reproduce la tabla. Esto verifica la calculadora, no la calidad de los modelos ni los tokens exactos que reportará una solicitud alojada. El siguiente paso operativo es comparar el primer registro real de uso con la estimación y reemplazar las longitudes medias supuestas.

El número de candidatos no es el número de resultados

El formulario actual de reranking de Orux incluye query, documents y el parámetro opcional top_n. El array de documentos determina los pasajes enviados para evaluación. Trata top_n como el número de resultados solicitado, no como sustituto de acortar la entrada para reducir costes. Para comparar 20 y 100 candidatos, prepara realmente dos conjuntos diferentes.

Una solicitud de embeddings utiliza input y el valor actualmente expuesto encoding_format: "float". Las opciones del modelo original y el formulario alojado son contratos distintos: no supongas que todas las funciones de una ficha están disponibles como parámetros en Orux. Utiliza el alias exacto y revisa el formulario vigente antes de integrar.

Para una consulta como «¿Cómo cambio el correo de facturación?», recupera primero candidatos de tus documentos autorizados y envía solo esos pasajes al reranker. Conserva los identificadores junto al texto para relacionar índices o resultados devueltos con sus fuentes. Una puntuación indica relevancia; no confirma vigencia, permisos del usuario ni suficiencia para responder.

Elige el conjunto más pequeño que conserve evidencia útil

Un reranker no puede recuperar un pasaje que nunca entró en su conjunto de candidatos. Reducirlo no es una optimización incondicional. Empieza con preguntas de soporte representativas y etiquetadas: nombres exactos de productos, expresiones ambiguas, cambios recientes de políticas y preguntas sin respuesta válida. Registra qué pasajes necesita una respuesta correcta antes de comparar configuraciones.

Para cada presupuesto, mide si el pasaje necesario se recuperó antes del reranking, su posición posterior y si la etapa de respuesta recibe suficiente evidencia. Registra por separado latencia y uso facturado. Si el pasaje falta antes de reordenar, investiga la recuperación y preparación documental; un reranker más grande o caro no puede puntuar documentos que no recibió.

Mantén estables la evaluación y la instantánea documental al comparar 20, 50 y 100 candidatos. De lo contrario, una actualización del corpus puede parecer una mejora del modelo. Aquí no hay un número universalmente ganador. Conserva la opción más barata solo si la cobertura de evidencia y la experiencia medidas siguen siendo aceptables. Repite la comprobación si cambian sustancialmente longitudes, tráfico o precios.

Preguntas frecuentes

Q.¿El total del primer período garantiza la factura de la API?

No. Es una estimación basada en carga explícita y precios de una fecha. Omite formato adicional, diferencias de tokenización, generación de respuestas e infraestructura. Úsala para comparar candidatos de forma consistente y contrasta las primeras solicitudes con los registros de uso y facturación antes de convertirla en previsión.

Q.¿Poner top_n en cinco cuesta lo mismo que evaluar cinco candidatos?

No lo supongas: la solicitud sigue incluyendo todos los documentos enviados para puntuar. Separa entradas candidatas de resultados devueltos. Para probar el efecto presupuestario de menos candidatos, reduce el array documents y verifica que la evidencia importante siga disponible.

Q.¿Hay que generar embeddings de documentos sin cambios en cada búsqueda?

No en el flujo basado en índices descrito aquí. Los embeddings se guardan y reutilizan hasta que cambie el contenido o la configuración. El embedding de consultas es otro paso. Cuenta altas, modificaciones y reindexaciones deliberadas, en lugar de multiplicar todo el corpus por cada búsqueda.

Q.¿El precio cero de BGE demuestra que es la mejor opción?

No. Solo establece una observación de precio en la fecha indicada. No dice nada sobre calidad de recuperación, acceso, latencia o tarifas futuras. Evalúa la alternativa con preguntas representativas y confirma su página actual antes de convertirla en una dependencia de producción.

Q.¿La calculadora llama a un modelo o consume Credits?

No. El ejemplo hace aritmética local con la biblioteca estándar, sin clave API ni conexión de red. Ilustra relaciones presupuestarias; no genera embeddings ni puntuaciones de relevancia. Una prueba posterior que llame a un modelo alojado es una operación independiente sujeta a sus precios y límites vigentes.

Precios comprobados el 2026-10-30. Fuentes: Qwen Embedding en Orux, Qwen Reranker en Orux, BGE Embedding en Orux, BGE Reranker en Orux y las dos fichas Qwen enlazadas arriba.