Costes, latencia y actualización en producción

Un servicio RAG llega a producción con 300 usuarios. Dos semanas después, la factura mensual alcanza cuatro cifras y la latencia mediana supera los cinco segundos en las horas punta. Nadie había calculado el coste por consulta, porque en desarrollo cada prueba costaba un céntimo de euro. Ese mismo mes, un documento se retira del sitio interno por un error jurídico; sigue en el índice vectorial y el sistema continúa citándolo durante tres semanas.

Estos dos problemas tienen una causa común: el prototipo no tiene ciclo de vida. Indexa una vez, responde unas decenas de veces y nada cambia. Un servicio en producción debe absorber documentos que evolucionan, documentos que desaparecen, picos de carga, y rendir cuentas de su coste. Estas restricciones no se añaden al final: determinan decisiones de arquitectura que resulta muy costoso rehacer a posteriori.

Calcular el coste por consulta

Descompón antes de optimizar. Una consulta consume tokens de entrada, tokens de salida, un embedding de la pregunta y, eventualmente, un reranking.

TARIFS = {                     # euros por 1 000 tokens, a ajustar
    "entree": 0.00015,
    "sortie": 0.00060,
    "plongement": 0.00002,
}

def cout_requete(jetons_contexte, jetons_question, jetons_reponse, reclassement_local=True):
    entree = (jetons_contexte + jetons_question + 250)   # 250 para las instrucciones
    total = (entree / 1000) * TARIFS["entree"]
    total += (jetons_reponse / 1000) * TARIFS["sortie"]
    total += (jetons_question / 1000) * TARIFS["plongement"]
    return total

unitaire = cout_requete(3000, 30, 300)
print(f"{unitaire*1000:.2f} € pour 1 000 requêtes")
print(f"{unitaire*300*20*22:.0f} € par mois pour 300 personnes, 20 requêtes par jour ouvré")