13 Lições Aprendidas na Construção de Agentes de IA para Serviços Técnicos

Na Opero, construímos agentes, o tipo de voicebots e chatbots que a equipe técnica usa em campo ou no escritório enquanto se prepara para um trabalho. Eles são construídos com base na documentação técnica de fabricantes, laboratórios de engenharia, empresas de HVAC e equipes de serviço de campo.

Esses agentes não são demonstrações. Um técnico os utiliza quando uma máquina está quebrada.

Muitas das minhas primeiras crenças estavam incorretas. Algumas também foram caras. Estas são as 13 coisas que aprendi ao longo do caminho.

Significaria muito se isso for útil para alguém construindo seus próprios agentes.

A Pilha

Este é o software que usamos:

• Agente e API: Python, FastAPI
• Orquestração: LangGraph para o gráfico, LangChain para os componentes
• Observabilidade: Langfuse
• Recuperação: embeddings da OpenAI, Milvus (busca híbrida densa e esparsa), zerank-2 para reclassificação
• Dados estruturados: Postgres
• Modelos: Diferentes provedores com failover automático. Se um provedor der um erro de API durante a operação, enviamos a solicitação para um provedor diferente.
• Comunicações: chamadas telefônicas agentic, SMS e e-mail com Hail.
• Infraestrutura: servidores na Hetzner, armazenamento e alguns componentes de pipeline na AWS

Parte 1. Ingestão

Lição 1: Construa Seu Próprio Pipeline de ETL de Documentos

Começamos com uma plataforma comercial de processamento de documentos chamada "Unstructured".

A plataforma era fácil de começar. Tivemos um sistema em operação em menos de um dia. Plataformas comerciais são boas para isso.

Então encontramos problemas.

A qualidade da extração era baixa. A plataforma fornecia uma saída estruturada, mas a estrutura estava correta para o Unstructured, não para nós. Mudamos nosso sistema para concordar com o formato deles. Esta é a sequência incorreta. É um anti-padrão. Tivemos que torcer nosso pipeline para fazê-lo funcionar.

Então começamos a trabalhar com a Zeppelin (um grande revendedor da Caterpillar), e o primeiro documento que eles compartilharam tinha 8.000 páginas de documentação técnica densa. Desenhos, esquemas, backlinks que fazem referência a outras páginas, identificadores complexos, etc.

O pipeline no Unstructured falhou 20 vezes. Pagamos por cada falha.

Nessa época, tomamos uma decisão. O custo era um problema, mas o problema maior era diferente: nossa lógica de processamento de documentos estava em um sistema que não podíamos examinar, reparar ou melhorar.

Fizemos uma comparação das plataformas e bibliotecas disponíveis e optamos por uma biblioteca de código aberto chamada Docling. Construímos um protótipo em um fim de semana. O protótipo deu resultados melhores do que a plataforma comercial.

Continuamos a melhorar o pipeline. Agora está totalmente automático e os resultados são bons.

A lição não é "não use ferramentas comerciais". Comece com uma ferramenta comercial. Lance seu produto MVP. Aprenda suas verdadeiras necessidades. Mas mova componentes-chave da arquitetura, como o processamento de documentos, para seu próprio sistema o mais rápido possível.

O processamento de dados é a base de todas as outras funções. Você precisa de flexibilidade, controle de custos e a capacidade de reparar suas próprias falhas.

As lições 2 a 11 são possíveis apenas porque controlamos o pipeline de ETL.

Você quer um artigo completo sobre o pipeline de ETL, a arquitetura, os modelos e a orquestração? Diga-nos e eu escreverei.

Lição 2: Possuir o Pipeline Reduziu Nossos Custos em 15 a 20x

O Unstructured cobrava 20 USD por 1.000 páginas no início. O preço então aumentou para 30 USD.

A precificação por página não reflete o custo real. O verdadeiro custo de processamento muda com o documento. Uma página de texto simples e uma página de desenhos de engenharia rotacionados não são equivalentes. Mas o provedor cobra o mesmo preço pelas duas páginas.

Operamos nosso próprio pipeline por algumas semanas. Medimos o custo com documentos reais de clientes. Nosso custo foi 15 a 20 vezes menor.

Não usamos modelos de baixa qualidade para obter esse resultado. Usamos bons modelos. Operamos os modelos em nossa própria infraestrutura de GPU com nosso próprio roteamento.

Para uma pequena empresa, isso não é apenas uma melhoria — é meses de tempo extra.

Lição 3: A Qualidade da Extração Define o Desempenho Máximo do Sistema

Você não pode corrigir uma má extração com um recuperador melhor, um agente mais inteligente ou um modelo maior.

Uma ficha técnica tem um layout de chave-valor. Se a extração transforma esse layout em texto não estruturado, os dados são perdidos. Se a extração ignora uma página rotacionada, os dados são perdidos. Se uma tabela perde seu alinhamento de colunas, os dados são perdidos. Nenhum processo subsequente pode recuperar esses dados.

A documentação técnica frequentemente apresenta essas condições: páginas rotacionadas, tabelas densas, fichas técnicas com layout de chave-valor.