Apresentação: Conceção da camada de dados para agentes de IA: dos sistemas transacionais ao MCP e aos modelos semânticos

Transcrição

Fabiane Nardon: Chamo-me Fabiane. Trabalho na TOTVS. A TOTVS é provavelmente a maior empresa de tecnologia de que nunca ouviu falar. Esta empresa tem vindo a desenvolver sistemas empresariais nos últimos 40 anos no Brasil: SaaS, soluções no local, tudo o que há entre elas. Cerca de um quarto do PIB brasileiro passa pelos nossos sistemas. O Brasil não é um mercado pequeno, é a 10.ª maior economia do mundo. Quando começámos a criar agentes de IA, o nosso problema não era a falta de dados, era precisamente o contrário. Tínhamos dados a mais e nenhum deles estava preparado para ser acedido pelos agentes. Evoluímos muito na criação de agentes nos últimos anos. Dispomos agora de várias estruturas de agentes, orquestrações de agentes ou sistemas de avaliação. Estarão os nossos dados preparados para serem acedidos por um ciclo de raciocínio que consome muitos tokens, é sensível à latência e pode disparar centenas de consultas imprevisíveis em poucos minutos? Os dados que temos nos sistemas transacionais foram otimizados para serem acedidos por aplicações.

Os dados que temos no data lake foram otimizados para serem acedidos por analistas de dados ou painéis de controlo. Nenhum destes dados foi otimizado para ser acedido por agentes de IA. Depois, temos outro problema, porque quando falamos de agentes de nível empresarial, estamos a falar de sistemas transacionais dos quais normalmente se espera uma precisão de 99,99%, e estamos a tentar fazer o mesmo com agentes que utilizam raciocínio probabilístico. Nunca iremos ter o mesmo nível de precisão que temos nos sistemas transacionais, e temos de lidar com isso. Provavelmente, até a forma como os utilizadores interagem com os sistemas irá mudar quando implementarmos sistemas de IA empresariais. Nesta palestra, não vou falar sobre a programação de agentes nem sobre agentes pessoais que se podem criar utilizando o OpenClaw, por exemplo. Vou falar sobre agentes de nível empresarial, sobre como preparar os dados e como fornecer dados para este tipo de aplicações.

Modelos computacionais determinísticos e não determinísticos

O tipo de software que estamos a desenvolver atualmente, combinando IA com software tradicional, envolve a combinação de software determinístico. O software que desenvolvemos nos últimos 40 anos utilizava apenas modelos computacionais determinísticos, mas agora temos um modelo computacional não determinístico a surgir. Ao combinar estes dois, é claro, podemos ter aplicações muito mais poderosas. Não se trata de usar um modelo computacional em detrimento do outro. Trata-se de decidir que parte do software enviar para o modelo computacional determinístico e que parte deixar que a IA assuma para construir a aplicação. O sucesso da sua aplicação depende de saber onde traçar a linha divisória entre os dois modelos computacionais, o que deve enviar para a parte determinística do software e o que deve enviar para os modelos GenAI ou LLM. Esta decisão baseia-se nesta fórmula com três variáveis: precisão, segurança e custo. Estas três variáveis dependem, em grande medida, da forma como fornece dados a estes sistemas.

Precisão

Comecemos por falar de precisão, ou seja, como fazer com que os seus agentes dêem respostas melhores. A primeira questão, especialmente para nós — lembre-se de que a maioria dos nossos sistemas é on-premise e executa sistemas transacionais —, é decidir de onde obter os dados. A sua principal fonte de dados, claro, são os sistemas transacionais, o seu ERP, o CRM. O sistema que possui pode ser SaaS ou no local, mas é aqui que se encontra a sua principal fonte de dados. A simples ligação da IA ao seu sistema transacional pode trazer vários outros problemas, porque, normalmente, os sistemas não estão preparados para receber muitas consultas imprevisíveis, ou não têm capacidade suficiente para executar o processamento histórico necessário para preparar os seus dados. Ou podem conter dados incorretos com ruído, sendo necessário limpá-los antes de os enviar para o agente. Ou pode ser necessário executar uma pesquisa semântica, e estas bases de dados antigas, as bases de dados legadas, talvez não suportem a pesquisa semântica.

É necessária uma base de dados vetorial ou algo semelhante. Existem muitas razões pelas quais as pessoas decidem copiar dados para a plataforma de dados; assim, é possível fazer tudo o que for necessário na plataforma de dados, preparar os dados e, em seguida, o agente pode aceder aos dados a partir da plataforma de dados utilizando o MCP ou qualquer outro protocolo de acesso a dados que possa utilizar. A única questão aqui é que os dados na plataforma de dados estão sempre um pouco atrasados em relação ao sistema transacional; por isso, dependendo do fluxo de trabalho ou do que tiver de fazer, terá de aceder aos dados diretamente a partir do sistema transacional. Mais uma vez, não se trata de utilizar apenas um ou outro, mas sim de combinar estas duas fontes de dados, dependendo do fluxo de trabalho que se pretende resolver. Esta é a nossa recomendação na empresa: obter os dados do sistema transacional ou utilizar a plataforma de dados.

Deve recorrer ao sistema transacional quando precisar de gravar dados nesse sistema. Não vai gravar dados na plataforma de dados para depois os enviar para o sistema transacional. Se precisares de operações de gravação, recorre ao sistema transacional. Quando precisares de dados atualizados, se não puderes contentar-te com os dados desatualizados que tens na plataforma de dados, então tens de recorrer ao sistema transacional. Ou quando precisares de aplicar algumas regras de negócio que estão codificadas no sistema transacional. Por outro lado, deve recorrer à plataforma de dados quando puder utilizar dados desatualizados, quando precisar de processar dados históricos ou quando precisar de uma pesquisa semântica que a plataforma de dados possa fornecer e que o sistema transacional possa não disponibilizar. Quando precisa de enriquecer os seus dados, é muito comum combinar fontes de dados externas para melhorar a qualidade dos dados com o objetivo de aumentar a precisão. É assim que decide de onde obter os dados.

Vamos falar sobre como podemos preparar a sua plataforma de dados para a era da autonomia. Nos últimos anos, muitas empresas decidiram investir numa arquitetura de data mesh. A data mesh é uma arquitetura muito interessante, especialmente quando se tem muitos dados em vários departamentos da empresa. Porque, na data mesh, divide-se os dados e distribui-se por domínios. Cada domínio é especializado num domínio de negócio específico, num tipo específico de dados. Assim, dispõe-se de uma plataforma de dados self-service que todos utilizam, pelo que os analistas de dados de cada domínio podem concentrar-se no negócio e preparar os dados para servir o negócio, sem precisarem de se preocupar com a própria plataforma de dados. Este tipo de arquitetura tornou-se muito popular e resolveu muitos problemas de governação, especialmente para empresas que tentam organizar os seus dados. Na data mesh, existe um conceito muito importante que é crucial para a arquitetura de dados.

É o conceito de um produto de dados. Um produto de dados é um conjunto de dados preparado para ser acedido por terceiros. Tem de ter um proprietário de dados, ou seja, alguém responsável pela qualidade e pela manutenção desses dados. Tem de ter um contrato de interface estável, porque não se vai alterar o esquema dos dados que se partilham com os outros. Tem de ter boa documentação, facilidade de descoberta e um SLA de qualidade. Um produto de dados é como um microsserviço para dados. É uma forma muito boa de organizar os dados na sua empresa e de os partilhar com os outros.

Quando começámos a conceber as nossas ferramentas MCP, decidimos concebê-las para recuperar dados através do produto de dados. Cada ferramenta faz parte de um produto de dados. Isto significa que cada ferramenta também precisa de ter um proprietário, um contrato de interface estável, documentação, facilidade de descoberta e SLAs de qualidade. Estas ferramentas combinam-se muito bem com o produto de dados. Se fizer isto, obtém toda a governação que a data mesh proporciona apenas por fazer isso. Porque agora tem todas as suas ferramentas organizadas na sua data mesh por domínio. Sabe quem é o responsável por essa ferramenta. A plataforma de dados que a suporta pode fornecer-lhe estatísticas. Por exemplo, se esta ferramenta ainda é utilizada, como é utilizada, qual o seu desempenho e assim por diante. Porque quando temos demasiadas ferramentas numa empresa, isto pode tornar-se um pesadelo. Quem é o proprietário destas ferramentas? Quem é o responsável por elas?

Uma vez que temos tudo isto na data mesh e na nossa arquitetura de data mesh, que é suportada pela nossa plataforma de dados, se ligares as ferramentas MCP ao produto de dados, obténs essa governança automaticamente, apenas por utilizares a mesma arquitetura. Agora, em vez de recorrer a ferramentas genéricas como «get_schema» e «generate_query», dispomos de ferramentas que conhecem os dados e sabem como os recuperar de forma muito precisa e mais orientada para o negócio. Em vez de termos ferramentas genéricas, temos ferramentas específicas capazes de recuperar os dados. Uma vez que o proprietário da ferramenta conhece os dados de negócio e todas as regras, pode criar as melhores ferramentas para cada produto de dados. Mesmo assim, há outro problema comum a todas as empresas: um problema semântico. Se for a qualquer empresa e perguntar, por exemplo, o que é um cliente ativo? O departamento de marketing vai dizer uma coisa. O departamento financeiro vai dizer outra.

É muito difícil chegar a um consenso. Uma vez, trabalhei numa empresa em que passaram uma semana inteira em reuniões apenas a tentar definir um único conceito de «churn» com o qual todos pudessem concordar, e nunca chegaram a um acordo. O problema não é ter várias definições, é fingir que só existe uma. Isso não vai acontecer. Uma vez que existem estas múltiplas definições, isto pode funcionar bem com seres humanos. Se estiveres a falar com alguém do departamento de marketing e o tema for «cliente ativo», podes compreender — por seres humano e trabalhares nessa empresa há já algum tempo — o que «cliente ativo» significa para essa pessoa. Quando se faz isto com LLMs e agentes de IA, estes não têm essa sensibilidade. É preciso fornecer mais informações ao agente para que ele possa compreender melhor o conceito de que se está a falar.

Felizmente, existe uma tecnologia muito antiga que nos pode ajudar nisso, e chama-se Web Semântica. Em 2001, Tim Berners-Lee, o pai da Web, propôs um conjunto de normas para atribuir significado à informação que se pode encontrar na Web. Enquanto preparava esta palestra, voltei a ler o artigo que Tim Berners-Lee publicou na revista Scientific American em 2001, onde explicava o conceito da Web Semântica e como esta funciona. Se lerem o artigo, verão que ele descreveu um mundo onde os agentes podem comunicar entre si e compreender-se mutuamente, sendo capazes de organizar e resolver os problemas das pessoas. Neste caso, o agente estava a tentar agendar um tratamento médico. Quando reli este artigo 25 anos após a sua publicação, fiquei muito surpreendido por termos demorado 25 anos a chegar a um ponto em que é possível utilizar efetivamente esta tecnologia para resolver o problema semântico.

No artigo, ele afirma que o agente saberá tudo isto sem precisar de inteligência artificial à escala do C-3PO de «Star Wars». Ele foi um pouco otimista demais, porque demorámos 25 anos a chegar até aqui. Agora podemos usar esta tecnologia a nosso favor. A boa notícia é que, como demorámos 25 anos a chegar até aqui, os atuais modelos LLM foram treinados com 25 anos de exemplos destas tecnologias e conseguem compreender muito bem as tecnologias propostas para a Web Semântica, o que nos ajuda imenso. O que é a Web Semântica? Tim Berners-Lee propôs um padrão chamado RDF. A ideia do RDF é atribuir um identificador único a cada conceito que se tenha. No meu exemplo do cliente ativo, teria um identificador único para o cliente ativo na área do marketing e outro identificador para o cliente ativo na área financeira. Pode haver vários conceitos com o mesmo nome, mas cada um teria um identificador diferente, o que permite eliminar a ambiguidade entre os conceitos.

Depois, existem padrões para representar ontologias. A ontologia pode representar a relação entre os diferentes conceitos. Utilizando a ontologia e o RDF, é possível obter a semântica dos conceitos. Se fornecermos isto a um LLM, este pode criar um gráfico de contexto para agentes de IA, e assim obtemos a semântica dos nossos dados. Fiz o meu doutoramento em Tecnologias da Web Semântica para melhorar a inferência em sistemas inteligentes, e isso foi há 20 anos. Quando estava a fazer o meu doutoramento, o maior problema era criar a ontologia. Era muito trabalhoso criar uma ontologia para um domínio. Agora, se tiver documentação sobre os seus dados e estiver a utilizar um LLM, é muito fácil criar uma ontologia. Essa é uma das razões pelas quais demorámos tanto tempo a utilizar efetivamente estas tecnologias.

Deixando a ficção científica de lado, vamos ver como isto funciona na vida real. Este é um exemplo que fiz com o velho e bom ChatGPT, sem qualquer treino especial nem nada do género. Forneci ao ChatGPT três dados. Disse que a Acme comprou 10 servidores, a Beta comprou 50 licenças e a Gamma comprou 20 teclados. Depois, perguntei quais os clientes que compraram hardware. O LLM, com o conhecimento de que dispõe, afirmou que a Acme e a Gamma compraram hardware, porque consegue inferir que um servidor é provavelmente hardware. Se eu fornecer uma ontologia ao ChatGPT e simplesmente disser — o OWL é um dos padrões da Web Semântica para representar ontologias — «considere esta ontologia OWL ao responder às seguintes perguntas». Na ontologia, pode ver-se que mapeei a relação entre os conceitos e indiquei que «servidor» é uma subclasse de «serviço na nuvem». Estou a dizer ao LLM que isto não é hardware, é, na verdade, software, é um serviço.

Depois, quando voltei a apresentar os factos ao ChatGPT, em vez de me limitar a dizer que comprou servidores, utilizei um identificador único do conceito. Estou a dizer que a Acme comprou 10 servidores, mas este servidor de que estou a falar é o servidor com este identificador RDF aqui. Depois, voltei a fazer a mesma pergunta: «Que clientes compraram hardware?», e a resposta que o ChatGPT me deu foi esta. Podem ver que o ChatGPT conseguiu compreender muito bem a ontologia e dar-me a resposta certa. Nos últimos anos, realizaram-se vários estudos que compararam a utilização deste tipo de tecnologia com o LLM e como isso poderia melhorar a precisão. Por exemplo, este estudo aqui, que data de 2024, demonstrou que a adição de uma camada semântica baseada em ontologia melhorou a precisão das respostas do LLM em 40%. Existem estudos mais recentes que demonstraram uma precisão ainda maior, mas isso depende da forma como formata os seus dados ou do seu domínio.

É uma taxa muito boa quando comparada com a utilização apenas de um LLM simples com os seus dados. Agora, tem os seus produtos de dados com semântica ligados às ferramentas MCP e, ao fazer isto, é interessante porque posso devolver a semântica dos dados com base no meu produto de dados que conheço muito bem. Se ligar a ferramenta MCP ao produto de dados, posso devolver apenas a parte da ontologia que está relacionada com esse produto de dados, porque as ontologias numa grande empresa podem tornar-se realmente extensas, e não se quer enviar uma ontologia completa para o contexto, pelo que se filtra a parte necessária.

Provavelmente repararam que, nos últimos anos, as plataformas de dados se tornaram muito mais uma caixa de ferramentas do que uma única ferramenta. Há alguns anos, se tivessem uma plataforma de dados, provavelmente esta executaria apenas o Apache Spark, ou seria baseada no Athena ou no Hadoop, se forem da geração mais antiga. Agora é possível ver que várias plataformas de dados oferecem diferentes tipos de ferramentas, e isso faz sentido quando se fala de agentes de IA. Por exemplo, a nossa plataforma de dados tem três camadas. Uma camada de alta latência baseada no Apache Spark para o processamento em lote de ficheiros Parquet. Esta camada consegue lidar com grandes volumes de dados a um custo menor. Depois, precisávamos também de uma camada de latência média que, no nosso caso, se baseia no Google BigQuery, que também consegue lidar com grandes volumes de dados, mas tem um custo mais elevado, porque o BigQuery, se tiver um cartão de crédito com crédito ilimitado — o que não é o nosso caso —, pode ser muito rápido, mas também pode ser muito caro.

Para os agentes, o que precisávamos de fazer era disponibilizar uma camada de baixa latência na plataforma de dados — no nosso caso, baseada no Postgres e no DuckDB —, capaz de lidar com volumes de dados mais pequenos a um custo menor, mas tudo é orquestrado por uma interface de processamento unificada na nossa plataforma de dados. A razão para isso é que é necessário ter algo unificado, para que se possa criar os pipelines de dados no Spark da mesma forma que se criam no BigQuery ou no Postgres. Temos uma interface unificada para isso. Provavelmente repararam que alguns fornecedores de plataformas de dados anunciaram recentemente — creio que a Databricks anunciou que vai passar a suportar, ou já suporta, o Postgres também. Fazemos isto há mais ou menos dois anos, simplesmente porque precisávamos de servir os agentes e precisávamos de ter uma opção de baixa latência.

Por que é necessária uma baixa latência quando se fala de agentes de IA? Isto é interessante porque, anteriormente, quando se falava de plataformas de dados, normalmente os dados estavam na plataforma para processamento histórico, e os analistas de dados e cientistas de dados podiam criar painéis para utilizar esses dados em vez de recorrerem aos sistemas transacionais. Agora que estão a fornecer dados aos agentes através da vossa plataforma de dados, precisam de algo diferente. Continuam a ter de realizar o processamento histórico na plataforma de dados para preparar os dados, mas precisam de uma latência diferente ao disponibilizar esses dados. Quando falamos de baixa latência na plataforma de dados, são necessários dois tipos de baixa latência. A primeira é a baixa latência no processamento. É necessário garantir que, desde o momento em que os dados são recebidos na plataforma de dados até ao momento em que estão prontos para serem disponibilizados, esse tempo seja muito curto.

É preciso obter os dados, limpá-los, aceder aos mesmos e prepará-los no menor tempo possível, porque se pretende aumentar a atualidade dos dados. É claro que não será possível fazer isso com todo o processamento de dados que se tem. Isto faz sentido para o processamento de dados que se consegue realizar muito rapidamente. No que diz respeito aos dados, é necessário realizar um processamento enorme e muito complexo. Pode-se fazer esse processamento utilizando o Apache Spark, por exemplo, mas depois é preciso disponibilizar os dados para que sejam recuperados pelos agentes com um baixo nível de latência. Existem dois tipos de baixa latência: a baixa latência no processamento e a baixa latência na recuperação de dados. Quando estávamos a conceber a nossa camada de baixa latência, queríamos algo que fosse independente do fornecedor, para que pudéssemos utilizá-la em várias nuvens. Queríamos algo que fosse de baixo custo, rápido, fiável e que suportasse a pesquisa semântica.

Precisávamos também de garantir que, ao obter os dados nesta primeira etapa, assim que os dados fossem recebidos, o pipeline de transformação fosse acionado imediatamente. Este pipeline teria de funcionar muito rapidamente. Queríamos garantir que este pipeline fosse atómico, o que significa que os dados seriam consistentes. Quero garantir que, assim que receber estes dados aqui, isto seja acionado, isto seja acionado e eu tenha os dados prontos. Estamos a falar de tecnologias antigas. Existe uma tecnologia muito antiga que pode resolver este problema, e chama-se base de dados transacional. Utilizámos o Postgres para resolver o problema. Quando recebo os dados na primeira camada aqui, nos dados brutos, isto aciona um gatilho que executa uma série de procedimentos armazenados. Sei que não é nada sofisticado, mas funciona muito bem. Garanto que a transação vai terminar e que os meus dados estarão corretos no final do pipeline.

Este pipeline pode ser executado em milésimos de segundo ou segundos, dependendo do que tenho de fazer. Ao utilizar o Postgres e combiná-lo com as outras tecnologias da plataforma de dados, consigo fazer coisas muito interessantes. Por exemplo, posso ter dados do BigQuery em ficheiros Parquet, combinar esses dados utilizando o Apache Spark, guardar os dados numa tabela do Postgres, e tudo isto é transparente para os nossos utilizadores porque disponho de uma interface de processamento unificada. Se aceder à nossa plataforma de dados, pode criar quantos pipelines de dados quiser, bastando indicar qual o motor que pretende utilizar. Depois, pode combinar os dados para os disponibilizar para utilização pelos agentes no final. Ao utilizar isso, é possível combinar diferentes métodos de processamento. A camada de baixa latência está preparada para responder às perguntas dos agentes e suportar a pesquisa semântica através da base de dados vetorial no Postgres. Agora tenho o produto de dados com semântica, uma camada de baixa latência e as ferramentas MCP a funcionar por cima. As ferramentas são, na verdade, apenas consultas Postgres predefinidas e a plataforma de dados também fornece ferramentas para criar ferramentas na própria plataforma. Nenhuma das ferramentas é programada por uma ferramenta ou sistema separado. São criadas no interior da plataforma de dados, utilizando a nossa base de dados Postgres para fornecer acesso com baixa latência.

Segurança

Vamos falar sobre segurança. Existe uma abordagem muito popular na recuperação de dados de bases de dados, que consiste simplesmente em criar uma ferramenta, uma ferramenta genérica capaz de ler o esquema e deixar que o LLM escreva as consultas. Isto, claro, é muito flexível, mas também vulnerável à injeção de prompts. Existe uma abordagem mais segura — que é a que estamos a utilizar — que consiste em criar ferramentas com parâmetros para recuperar dados, com a segurança incorporada no código da ferramenta e sem permitir que o LLM gere o código. É claro que isto é menos flexível, porque os únicos dados a que o agente pode aceder são aqueles para os quais existe uma ferramenta capaz de os recuperar. Por outro lado, é menos vulnerável à injeção de prompts. Mesmo que faça isso, para várias ferramentas, preciso de saber quem está a chamar o agente. Só posso recuperar os dados que essa pessoa em particular pode ver.

O que fazemos é algo do género. O agente de IA acede ao provedor de identidade da empresa e inicia sessão. Provavelmente, há um interveniente humano neste processo. O provedor de identidade da empresa devolve o utilizador com sessão iniciada. Quando os agentes de IA contactam o servidor MCP, autenticam-se através do OAuth. No token OAuth, consta o utilizador com sessão iniciada. É possível propagar esse utilizador às vossas ferramentas e, em seguida, utilizar essa informação para filtrar os dados de que necessitam. Aqui, vou recuperar apenas os colaboradores de quem este utilizador com sessão iniciada é o chefe. Desta forma, utilizando a propagação de identidade, posso enviar esta informação para as nossas ferramentas. Isto também é feito automaticamente pela nossa plataforma de dados. Quando invocar o nosso servidor MCP, irá sempre obter o utilizador com sessão iniciada que recebemos do nosso fornecedor de identidade da empresa.

Custo

Vamos falar sobre a última variável, que é o custo. Há um ditado famoso no Brasil, de um escritor austríaco, que diz que o Brasil é o país do futuro. Nós, brasileiros, gostamos de acrescentar com um pouco de humor: «e sempre será». Há um aspeto em que o Brasil vive no futuro, e esse aspeto é a economia dos tokens. É que, quando se diz que o Claude Code custa apenas 100 dólares, para nós são 500 dólares. Isto equivale a um terço do salário mínimo brasileiro. O custo dos tokens afeta-nos muito antes de vos afetar. Tenho visto a surgir, nos últimos meses, discussões sobre o custo dos tokens. Nós vivemos isto há anos. O que é bom, porque a escassez torna-nos mais criativos. Também tivemos de lidar com os custos dos tokens. Os dados têm um impacto enorme nos custos dos tokens. Se utilizarem ferramentas mais precisas, devolverem menos dados inúteis e, sobretudo, incorporarem a lógica na ferramenta e não no prompt, podem poupar muitos tokens.

O que decidimos fazer foi criar vários servidores MCP para os agentes. Depois, deparámo-nos com um problema: pode acontecer que um determinado servidor MCP seja chamado uma única vez, outro seja chamado muitas vezes e vários servidores MCP nunca sejam chamados. Não há forma de saber isto antecipadamente, porque estamos a criar um agente e não é possível prever como as pessoas vão utilizá-lo, nem quais as chamadas que serão efetuadas. O que fizemos foi implementar um padrão que criámos, chamado MCP Fabric. A ideia é que, em vez de ter vários servidores MCP implementados, se tenha apenas um serviço capaz de servir vários servidores MCP virtuais. No nosso caso, fizemos isto utilizando o Spring AI. Cada servidor MCP é apenas um URL disponível num único serviço, pelo que é possível criar centenas de servidores MCP sem ter de arcar com os custos de implementar um serviço para cada um deles.

Com isto, esta é a arquitetura final da nossa plataforma de dados agentica. Temos diferentes camadas de latência: a camada de alta latência, a de média latência e a de baixa latência. Uma interface de processamento unificada que organiza tudo, para que não tenha de se preocupar com o que está a funcionar por trás. Na plataforma de dados, dispõe-se dos conceitos de produtos de dados, semântica, um criador de ferramentas e um criador de MCP. Tudo é criado dentro da plataforma de dados com o MCP Fabric para suportar muitos servidores MCP, OAuth e propagação de identidade para resolver questões de segurança. É fácil, rápido e muito económico criar novas ferramentas e servidores MCP. Pode fazer com que as ferramentas devolvam o que o LLM necessita e reduzir o consumo de tokens. Depois, podemos deparar-nos com um grande problema: ter demasiadas ferramentas no contexto. É claro que isto vai custar mais tokens. É assim que resolvemos a situação. Temos uma economia de tokens em camadas. Primeiro, decidimos criar um servidor MCP para cada agente.

Como é muito barato, muito fácil e muito rápido criar um servidor MCP, posso criar um para cada agente. Este servidor MCP terá apenas as ferramentas de que esse agente específico necessita. Depois, temos a pesquisa dinâmica de ferramentas. Vamos ver como isto funciona. Para cada agente, vou criar um servidor MCP. Se utilizasse o gateway MCP, seria praticamente a mesma coisa. Quando se tem um gateway MCP, o que se faz, na verdade, é selecionar as ferramentas que vão estar disponíveis neste servidor MCP virtual. Vais atribuir a um agente específico um servidor MCP que tenha apenas algumas das ferramentas de que precisas. Fizemos o mesmo, mas não utilizamos o gateway MCP. A plataforma de dados é o próprio gateway MCP. Podemos criar um servidor MCP para cada agente. Temos um subconjunto das ferramentas disponíveis para esse agente.

Mesmo assim, posso ter um problema, porque posso ter um agente específico, um servidor MCP específico que tenha muitas ferramentas, e isso pode encher o meu contexto muito rapidamente. Para resolver isso, temos também a pesquisa dinâmica de ferramentas. A ideia é que o agente vá contactar o servidor MCP e solicitar uma lista de ferramentas. O servidor MCP irá enviar todas as ferramentas disponíveis, com as respetivas descrições e tudo o mais. Em vez de as colocar no contexto, o agente irá enviar essas ferramentas para o serviço de pesquisa de ferramentas. O serviço de pesquisa de ferramentas terá essas descrições. Quando o agente precisar de algo para resolver um problema, irá chamar a função `search_tool` no serviço de pesquisa de ferramentas. O serviço de pesquisa de ferramentas irá devolver as ferramentas candidatas para resolver esse problema específico. Pode fazer isso utilizando pesquisa semântica, o Lucene ou expressões regulares, dependendo do problema em questão.

Assim, ficam as cinco ferramentas no contexto. Depois, o agente pode chamar a ferramenta. Realizámos um teste de desempenho utilizando a pesquisa dinâmica de ferramentas. Podem ver que este é o número de tokens utilizados com 10 ferramentas, 25 ferramentas, 50 ferramentas e 100 ferramentas. A barra laranja representa a pesquisa dinâmica de ferramentas, e a barra azul representa apenas a inclusão de todas as ferramentas no contexto. Como se pode ver, é possível poupar muitos tokens utilizando uma abordagem como essa. Outra coisa que se pode fazer para poupar alguns tokens é formatar a resposta da ferramenta de forma a utilizar menos tokens. Normalmente, o JSON é a melhor opção, especialmente em termos de precisão. É muito fácil de utilizar. É muito fácil de exportar. É muito bom para representar estruturas aninhadas. Também é muito detalhado, e utiliza-se muitos tokens. Se tiver apenas dados planos e devolver os resultados em CSV, pode poupar até 50% de tokens na resposta da sua ferramenta.

Há outro padrão que estamos a testar, que é bastante recente, chamado TOON. Tem este aspeto. O TOON também consegue representar dados tabulares mistos e dados complexos, e permite poupar entre 30% e 60% de tokens no resultado. O problema do TOON é que, por ser muito recente, por vezes não oferece a mesma precisão, uma vez que os LLMs não foram treinados com anos de dados em TOON, mas sim com anos de ficheiros CSV e JSON. Existem formas de o utilizar para melhorar a precisão, e isso é algo que estamos a testar neste momento.

Resumo

Eis um resumo das técnicas. Algumas podem ser utilizadas para melhorar a precisão, outras vão resolver questões de segurança e outras ainda serão utilizadas para reduzir o custo por token. Todas elas podem ajudar a fornecer melhores dados aos agentes de IA. Se integrar o seu código na parte determinística do seu software, este ficará mais preciso, mais seguro e mais económico. Por outro lado, a magia acontece na parte não determinística do software. É aí que o agente consegue compreender a linguagem natural, raciocinar com base em informação incompleta e lidar com ambiguidades. O sucesso do seu software dependerá de saber onde traçar a linha divisória entre estes dois modelos computacionais e de fornecer dados ao agente. É muito importante para que a magia aconteça.

Perguntas e Respostas

Participante 1: Existe a possibilidade de utilizarmos mecanismos de serialização mais comprovados? Por exemplo, desde que tenhamos o esquema — o esquema semântico —, não poderíamos utilizar um protocolo do tipo Protocol Buffer para compactar os dados e, ainda assim, manter todas as vantagens que obtemos com o JSON?

Fabiane Nardon: Sim, depende. Nunca testei o Protobuf nem nada semelhante. Depende da forma como o LLM vai conseguir interpretar e dar a resposta certa. Por exemplo, comparando o TOON com o JSON. O LLM normalmente compreende melhor o JSON, com menos ambiguidade do que o TOON. Depende do outro protocolo que estiver a utilizar e da capacidade do LLM em compreender esse padrão e fornecer a precisão adequada. É algo que estamos a testar neste momento e a tentar encontrar um equilíbrio entre a precisão e a economia de custos.

Participante 2: Falou sobre RDF e a identificação única de entidades na sua ontologia. Estou curioso: já lidou com o problema da deduplicação na representação da sua ontologia semântica e como é que abordou essa questão?

Fabiane Nardon: A deduplicação de dados na ontologia, é isso mesmo?

Participante 2: Também nos seus grafos.

Fabiane Nardon: No gráfico? Claro, não é fácil representar o RDF e a ontologia. Isto também é uma arte. Dependendo da forma como o faz, também pode ter o mesmo conceito com identificadores diferentes. Uma vez que estamos a organizar os nossos dados em domínios e em produtos de dados, isto não pode ser eliminado, mas podemos reduzi-lo bastante, porque cada responsável por um domínio cria a sua parte da ontologia, que será ligada à ontologia mais ampla. É claro que isto não é perfeito, mas podemos resolver um pouco o problema organizando-nos em domínios e produtos de dados.

Participante 3: Vi um dos seus slides em que falava especificamente sobre a sua implementação da funcionalidade de pesquisa do MCP, e achei muito fascinante que, no chat principal do orquestrador que estava a apresentar, o contexto não tenha ficado de todo poluído quando pesquisou inicialmente as primeiras 100 ferramentas. Depois, houve uma chamada secundária que refinou essa pesquisa, creio eu, para cerca de cinco ferramentas ou algo do género, e foi isso que foi passado para o seu agente principal. Seria possível falar um pouco sobre como está a realizar essa pesquisa inicial das 100 ferramentas sem poluir de todo a sua janela de contexto?

Fabiane Nardon: Talvez eu tenha simplificado demais, porque, claro, há uma ferramenta no contexto que é a ferramenta de pesquisa? O que fizemos foi implementar também utilizando o Spring AI. Na verdade, fornece-se ao agente apenas uma ferramenta, que é a ferramenta de pesquisa. Utilizando o Spring AI, é possível injetar duas referências no contexto. Quando se faz a chamada e se obtêm as cinco ferramentas, basta injetar essas cinco ferramentas no contexto.

Participante 3: O que aconteceu com a redução das 100 ferramentas para as 5?

Fabiane Nardon: As 100 ferramentas referem-se à situação em que se tem o servidor MCP e, ao chamar a lista de ferramentas, solicitando a lista das ferramentas disponíveis, o servidor MCP devolve uma lista de ferramentas. É uma representação de todas as ferramentas e das respetivas descrições. É normalmente o que o cliente MCP vai receber quando se comunica com o servidor MCP pela primeira vez.

Participante 3: Acho que não percebi bem. Está essencialmente a dizer que a ferramenta de pesquisa é o seu próprio agente e que permanece no seu contexto, e que as cinco ferramentas devolvidas são as que estão a ser utilizadas.

Fabiane Nardon: Sim. Tens dois serviços: na ferramenta de pesquisa, tens todas as ferramentas; e no contexto do agente, tens apenas as ferramentas que obtiveste através da pesquisa dinâmica de ferramentas.

Participante 4: Adoro a forma como tornaram superfácil criar ferramentas com base na vossa plataforma de dados. Quem costuma criar as ferramentas? São as equipas de produtos de dados ou as equipas de agentes que as vão utilizar?

Fabiane Nardon: É uma mistura. Normalmente, a equipa de dados conhece melhor os dados e é ela que cria as ferramentas. Normalmente, as equipas que estão a desenvolver o agente também são capazes de utilizar os dados, porque, no caso do agente, é preciso conhecer os dados de que se dispõe, especialmente no nosso ramo de atividade. É diferente porque, no nosso ramo, estamos a criar agentes empresariais para os nossos sistemas. Se estiver a criar, por exemplo, ferramentas para o GitHub e pretender permitir que qualquer pessoa aceda às suas ferramentas, a situação é diferente. No nosso caso, as pessoas que estão a criar os agentes têm, normalmente, acesso aos dados. Porque, por vezes, um grupo ou domínio criou ferramentas para recuperar dados e a outra equipa está apenas a criar um agente e a obter um dado de outro domínio para poder reutilizar as ferramentas. Neste caso, havia uma equipa a desenvolver a ferramenta e outra a desenvolver o agente. É uma combinação.

Participante 4: Ambas, ou seja, tanto as equipas de produtos de dados podem criar ferramentas, como as equipas de agentes também têm essa capacidade e os meios para o fazer?

Fabiane Nardon: Sim, a equipa de agentes também pode criar ferramentas, desde que tenha acesso aos dados. Às vezes é a mesma equipa, outras vezes não. Existem também ferramentas já prontas de outros domínios. Se precisar dessa ferramenta de outro domínio, pode simplesmente aceder à ferramenta ou pedir à equipa de dados desse outro domínio para criar uma ferramenta específica para si. Cria-se agentes para o seu produto e é possível combinar ferramentas de vários domínios diferentes. Depende. Normalmente, é a equipa de dados que cria as ferramentas de dados, porque conhece muito bem o negócio e o esquema de dados. Normalmente, é assim que acontece.

Veja mais apresentações com transcrições