Fine-tuning, RAG ou prompt: o compromisso na governação de dados

Há três formas de dar o seu domínio a um modelo generalista. Pode fazer fine-tuning, cozendo os seus dados nos pesos. Pode recuperar, indo buscar os seus dados em tempo de execução e entregando-os ao modelo como contexto. Ou pode instruir, descrevendo o seu domínio nas instruções de cada chamada. A maioria das equipas escolhe entre as três por capacidade e custo: qual torna o modelo mais exato, pelo menor dinheiro e esforço.

Só que, numa empresa regulada, essas são as perguntas secundárias. A principal é onde é que os seus dados regulados acabam por viver, porque esse único facto decide se consegue auditar o sistema, apagar os dados de uma pessoa a pedido, e atualizar o conhecimento de domínio sem um projeto de retreino. A escolha entre fine-tuning, RAG e prompt é uma decisão de governação de dados vestida de engenharia. Escolha só por exatidão e pode encurralar-se numa arquitetura em que um pedido de apagamento de rotina significa retreinar um modelo.

A forma de escolher bem é deixar de perguntar que técnica é mais capaz e começar a perguntar onde é que cada uma põe os seus dados regulados, e quanto lhe custa essa localização quando um regulador, um cliente ou o seu próprio processo de alterações bater à porta.

Onde vivem os dados: cozidos, recuperados ou em contexto

As três abordagens diferem num eixo que governa tudo o resto: a persistência e a localização dos seus dados regulados em relação ao modelo.

O fine-tuning coze os dados nos pesos. Pega em exemplos do seu domínio, muitas vezes com registos reais, e treina o modelo com eles. Depois do treino, essa informação fica difusa por milhares de milhões de parâmetros. Deixa de ser um documento para o qual consiga apontar. É um resíduo estatístico distribuído pelo modelo, e o modelo pode reproduzi-lo num output sem nunca o "recuperar", porque nunca foi guardado como algo recuperável. É a forma mais íntima de ensinar, e a menos reversível.

O RAG mantém os dados num repositório que o modelo lê em tempo de execução. O seu conteúdo regulado fica numa base de dados ou índice que é seu. No momento da consulta, a peça relevante é obtida e colocada na janela de contexto, usada para aquela resposta, e depois desaparece do ponto de vista do modelo. Os pesos do modelo nunca mudam. Os dados vivem onde os pôs, sob os seus controlos de acesso, e o modelo pede-os emprestados por instantes.

O prompt põe os dados na instrução, em contexto, por chamada. Nada persiste. O conhecimento de domínio é descrito ou fornecido no prompt, usado naquela única inferência, e descartado. É a opção mais transitória: o modelo aprende o seu domínio durante uma chamada de API e esquece-o completamente a seguir.

O mesmo objetivo, três perfis de governação de dados radicalmente diferentes. O resto da decisão decorre desta distinção.

Auditabilidade e direito ao apagamento: as perguntas que um regulador vai mesmo fazer

Duas obrigações expõem a diferença com nitidez, e ambas são rotina numa casa regulada.

Considere a auditabilidade. Um regulador pergunta: que informação usou o sistema para chegar a esta decisão, e consegue mostrar-ma? Com RAG, a resposta é limpa. Recuperaram-se estes documentos específicos, nesta versão do índice, e a decisão derivou deles; o trilho de evidências nomeia as fontes. Com prompt, é igualmente limpa: o contexto foi montado a partir destes dados, aqui estão. Com um modelo afinado por fine-tuning, a resposta honesta é incómoda. A decisão apoiou-se em conhecimento difundido pelos pesos durante o treino, e não consegue apontar para o registo específico que a moldou. Consegue descrever o conjunto de treino; não consegue rastrear um output específico até um input específico. Para um processo em que cada decisão precisa de uma base inspecionável, isso é um problema estrutural, não uma falha de documentação.

Considere agora o direito ao apagamento. Uma pessoa exerce o direito a que os seus dados sejam apagados. Se o registo dela estava num repositório RAG, apaga o registo e desaparece das futuras recuperações, de imediato e de forma comprovável. Se só esteve em prompts, nunca foi persistido; não há nada para apagar. Mas se os dados foram cozidos num modelo afinado, apagá-los é genuinamente difícil. A informação está enredada nos pesos, e não há operação limpa para remover a contribuição de uma pessoa sem retreinar sem ela, ou sem aplicar técnicas de machine unlearning ainda em amadurecimento e difíceis de provar a um supervisor. Um direito que tem de honrar em dias pode colidir com um modelo que retreina em semanas.

Nada disto torna o fine-tuning errado. Torna-o um compromisso cujo custo total só aparece mais tarde, exatamente no momento em que uma organização regulada menos pode dar-se ao luxo de uma surpresa.

Custo de atualização: com que rapidez pode o seu conhecimento de domínio mudar?

Há um terceiro eixo prático, e é o que morde operacionalmente e não juridicamente: quanto custa mudar o que o modelo sabe?

O conhecimento de domínio num negócio regulado não é estático. Uma política é revista, um limiar muda, uma regra é substituída. A forma como cada abordagem absorve essa mudança difere em ordens de grandeza. Atualizar um corpus RAG é uma operação documental: substitui-se a fonte, reindexa-se, pronto, e a mudança está ativa na consulta seguinte. Atualizar um prompt é editar texto e reimplementar a instrução. Atualizar conhecimento que vive em pesos afinados significa uma nova corrida de treino, revalidação e uma entrega controlada de uma nova versão do modelo. As duas primeiras são horas. A terceira é um projeto.

É aqui que a desatualização se torna risco de governação em vez de incómodo. Se o seu conhecimento regulado muda mais depressa do que consegue retreinar, um modelo afinado que o codifica vai saindo de conformidade entre corridas de treino, e nada no seu comportamento o anuncia. O RAG e o prompt mantêm o conteúdo regulado de mudança rápida numa camada que consegue atualizar à velocidade a que as regras mudam de facto.

Um enquadramento de decisão para uma equipa regulada

Nada disto se reduz a "use sempre RAG". Reduz-se a fazer corresponder a técnica ao que os dados são e à forma como se comportam.

O enquadramento que aguenta perante um comité de risco é separar duas coisas de que o modelo precisa. Precisa de competências, a capacidade estável e geral de ler um documento, seguir um formato, raciocinar numa tarefa estruturada. E precisa de factos, o conteúdo específico, mutável e muitas vezes regulado sobre o qual raciocina. Ponha as duas em sítios diferentes.

O fine-tuning é defensável para ensinar competências duradouras e não sensíveis: um estilo de casa, um esquema de output, um padrão de raciocínio que não muda e não traz dados pessoais. É um mau sítio para pôr factos, e um sítio perigoso para pôr factos regulados, precisamente por causa da auditabilidade, do apagamento e do custo de atualização. Os factos regulados pertencem ao RAG, onde ficam inspecionáveis, apagáveis e atuais, sob controlo de acesso aplicado no momento da recuperação. E o prompt transporta o contexto transitório de cada chamada, que nem persiste nem precisa de persistir. A maioria dos sistemas regulados robustos usa as três deliberadamente, com uma regra clara sobre que tipo de informação pode viver onde, em vez de deitar a mão à que pareceu mais exata numa demonstração.

Por isso, a pergunta a resolver antes de escolher uma técnica não é "que abordagem torna o modelo mais exato?". É que dados regulados esta abordagem nos levaria a guardar, onde viveriam, e conseguimos auditá-los, apagá-los e atualizá-los à velocidade que as nossas obrigações exigem? Responda primeiro a isso, e a exatidão passa a ser uma escolha que faz dentro de um desenho seguro, em vez de a razão por que acabou num inseguro.

Se quiser mapear que parte do seu conhecimento de domínio pertence aos pesos, à recuperação ou ao prompt, marque uma reunião e traga-nos o processo com mais dados regulados.