Custos, latência e atualização em produção

Um serviço RAG entra em produção com 300 usuários. Duas semanas depois, a fatura mensal chega a quatro dígitos e a latência mediana passa de cinco segundos nos horários de pico. Ninguém havia calculado o custo por requisição, porque, em desenvolvimento, cada teste custava um centésimo de euro. No mesmo mês, um documento é retirado do site interno por um erro jurídico; ele continua no índice vetorial e o sistema segue citando-o por três semanas.

Esses dois problemas têm uma causa comum: o protótipo não tem ciclo de vida. Ele indexa uma vez, responde algumas dezenas de vezes, e nada muda. Um serviço em produção precisa absorver documentos que evoluem, documentos que desaparecem, picos de carga, e prestar contas sobre seu custo. Essas restrições não se somam no final: elas determinam escolhas de arquitetura que são muito caras de refazer depois.

Calcular o custo por requisição

Decomponha antes de otimizar. Uma requisição consome tokens de entrada, tokens de saída, um embedding da pergunta e, eventualmente, um reranqueamento.

TARIFS = {                     # euros pour 1 000 jetons, à ajuster
    "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 pour les consignes
    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é")