Quando li o artigo do Sarang Sanjay Kulkarni no blog do Martin Fowler, fiquei com uma reação dividida. Por um lado, é dos case studies técnicos mais honestos sobre agentic AI em produção que já vi. Por outro, mostra como o fosso entre um protótipo que “funciona” e um sistema que realmente está em produção é enorme.
O PRINCE (Preclinical Information Center) da Bayer com a Thoughtworks não é um chatbot com RAG bem feito. É uma plataforma que integra décadas de relatórios de segurança de estudos farmacêuticos — documentos que, se mal interpretados, podem atrasar aprovações de medicamentos.
Para mim, o mais valioso não é a arquitetura (que é impressionante). É verem o que falhou, o que removeram, e como iteraram. A maior parte dos artigos técnicos omite essa parte.
O Desafio: O Labirinto de Dados Pré-Clínicos
A Bayer, como qualquer grande farmacêutica, acumulou décadas de dados de estudos pré-clínicos. O problema é que estes dados estão:
- Fragmentados por dezenas de sistemas e repositórios diferentes
- Maioritariamente não estruturados — PDFs de relatórios de estudo com décadas, alguns digitalizados
- Incompletos nos metadados — as migrações de sistema ao longo dos anos deixaram metadados estruturados imprecisos
Os métodos tradicionais de pesquisa por keywords (com lógica Boolean) simplesmente não funcionam para perguntas como “houve sinais de toxicidade hepática em estudos com este composto em ratos?”.
A Solução: PRINCE
O PRINCE nasceu como um portal unificado para metadados de estudos pré-clínicos. Ao longo do tempo evoluiu em três fases:
Search (Fase 1)
Consolidar silos de dados internos numa interface pesquisável, focada em metadados estruturados. Filtros, pesquisa por campos, resultados previsíveis.
Ask (Fase 2)
Introduzir um sistema de perguntas-respostas baseado em RAG (Retrieval-Augmented Generation). Os investigadores podiam finalmente fazer perguntas em linguagem natural e obter respostas baseadas no conteúdo dos PDFs.
Do (Fase 3 — Atual)
A fase atual. O PRINCE é um assistente de pesquisa ativo, capaz de executar tarefas complexas com múltiplos agentes especializados, orquestrar workflows complexos e ajudar a redigir documentos regulatórios.
A Arquitetura Técnica
O sistema é um workflow orquestrado com LangGraph, servido via FastAPI. A interface é React. Vamos aos detalhes.
Stack principal
| Componente | Tecnologia |
|---|---|
| Orquestração | LangGraph |
| Backend API | FastAPI |
| Vector store | OpenSearch |
| Dados estruturados | Amazon Athena |
| Estado do workflow | PostgreSQL (LangGraph checkpointer) |
| Estado da aplicação | DynamoDB |
| Observabilidade | Langfuse |
| Modelos LLM | OpenAI, Anthropic, Google + open-source |
| Frontend | React |
O Fluxo Multi-Agente
O workflow do PRINCE não é um único prompt gigante. É uma sequência de agentes especializados, cada um com o seu contexto específico:
- Clarify User Intent — Desambiguação da pergunta do utilizador
- Think & Plan — Process reflection: o sistema pensa antes de agir
- Researcher Agent — Recolha de informação (RAG + Text-to-SQL)
- Reflection Agent — Data reflection: verifica se os dados são suficientes
- Writer Agent — Síntese e formatação da resposta final
Clarify User Intent: A Primeira Barreira
Quando um utilizador pergunta “mostra-me os estudos de toxicidade”, o sistema não sabe se é toxicologia, farmacologia, ou outra área. Em vez de tentar adivinhar e falhar, o PRINCE faz perguntas de clarificação.
Isto é context engineering na prática: o sistema não envia toda a informação disponível para o LLM. Em vez disso, restringe o domínio antes de começar a pesquisar.
Uma otimização em curso: seleção de domínio ao nível da UI, onde o utilizador pode pré-selecionar as fontes de dados relevantes, e o sistema sugere as mais prováveis baseado na intenção da pergunta.
Think & Plan: O Espaço para Pensar
O passo Think & Plan é onde o sistema reflete sobre o processo — não sobre os dados. É uma técnica inspirada no Think tool da Anthropic.
Porque é que isto é importante? Para mim, esta é a parte mais subestimada do design de sistemas agentic: dar ao modelo espaço para pensar antes de agir. A maioria dos sistemas salta diretamente para a ação e depois lida com as consequências.
Inicialmente o PRINCE tinha duas ferramentas: RAG e Text-to-SQL. À medida que integraram mais domínios, o número de ferramentas cresceu significativamente. E várias sobrepunham-se em funcionalidade.
Ter um passo dedicado para o modelo pensar sobre qual ferramenta usar (em vez de decidir na hora) melhorou drasticamente a precisão da seleção de ferramentas.
O Think & Plan faz process reflection: avaliar se o workflow está no caminho certo, se a trajetória leva ao objetivo do utilizador, e como ajustar a estratégia.
O Researcher Agent
Este é o agente que realmente vai buscar a informação. Usa duas estratégias principais:
RAG para Dados Não Estruturados
O pipeline de RAG é sofisticado:
- Keyword extraction — o LLM extrai termos relevantes da pergunta
- Metadata filter generation — gera filtros como
eq(study_id, T123456-2) - Query expansion — gera 5 variações semânticas da pergunta usando um modelo mais pequeno e rápido
- Hybrid retriever — combina pesquisa semântica (kNN) com pesquisa por keywords, com peso 0.7 para semântica e 0.3 para keywords
- Reranking — cross-encoder
bge-reranker-largeseleciona os top 7 chunks - Response generation with citation — o modelo final gera resposta com citações às fontes
Text-to-SQL para Dados Estruturados
Para perguntas que exigem filtros precisos, agregações, ou comparações numéricas, o sistema usa Text-to-SQL:
- O LLM recebe apenas o schema relevante para a pergunta (não o schema todo)
- Dynamic few-shot prompting — exemplos de queries complexas são recuperados de uma vector store baseada na similaridade semântica com a pergunta atual
- O SQL gerado é validado (apenas SELECT é permitido)
- Se a query falha, o erro + contexto são passados ao LLM para corrigir (até 3 tentativas)
O Reflection Agent: Validação de Dados
Enquanto o Think & Plan faz process reflection, o Reflection Agent faz data reflection: verifica se os dados recolhidos são suficientes para responder à pergunta.
Se não forem suficientes, gera perguntas específicas para orientar a próxima iteração de pesquisa. Se forem suficientes, passa ao Writer Agent.
Isto dá ao PRINCE três loops de reflexão complementares:
| Tipo de Reflexão | O que verifica | Feito por |
|---|---|---|
| Process reflection | O workflow está no caminho certo? | Think & Plan |
| Data reflection | Os dados são suficientes? | Reflection Agent |
| Draft reflection | A resposta está completa? | Writer Agent (loop interno) |
O Writer Agent: Síntese com Qualidade
O Writer Agent não descobre informação nova. Recebe o contexto do Researcher, assegura que cada afirmação tem citação para o chunk original, e respeita os requisitos de formatação (tabelas, bullet points, secções).
Para respostas complexas pode fazer um loop interno de revisão: escreve, verifica secções em falta ou tabelas inconsistentes, e reescreve.
Trust Through Transparency
Num ambiente regulado como o farmacêutico, a confiança não é negociável. O PRINCE implementa:
- Citações granulares — cada frase tem hover citation com link ao documento original, página e quote exata
- Passos intermédios visíveis — o utilizador vê o que o sistema está a fazer
- Contexto das fontes — links diretos para os chunks usados
Avaliação
O sistema tem dois tipos de avaliação: - Dataset evaluations — curadas por especialistas, correm quando há mudanças significativas. Métricas: Faithfulness, Answer Relevancy, Context Relevancy, Answer Accuracy - Live traffic evaluations — batch diário em queries reais, sem respostas de referência. Essencial para detetar alucinações
A ferramenta de observabilidade é o Langfuse, que dá traces detalhados de toda a produção.
Engineering for Resilience
Sistemas agentic são frágeis por natureza. Uma falha num passo pode estragar todo o workflow. Já me aconteceu — um agente morre a meio do processo e perdes tudo, tens de recomeçar do zero. O PRINCE resolve isto com:
- State persistence — o estado do workflow é persistido em Postgres. Se algo falha, recomeça do nó que falhou
- Built-in retries — retries automáticos em cada passo
- User-initiated retries — o utilizador pode retentar e o sistema continua do ponto de falha, não do início
- LLM fallbacks — se um modelo/provider falha após várias tentativas, muda automaticamente para outro (ex: OpenAI → Anthropic)
- Framework-level support — LangGraph tem suporte nativo para gestão de estado e recovery
Lições para Quem Quer Construir Sistemas Agentic
Se há lições claras deste case study, são estas:
- Não uses um prompt gigante. Divide o workflow em agentes especializados com contextos diferentes.
- Dá espaço ao modelo para pensar. Um passo dedicado de planeamento melhora a seleção de ferramentas.
- Separa a reflexão do processo da reflexão dos dados. São problemas diferentes e devem ser tratados por componentes diferentes.
- Context engineering importa mais do que contexto grande. Contexto maior não substitui contexto relevante.
- Persiste o estado. Workflows multi-passo falham. Se não persistires o estado, cada falha recomeça do zero.
- Fallbacks de LLM são obrigatórios. Nenhum modelo está sempre disponível. Ter alternativas é essencial em produção.
O que falta dizer
O PRINCE prova que sistemas agentic podem funcionar em produção na indústria farmacêutica, que é tudo menos permissiva. Mas também mostra o fosso entre o protótipo e o sistema real: persistência de estado, fallbacks de LLM, três níveis de reflexão, avaliação contínua, citações granulares. Nada disto vem de graça.
Para mim, a pergunta que fica é: quantos sistemas agentic que se dizem “em produção” têm este nível de engenharia? Suspeito que poucos. E isso devia preocupar-nos mais do que parece.
O artigo original está nos recursos abaixo. Vale a pena ler com atenção, especialmente a parte do que removeram e porquê — é aí que se aprende mais.
Comentários (0)
Nenhum comentário ainda. Seja o primeiro!
Deixar comentário