Quando equipes de engenharia devem adotar o Dust em vez de manter pipelines RAG proprietários

Construir um protótipo de geração aumentada por recuperação (RAG) é uma tarefa simples: com LangChain ou LlamaIndex, um modelo de embedding e um banco de dados vetorial como pgvector ou Pinecone, é possível indexar uma pasta de arquivos Markdown e obter respostas contextuais em poucas horas de um fim de semana. No entanto, sustentar um sistema de recuperação de conhecimento interno em produção para centenas de colaboradores técnicos e de negócios envolve uma realidade operacional completamente diferente.

Equipes de engenharia devem adotar o Dust quando o objetivo principal for a capacitação interna e a recuperação de conhecimento operacional distribuído entre ferramentas SaaS corporativas (Notion, Slack, Google Drive, Confluence e GitHub), sem comprometer engenheiros de plataforma seniores na manutenção contínua de conectores, sincronização de permissões e infraestrutura de busca.

Por outro lado, as equipes devem manter pipelines RAG proprietários quando a recuperação for o diferencial competitivo do produto comercial vendido aos clientes, exigir latências ultra-baixas com SLAs p99 inferiores a 100 milissegundos, demandar algoritmos customizados de busca híbrida ou embeddings multimodais próprios, ou operar em redes totalmente isoladas (air-gapped) proibidas de acessar LLMs em nuvem pública.

A parte oculta do iceberg: A realidade do "Dia 2" do RAG proprietário

Muitos líderes técnicos subestimam o Custo Total de Propriedade (TCO) de soluções RAG desenvolvidas internamente porque a criação inicial representa menos de 20% do esforço global. Os 80% restantes correspondem ao atrito operacional contínuo.

1. Instabilidade de conectores SaaS e fragilidade na ingestão

Conectar ferramentas SaaS corporativas não se resume a consumir uma API pontual:

• Limites de requisições (rate limits) e backoff exponencial: Slack e Notion impõem restrições severas durante varreduras em grandes workspaces, exigindo o desenvolvimento de filas distribuídas resilientes e estratégias de novas tentativas.
• Ciclo de vida de webhooks: Webhooks externos perdem eventos durante instabilidades de rede, falham ao detectar alterações de permissão em pastas aninhadas e sofrem com a expiração periódica de tokens OAuth.
• Processamento de formatos complexos: Extrair conteúdo de apresentações do Google Slides, bancos de dados do Notion, planilhas com múltiplas abas e PDFs digitalizados exige manutenção constante de bibliotecas de parsing e regras de particionamento (chunking).

2. Herança de permissões e risco de vazamento de ACL

A segurança no acesso ao conhecimento corporativo é crítica: um desenvolvedor não pode ter acesso a planilhas de remuneração da diretoria, e um analista de suporte não pode visualizar dados confidenciais restritos de clientes. Em uma arquitetura proprietária, mapear grupos do provedor de identidade (IdP) para listas de controle de acesso (ACL) em nível de documento em múltiplos sistemas exige criar um mecanismo complexo de sincronização contínua. Toda vez que as permissões de uma pasta no Google Drive mudam, os metadados vetoriais precisam ser atualizados instantaneamente. Qualquer falha na filtragem em tempo de consulta gera vazamentos graves de dados.

3. Latência de reindexação e fragmentos órfãos

Documentos de trabalho mudam diariamente. Em bancos vetoriais tradicionais, atualizar uma especificação técnica de 50 páginas exige remover fragmentos antigos, inserir novos e purgar dados órfãos. Se a sincronização falhar, o modelo gera alucinações baseadas em diretrizes obsoletas. Além disso, ao atualizar o modelo de embedding (por exemplo, de text-embedding-ada-002 para text-embedding-3-large), toda a base documental precisa ser reprocessada e reindexada sem interromper o serviço.

4. Rápida obsolescência de modelos e orquestração

O ecossistema de LLMs evolui mensalmente. Manter um pipeline próprio exige reescrever periodicamente o código de orquestração para suportar novas janelas de contexto, saídas estruturadas em JSON e parâmetros de raciocínio de fornecedores como OpenAI, Anthropic Claude, Google Gemini, Mistral e DeepSeek.

5. Suporte a interfaces multicanais

Engenheiros trabalham no Slack, terminal e GitHub; áreas de negócios usam navegadores web e sistemas de chamados. Uma solução própria força a equipe a desenvolver e sustentar bots para Slack, interfaces web com Server-Sent Events (SSE), janelas de citação de fontes e fluxos de autenticação.

O que o Dust entrega como plataforma gerenciada

O Dust foi concebido como um sistema operacional de agentes corporativos desenhado para eliminar o fardo da infraestrutura de busca e integração de conhecimento.

Conectores e fontes de dados totalmente gerenciados

O Dust oferece integrações nativas prontas para uso com Slack, Notion, Google Drive, Confluence, GitHub, Zendesk, Intercom, Snowflake e BigQuery.

• Ciclo de vida automatizado: Documentos ingeridos recebem um identificador exclusivo (document_id). Cada inserção funciona como um Upsert: atualizar um documento substitui automaticamente seus fragmentos antigos no índice vetorial subjacente.
• Pré-processamento e chunking: O sistema remove espaços desnecessários e particiona o texto respeitando limites seguros de tokens (max_chunk_size).
• Infraestrutura de embeddings: Utiliza por padrão o modelo text-embedding-3-large da OpenAI (com suporte a modelos personalizados no plano Enterprise). Em tempo de consulta, o Dust vetoriza a pergunta, recupera os trechos mais relevantes, agrupa os fragmentos por documento e classifica os resultados por pontuação de similaridade.

Governança via Spaces e modelo de permissões em duas camadas

Em vez de tentar replicar árvores frágeis de permissões por arquivo de múltiplos fornecedores, o Dust estabelece governança estruturada por meio de Spaces (Espaços):

• Espaços Abertos (Open Spaces): Acessíveis a todos os membros do workspace, ideais para manuais técnicos, documentações públicas e normas gerais. Inclui o espaço padrão imutável Company Data.
• Espaços Restritos (Restricted Spaces): Acessíveis apenas a usuários autorizados ou grupos provisionados via SCIM pelo IdP corporativo (Okta, Microsoft Entra ID).
• Isolamento de acesso em duas camadas:
  1. Agente para Dados: Os agentes só consultam as fontes de dados vinculadas ao espaço em que foram configurados.
  2. Usuário para Agente: Usuários só conseguem visualizar, mencionar e executar agentes se forem membros dos espaços associados. Dados confidenciais nunca vazam em conversas para quem não possui permissão.
• Contas de serviço dedicadas: Para Google Drive e Notion, o Dust recomenda utilizar contas de serviço (como dust-admin@empresa.com), permitindo que a equipe de TI e segurança audite e selecione exatamente quais pastas e drives compartilhados devem ser sincronizados.

Roteamento dinâmico entre múltiplos modelos

O Dust unifica os principais provedores de IA sob uma interface consistente. As equipes podem alternar entre mais de 20 modelos de fronteira (OpenAI GPT-4o, Anthropic Claude 3.5 e 3.7 Sonnet, Google Gemini 1.5 e 2.0, Mistral Large, DeepSeek) sem alterar uma única linha de código. Administradores podem definir políticas de acesso e limites de esforço de raciocínio por grupo para manter os custos sob controle.

Extensibilidade técnica: APIs REST e servidores MCP

O Dust não é uma ferramenta no-code fechada:

• API para desenvolvedores e OpenAPI 3.0: Fornece endpoints para criar fontes de dados, inserir arquivos de texto e PDF, disparar execuções de agentes e transmitir respostas via streaming SSE.
• Suporte ao Model Context Protocol (MCP): Integra servidores MCP remotos e locais (preview), permitindo que agentes consultem microserviços internos, bancos de dados corporativos ou pipelines de CI/CD com segurança.
• Gatilhos e execuções agendadas: Permite acionar agentes por agendamento cron recorrente ou por webhooks acionados por ferramentas externas.
• Código aberto transparente: O código central do Dust está disponível no GitHub (dust-tt/dust), permitindo que arquitetos analisem os fluxos de indexação e evitem armadilhas de dependência tecnológica (vendor lock-in).

Comparativo direto: Pipeline proprietário vs. Plataforma Dust

Custo Total de Propriedade (TCO): A matemática financeira

Ao avaliar entre construir ou comprar, líderes de engenharia devem comparar o valor da assinatura de software com os salários dos profissionais envolvidos e o custo de oportunidade.

Cenário de referência: Empresa de tecnologia com 150 colaboradores (50 engenheiros)

Custo de construir e manter internamente

• Desenvolvimento inicial (4 meses): Dois engenheiros seniores construindo pipelines de dados, indexação vetorial, testes e integração com Slack. Custo com encargos (~US$ 150.000/ano por profissional): cerca de US$ 100.000.
• Manutenção recorrente (anual): Equivalente a 0,75 engenheiro dedicado a corrigir falhas de API, atualizar modelos de embedding e gerenciar bancos vetoriais: US$ 112.500/ano.
• Infraestrutura e chamadas de LLM: Banco vetorial gerenciado (Pinecone/Qdrant Cloud), nós de computação e chamadas de API: US$ 15.000 a US$ 25.000/ano.
• Custo total no primeiro ano: ~US$ 227.500 a US$ 237.500, com despesas anuais recorrentes superiores a US$ 125.000.

Custo de adotar o Dust

• Plano Business self-service: Assentos Pro a 24 €/mês (faturamento anual) para usuários padrão e Max a 120 €/mês para criadores intensivos, abastecidos por créditos de consumo.
• Plano Enterprise: Preços sob medida por volume com créditos compartilhados no workspace, conectores e servidores MCP ilimitados, SCIM, SLA e residência de dados nos EUA ou UE.
• Custo anual consolidado: Representa uma fração discreta do custo de um único engenheiro sênior.
• Ganho de oportunidade: Dois engenheiros seniores permanecem 100% dedicados aos produtos comerciais que geram faturamento real para a empresa.

Estrutura de decisão: Qual caminho seguir?

Adote o Dust se:

1. O conhecimento corporativo estiver disperso em ferramentas SaaS: Políticas, documentação e chamados estão espalhados entre Slack, Notion, Google Drive, Confluence e GitHub.
2. Especialistas de negócios precisarem criar agentes autônomos: Líderes de produto, suporte e operações puderem criar e testar agentes RAG via linguagem natural e MCP sem abrir chamados para desenvolvimento.
3. A capacidade técnica da equipe de engenharia estiver sobrecarregada: Não houver justificativa para alocar horas de engenharia na depuração de falhas de sincronização de terceiros.
4. Houver necessidade imediata de conformidade e segurança: A empresa precisar de certificação SOC 2, adequação ao GDPR, SSO via SAML e registros de auditoria desde o primeiro dia.

Mantenha um pipeline RAG proprietário se:

1. O pipeline for o produto comercial principal da empresa: Se o seu negócio vende uma plataforma de pesquisa jurídica orientada por IA, um buscador de diagnósticos médicos ou um analisador de repositórios onde os algoritmos de busca são a propriedade intelectual da companhia.
2. Houver requisitos extremos de latência (<100 ms): A aplicação demandar índices vetoriais em memória dedicados ou aceleração em hardware dentro de transações de missão crítica.
3. O ambiente for estritamente isolado (air-gapped): Normas governamentais ou do setor financeiro proibirem conexões externas e exigirem modelos puramente locais e offline (como vLLM/Ollama com Milvus local).
4. Houver dezenas de milhões de itens públicos com regras simples de acesso: Indexação de 50 milhões de produtos de catálogo aberto onde o custo por assento de SaaS não se aplica e as permissões de acesso são idênticas para todos os usuários.

O modelo híbrido: Abordagem pragmática

Muitas organizações de tecnologia de ponta adotam uma estratégia híbrida:

• Conhecimento corporativo geral gerenciado no Dust: O Dust é implementado para resolver onboarding técnico, busca de documentação interna, resolução de chamados e produtividade entre equipes.
• Sistemas proprietários conectados via MCP: Em vez de recriar um pipeline RAG completo, os engenheiros desenvolvem servidores MCP enxutos ou expõem APIs REST internas. O Dust assume a autenticação, a interface com o usuário, a alternância de modelos e a recuperação de texto, enquanto o time de engenharia concentra-se em fornecer dados internos de alta relevância.

Ao delegar o trabalho não diferenciado de conectores e permissões a uma plataforma gerenciada, a equipe de engenharia concentra seus esforços onde realmente gera valor de negócio.

Referências

• Dust Pricing: Business and Enterprise Plans for AI Agents
• Understanding Retrieval Augmented Generation (RAG) and the search method in Dust
• Chunks and Documents
• Datasources
• Access Controls and Permissions
• Spaces management
• Google Drive Connection
• Notion Connection
• The economics of multiplayer AI