02 · IA aplicada em logística e compras
Assistentes de IA que trabalham dentro das regras
Dois assistentes, em logística e em compras, que respondem com base em documentos, consultam dados operacionais atuais e executam ações — enquanto a aplicação mantém o controle de identidade, permissões e regras de negócio.
- Empresa
- Grupo Inlog · Stratesys
- Cargo
- Desenvolvedor Full Stack Sênior
- Período
- 2024 — atual
- Stack
- LLMs
- RAG
- MCP
- NestJS
- pgvector
- Azure AI Search
- Zod
- SSE
01 · O problema
Quem opera um negócio passa muito tempo navegando entre telas para encontrar um status, consultar um documento ou fazer uma pequena alteração. Um assistente conversacional pode encurtar esse caminho — desde que nunca invente dados operacionais nem faça algo além do que o usuário pode fazer. Trabalhei nesse problema duas vezes: primeiro em uma plataforma de logística de coleta de resíduos, depois em uma plataforma de compras corporativas.
02 · O que eu fiz
- Logística: integrei o chat em Next.js aos serviços NestJS, com GPT-4o e respostas transmitidas via Server-Sent Events.
- Atuei diretamente no pipeline de recuperação — LangChain.js para processar e dividir documentos, embeddings da OpenAI e PostgreSQL com pgvector —, guardando metadados de origem e organização para rastreabilidade e filtragem.
- Implementei ferramentas MCP com o SDK oficial em TypeScript, como a consulta de status de rota. Os argumentos são validados com Zod; usuário e organização vêm da sessão autenticada, nunca do modelo.
- Compras: integrei Azure OpenAI e Azure AI Search ao backend NestJS, com busca híbrida por palavras-chave e vetores — nomes e códigos de fornecedores exigem correspondência exata tanto quanto as perguntas exigem significado —, filtrada por processo de compra e permissões do usuário.
- Desenvolvi uma ferramenta MCP de escrita que atualiza a justificativa de um rascunho de compra. Os argumentos são validados, o serviço confere permissão de edição e estado do processo, e o assistente só informa sucesso depois da confirmação do backend.
03 · A decisão principal
Separar conhecimento de estado atual — e manter a autoridade nos serviços.
Documentos passam pela recuperação. Status atual e ações passam por ferramentas apoiadas nas mesmas APIs que o produto já usa. O índice vetorial nunca é a fonte da verdade para dados operacionais, e o modelo nunca decide quem é o usuário ou o que ele pode alterar. Ele interpreta o pedido; a aplicação autoriza e executa.
04 · Diagrama interativo
Ilustração original da ideia de engenharia — não é uma captura do produto.
Um pedido, três caminhos possíveis
Dados atuais
- 01Ferramenta de leitura com argumentos validados
- 02O serviço confere a organização do usuário
- 03O status vem da API, não do índice
Os serviços garantem identidade, permissões e regras de negócio
Dados atuais: Ferramenta de leitura com argumentos validados. O serviço confere a organização do usuário. O status vem da API, não do índice.
05 · O que mudou
Os usuários passaram a consultar informações e concluir tarefas suportadas por conversa, sem navegar por várias telas. A recuperação foi validada com perguntas conhecidas, documentos esperados e respostas fundamentadas nos trechos recuperados. Adoção e tempo economizado não foram medidos formalmente — uma métrica que hoje eu definiria desde o primeiro dia.
06 · Escopo, com transparência
Minhas contribuições estão listadas acima. Em compras, a extração de documentos e a configuração inicial da indexação foram compartilhadas com o time. Os dois assistentes fazem parte de produtos maiores, construídos por muitas pessoas.