Construir vs. Comprar para Infraestrutura de Conhecimento em IA: Capacidade Primeiro, Custo Depois

TL;DR

• O servidor MCP gerado automaticamente da Mintlify suporta apenas filtros de metadados integrados (versão, idioma); não tem conceito de campos personalizados como buying_signals ou personas — essa é uma diferença arquitetural, não uma funcionalidade ausente.
• RAG auto-hospedado custa de $80 a $250/mês em comparação com $350 a $500/mês para uma plataforma gerenciada em escala de equipe; o preço base do SaaS parece barato até você adicionar excessos de IA e assentos.
• Ferramentas de codificação de IA comprimiram a implementação para dias; a distribuição e a aprovação de TI ainda levam semanas a meses — esse custo não se comprime e a maioria das análises de construir vs. comprar o omite.
• A fragmentação hierárquica em vez da fragmentação plana mostra uma melhoria de 15 a 25% nas pontuações de fidelidade do RAG; a escolha do modelo de incorporação é uma otimização restrita contra as restrições do perfil de inferência do Bedrock KB, não uma classificação livre do MTEB.
• Pergunte primeiro sobre a capacidade — o padrão arquitetônico do SaaS se encaixa no caso de uso? — depois execute os números reais de custo, incluindo excessos, antes de decidir.

Quando eu estava construindo a camada de inteligência para o KB de campo da minha equipe, quase comprei a Mintlify.

A Mintlify é bem projetada. Ela entrega um servidor MCP gerado automaticamente em /mcp para cada site de documentos — zero configuração, ao vivo no dia em que você publica. Pesquisa integrada com Claude, geração automática de /llms.txt, implantações de pré-visualização de PR, um agente Autopilot que monitora repositórios conectados e redige atualizações de documentação como PRs. Cerca de $250 a $300/mês para um plano Pro. Sem infraestrutura para gerenciar.

A lista de recursos parecia exatamente o que eu precisava. Em vez disso, construí minha própria pilha — uma base de conhecimento personalizada com um armazenamento vetorial, um servidor MCP suportado por Lambda, um pipeline CI que exporta markdown para S3 e resincroniza em cada merge. Com uma ferramenta de codificação de IA, a implementação levou aproximadamente o mesmo tempo que configurar o SaaS teria levado. A decisão não teve nada a ver com o tempo de construção.

Este post é sobre o porquê. Não "por que sou especial" — mas o princípio por trás da decisão, que se generaliza para qualquer escolha de construção vs. compra de infraestrutura de IA.

O problema que as plataformas de documentos foram construídas para resolver

O problema subjacente é real. 62% das equipes que lidam com clientes dizem que seus materiais de referência estão consistentemente desatualizados. 54% das empresas usam mais de 5 ferramentas desconectadas para documentação e compartilhamento de informações. 42% das organizações citam "funcionários sobrecarregados e sem tempo para gestão do conhecimento" — não falta de ferramentas, mas falta de redução da fricção no caminho de escrita.

A solução tradicional — Highspot, Seismic, SharePoint, Confluence — não resolveu isso. Essas plataformas são filosoficamente opostas ao docs-as-code: proprietárias, baseadas em GUI, bloqueadas em plataforma, sem controle de versão. E mesmo assim, não resolveram o problema fundamental: 65% do conteúdo da empresa não é utilizado pelas equipes para as quais foi criado, e 38% dos líderes de capacitação citam conteúdo desatualizado como seu maior desafio.

Plataformas de documentos como a Mintlify representam uma melhoria genuína: markdown como fonte da verdade, versionamento baseado em Git, MCP para consumo de IA. Para documentação de desenvolvedores — referências de API, guias de SDK, tutoriais de integração — essa arquitetura é excelente.

A questão é o que acontece quando o caso de uso não é documentação de desenvolvedor.

A comparação de recursos perde a questão

A análise padrão de construir vs. comprar é uma tabela de recursos. Você lista o que precisa, verifica o que o produto cobre, calcula a lacuna. Se a lacuna é pequena, compra. Se a lacuna é grande, constrói.

Essa estrutura falha para a infraestrutura de IA porque trata lacunas de capacidade como diferenças de grau — o produto SaaS tem 80% do que você precisa, você só precisa fechar os últimos 20%. Isso geralmente é a estrutura certa para software empresarial. É a estrutura errada quando a lacuna de 20% é uma diferença arquitetural fundamental.

O servidor MCP gerado automaticamente da Mintlify suporta filtragem de metadados — mas apenas em atributos de documento integrados: versão (v1.2), idioma (en) e limite de pontuação de relevância. Não há campos de metadados personalizados. Sem buying_signals. Sem personas. Sem competitive_alternatives. Sem category. A superfície de filtro é o que faz sentido para documentação de desenvolvedores: "mostre-me os docs da API v2 em inglês." Não tem conceito de uma dimensão de inteligência de campo.

Meu caso de uso era uma camada de inteligência de campo. A questão de recuperação não é "encontrar páginas sobre X" — é "encontrar páginas que correspondem a um sinal de compra para uma persona específica avaliando uma categoria de produto específica." Isso requer pré-filtros de metadados personalizados estruturados na busca vetorial. Nenhuma quantidade de adição à superfície de filtro da Mintlify chega lá, porque essas dimensões de filtro não existem no modelo de dados da plataforma.

Essas não são alternativas à mesma capacidade. Elas são capacidades diferentes.

A questão não é "este SaaS cobre recursos suficientes?" A questão é "o padrão arquitetônico deste SaaS é o padrão que meu caso de uso requer?"

Sobre o que a decisão realmente se baseou

Três coisas tornaram a construção a escolha certa:

1. Governança. Um site interno de inteligência de campo com dados de contas, análise competitiva e sinais de compra vive dentro da infraestrutura da empresa ou não existe. A Mintlify é apenas SaaS — sem opção de auto-hospedagem. Isso a eliminou antes da comparação de recursos começar. Esta não foi uma decisão difícil. Se seu conteúdo tem restrições de classificação de dados, a localização do hosting não é uma variável. Pesquisas externas confirmam que esta é a principal razão legítima para construir: "Dados únicos, necessidades regulatórias ou requisitos de diferenciação competitiva não atendidos por fornecedores."

2. Arquitetura de recuperação. A lacuna não estava em um recurso — estava no modelo. O que eu precisava era de fragmentação hierárquica pela estrutura de cabeçalho, sidecars de metadados por página com campos estruturados personalizados, e consultas de pré-filtro que restringem a busca vetorial antes de ser executada. Isso requer uma arquitetura onde eu controle o esquema de metadados, a estratégia de fragmentação e os predicados de filtro. Isso não é um recurso ausente da Mintlify. É uma arquitetura de recuperação diferente construída para um caso de uso diferente.

3. O valor da conversa. Se você está em conversas com clientes explicando por que os sistemas de conhecimento de IA falham e como construir sistemas duráveis — ter construído um você mesmo é o artefato de credibilidade. "Nós construímos, aqui estão as decisões que tomamos, aqui está o que custou, aqui está o que desbloqueou" é uma conversa entre pares. "Nós usamos a versão SaaS" não é. Isso só se aplica quando a construção é genuinamente necessária para seu caso de uso real — não é um argumento para construir tudo.

A implementação técnica

O que realmente envolveu a construção:

Estrutura Markdown

Cada página segue uma convenção projetada para consumo de máquina, não apenas leitura humana. Três camadas estruturais:

---
title: [Título da página]
description: [Descrição da página]
---