Um guia para desenvolvedores alerta que manter uma transação de banco de dados aberta durante toda a duração de um chat de IA pode corromper respostas e sobrecarregar o DBMS subjacente. A nota, voltada para equipes que constroem ferramentas baseadas em LLM, afirma que essa prática “não deve ser feita” e oferece quatro padrões de consistência de curta duração em seu lugar.

Por que o aviso é importante

Assistentes baseados em LLM frequentemente fazem uma série de perguntas de acompanhamento: eles leem um registro, solicitam um detalhe e, em seguida, pedem um total. Se os dados subjacentes mudarem entre essas etapas, o assistente pode retornar valores contraditórios — uma resposta estará errada. A solução tentadora é abrir uma única transação no início da conversa e mantê-la viva até o fim do chat. Na prática, essa abordagem retém versões de linhas, enche o tempdb, mantém bloqueios (locks) e interfere no pool de conexões.

O que leva a transações de longa duração

  • Prompting de múltiplos turnos – LLMs normalmente geram vários prompts antes que o usuário veja uma resposta.
  • Chamadas de ferramentas que acessam o banco de dados – Cada turno pode invocar um procedimento armazenado, um SELECT ou um UPDATE.
  • Escopo de transação não controlado – Desenvolvedores às vezes envolvem todo o chat em um bloco BEGIN…COMMIT, assumindo que isso garante a consistência.

Quando o chat se estende, o mecanismo do banco de dados deve reter as versões originais das linhas para que a transação veja uma visão estável. Essas versões ficam no tempdb, consumindo espaço e E/S (I/O). Bloqueios mantidos pelo mesmo período impedem escritores concorrentes, e a conexão ociosa pode esgotar o pool, forçando novos chamadores a esperar por uma vaga livre.

Quatro padrões de curta duração

O guia recomenda tratar a consistência como uma preocupação por chamada de ferramenta, em vez de por conversa. Os quatro padrões são:

  1. Instruções em tempo real (Live statements) – Cada chamada é executada sob o nível de isolamento padrão, vendo apenas os dados que foram confirmados (committed) no momento da execução. Este é o modelo mais simples; o chamador aceita que os dados podem ter mudado desde o turno anterior.
  2. Transações delimitadas (Bounded transactions) – Um desenvolvedor agrupa um pequeno conjunto de instruções dentro de uma única transação curta que termina antes do próximo turno do LLM. Isso garante a atomicidade para aquele lote sem persistir além da chamada da ferramenta.
  3. Leituras de snapshot (Snapshot reads) – A operação começa com um timestamp de snapshot definido, fornecendo uma visão estável do banco de dados durante a duração da chamada. Todas as leituras dentro da chamada veem os mesmos dados, mesmo que ocorram gravações concorrentes.
  4. Relatórios materializados (Materialized reports) – A ferramenta lê de um conjunto de resultados pré-gerado e versionado que reflete o banco de dados em um ponto de corte conhecido. A paginação ou cálculos adicionais operam, então, sobre esse conjunto de dados congelado.

No SQL Server, verifique se READ_COMMITTED_SNAPSHOT está ativo. Não presuma que o nome conte a história toda.

Regras práticas para aplicativos baseados em LLM

  • Agrupe o que for necessário – Se uma pergunta exigir muitos valores, calcule-os em uma única chamada de ferramenta em vez de emitir consultas separadas que iniciam uma nova transação cada uma.
  • Paginação determinística – Ao apresentar resultados em várias páginas, use uma chave de ordenação estável, um cursor ou um conjunto de resultados materializado. Nunca mantenha uma transação aberta enquanto o usuário rola a página.
  • Retorne evidências – Juntamente com os dados, inclua metadados que tornem o modelo de consistência explícito: a classe de consistência, o horário de início do snapshot, o ponto de corte do relatório, o frescor dos dados, a contagem de linhas, a identidade do banco de dados e um ID de rastreamento (trace ID).
  • Realize testes de estresse com concorrência – Simule gravações concorrentes enquanto o LLM está gerando prompts e verifique se o aplicativo tenta novamente ou falha de forma graciosa.

A conclusão é clara: um chat de IA não deve ditar o tempo de vida de uma transação de banco de dados. Ao limitar o escopo da consistência a cada chamada de ferramenta, os desenvolvedores mantêm o banco de dados saudável, preservam o desempenho para todos os usuários e ainda fornecem ao LLM dados confiáveis o suficiente para responder com precisão.