Se queremos que façam trabalho do conhecimento, devemos projetá-los como agentes de conhecimento — Benjamin Clavié, Mixedbread

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: If we want them to do Knowledge Work, design them as Knowledge Agents — Benjamin Clavié, Mixedbread · Canal: AI Engineer · 17:34 · Assistir no YouTube

Tópicos: Agentes de IA, Automação de tarefas e workflows, Avaliação e benchmarks de IA, RAG, busca e recuperação de informação

Resumo

Benjamin Clavié defende que agentes de IA devem ser projetados para realizar trabalho do conhecimento, e não apenas tarefas de programação. Esse trabalho envolve buscar e interpretar informações ambíguas e contextuais para produzir decisões ou resultados acionáveis. A apresentação mostra como ferramentas de busca melhores e a divisão do trabalho entre agentes podem aumentar a precisão e reduzir custos. A conclusão é que ferramentas, agentes e orquestração precisam ser projetados em conjunto, seguindo práticas de organização do trabalho que humanos desenvolveram ao longo do tempo.

Pontos-chave

Trabalho do conhecimento inclui áreas como direito, finanças, medicina, pesquisa e engenharia de software.
Agentes de programação são um caso específico: o código contém referências e estruturas mais estáveis do que o conhecimento não codificado.
Tarefas de conhecimento exigem interpretar contexto e intenção, pois termos iguais podem ter significados diferentes em cada situação.
Novas ferramentas ampliam quais tarefas podem ser realizadas de forma escalável e econômica.
O benchmark BrowseComp+ mostra que ferramentas de busca bem otimizadas podem reduzir chamadas e recursos necessários.
Trabalho complexo se beneficia da divisão de tarefas: um agente principal delega pesquisas a subagents e usa os resultados para formular uma resposta.
No benchmark MQA, a busca multimodal e a arquitetura com agentes reduziram a diferença de desempenho em relação ao resultado humano.
As ferramentas devem ser co-projetadas com os agentes, que precisam saber escolher entre primitivas de busca, como BM25 e busca semântica.
Como a context window é um recurso finito, agentes precisam decompor tarefas e organizar as informações relevantes.

Capítulos

Início	Capítulo	Resumo
00:01	De agentes de programação a agentes de conhecimento	O palestrante diferencia agentes de programação de agentes voltados ao trabalho do conhecimento em áreas diversas.
03:44	Por que o conhecimento fora do código é mais difícil	Código oferece referências relativamente estáveis, enquanto outras formas de conhecimento dependem de contexto, intenção e significado.
07:29	Como ferramentas e organização ampliam o trabalho	A evolução de ferramentas e fluxos de trabalho torna tarefas de conhecimento mais acessíveis, escaláveis e baratas.
11:16	Pesquisa jurídica, benchmarks e divisão de tarefas	Exemplos de pesquisa jurídica e benchmarks ilustram como ferramentas melhores e agentes que delegam pesquisa podem elevar a qualidade das respostas.
14:56	Lições para projetar agentes de conhecimento	A conclusão recomenda aprender com a organização humana do trabalho, co-projetar ferramentas e agentes e decompor tarefas para lidar com limites de contexto.

Citações

Devemos projetá-los como agentes de conhecimento, não como agentes de programação. — 00:01

Código é conhecimento, mas nem todo conhecimento é código. — 03:44

As ferramentas não são complementos neutros. — 08:04

Os agentes de IA se beneficiam muito desse padrão. — 15:27

Você precisa de uma maneira de decompor sua tarefa. — 17:02

Conceitos e entidades

Benjamin Clavié (pessoa): Palestrante que apresenta a defesa de agentes projetados para trabalho do conhecimento.
Mixedbread (empresa): Empresa mencionada pelo palestrante em relação a ferramentas de recuperação e busca.
knowledge agents (conceito): Agentes concebidos para encontrar, interpretar e utilizar conhecimento em tarefas de diferentes áreas.
knowledge work (conceito): Trabalho cujo principal insumo é informação e cujo resultado costuma ser um julgamento, decisão ou ação.
BM25 (conceito): Método de busca lexical cuja qualidade depende, entre outros fatores, da otimização da configuração.
BrowseComp+ (benchmark): Benchmark citado para avaliar ferramentas de busca em tarefas de pesquisa com muitos documentos.
MQA (benchmark): Benchmark baseado em PDFs e tarefas empresariais, citado na comparação entre humanos e sistemas de IA.
Gemini 3 (modelo): Modelo citado na comparação de desempenho com humanos usando BM25.
Claude Code (ferramenta): Ferramenta de programação mencionada como exemplo de agente usado em tarefas de código.
busca multimodal (conceito): Busca que pode trabalhar com conteúdo de PDFs, incluindo tabelas, em vez de depender apenas de texto extraído por OCR.
orquestração de agentes (conceito): Organização de agentes e subagents para decompor uma tarefa e reunir resultados de pesquisa.

Tradução completa (pt-BR)

00:01 [música] Certo. Então, oi, pessoal. Vou fazer a apresentação mais rápida possível sobre mim. Sou Ben Clavier. Trabalhei na Mix Bread, onde fazemos retrieval. Sou francês e moro em Tóquio. E hoje vou falar com vocês [limpa a garganta] sobre o fato de que agents deveriam fazer trabalho do conhecimento. Portanto, deveríamos projetá-los como trabalhadores do conhecimento. Deveríamos projetá-los como agents do conhecimento, e não

00:32 agents de programação. Vou explicar a diferença e por que acho isso importante. É uma palestra um pouco quente sobre tecnologia, mas vamos começar. A primeira coisa é que os primeiros agents nos davam curiosidades divertidas. Estou falando dos agents do começo, os agents de 2022, quando tudo o que você tinha era, sabe, RAG, mas os agents nem conseguiam fazer tool calling naquela época. Então, tudo o que você tinha era uma instrução if. Você fazia uma busca. E pronto: era legal, dava para conversar com seu PDF. Essa foi a primeira forma de trabalho agêntico. Não era muito útil. Não vamos falar disso por muito tempo. O que veio depois foram os agents de programação, e isso

01:04 virou a grande febre. Quando os agents começaram a conseguir pesquisar de verdade, entender as coisas corretamente, executar tarefas e chamar ferramentas, começamos a projetar agents de programação, e eles são algo enorme. Acho que não há ninguém nesta sala que não use agents de programação. Usaria o Codex, etc. E essa é uma forma de trabalho do conhecimento. Mas, naquela época, os agents não eram trabalhadores do conhecimento. Eram agents de programação. E agora estão se tornando trabalhadores do conhecimento. E, por trabalho do conhecimento, quero dizer que ele é um superconjunto amplo. E praticamente todo workflow em que você já pensou

01:37 antes é uma forma de trabalho com agents do conhecimento, simplesmente pela natureza do conhecimento. Por exemplo, se você tem um agent que é advogado e procura documentos jurídicos; se você tem um agent financeiro; se está procurando informações sobre medicamentos — há muitas pessoas no Twitter que tentam fazer autodiagnósticos, e há muitos usos médicos. Tudo isso são casos de agents do conhecimento. O objetivo é encontrar conhecimento e tentar fazer uso dele. A programação faz parte disso, é claro, e até aquela pequena parte de RAG de que falamos no primeiro slide

02:09 faz parte disso, mas é uma proporção muito, muito pequena do todo. Há muito mais no conhecimento do que qualquer domínio isolado. E o que é, afinal, trabalho do conhecimento? Estou dizendo que é importante que eles façam trabalho do conhecimento; programação é trabalho do conhecimento. Na minha opinião, há duas maneiras de defini-lo. Uma delas é: trabalho do conhecimento é um trabalho cuja principal entrada é informação. A principal entrada não é um material físico. Não é algo que você possa tocar. É conhecimento, é informação. E a natureza

02:41 do trabalho do conhecimento é que você processa essa informação, que por natureza é muito ambígua, muito difusa. E o principal resultado que você obtém disso é algo prático. É um julgamento. É uma decisão. É algum tipo de resultado. Se for um advogado, você vai receber, sabe, as conclusões dele sobre seu caso, e ele talvez faça sua defesa. Você vai receber algo prático, uma linha de raciocínio — algo que ainda não é tangível, mas que existe como conhecimento. Há também uma definição topológica que faz sentido aqui: se você precisa de busca, é um problema de conhecimento; e, se é um problema de conhecimento, você precisa de

03:12 busca. É uma definição muito fácil de fazer por si só. E, no mundo real, basicamente a maior parte do trabalho que vemos na economia de serviços é uma forma de trabalho do conhecimento: advogados são trabalhadores do conhecimento, acadêmicos são trabalhadores do conhecimento, atuários são trabalhadores do conhecimento, engenheiros de software e pesquisadores também são trabalhadores do conhecimento. E o fato de haver tanto trabalho do conhecimento na sociedade contribuiu para uma estruturação cada vez melhor desse trabalho: na verdade, existem workflows muito, muito bem definidos para como devemos fazer trabalho do conhecimento, para como o trabalho do conhecimento funciona em si e para como o aprimoramos.

03:44 Mas, até agora, o campo dos agents meio que se concentrou no caso especial e tentou generalizar a partir dele. E esse caso especial é programação e engenharia de software. A questão é que código é conhecimento, mas nem todo conhecimento é código. E código é uma forma de conhecimento muito, muito singular, porque tem referências muito duradouras. Em uma base de código, haverá muitas referências a um identificador, um arquivo ou um caminho. E, certo, quando fazemos vibe coding, isso pode mudar, mas na maior parte do tempo não muda tanto assim: todas essas coisas são muito, muito duradouras. Além disso, essa superfície é obviamente fácil de

04:19 pesquisar com grep: há palavras-chave, definições de métodos, muitas coisas que, por definição, você consegue localizar no código. E a tarefa — esta é, na verdade, muito importante e não falamos muito sobre isso — é que as pessoas perguntam: “Por que o GPT é bom o suficiente para programação?” ou “Como um agent consegue programar e você está me dizendo que consegue fazer pesquisa aprofundada para uma questão jurídica?”. Uma das razões é que não percebemos, mas, quando interagimos com agents de programação, damos a eles tarefas extremamente específicas. Não esperamos tanto assim deles. Tudo gira, de certa forma, em torno de um

04:50 recurso, de um ticket específico: há uma tarefa em questão. Você não vai dizer ao agent: “Descubra um novo paradigma de programação e implemente-o neste novo aplicativo. Não sei o que vai dar certo, boa sorte.” Mas, no trabalho do conhecimento, muitas vezes esse é o caso. Primeiro, você não tem aquelas referências duradouras: o significado está sempre implícito. E, mais importante, a mesma pista pode significar muitas coisas diferentes. Não temos definições de funções no trabalho do conhecimento. Por exemplo, se você recebe “30 dias” e seu agent está procurando “30 dias”, isso é um prazo? Um período de carência? Uma regra de retenção? É sequer no mesmo

05:21 domínio? Você está procurando “30 dias” no contrato e acaba encontrando informações sobre medicamentos? Há muita informação contextual. Sim. Mas, mais importante, a busca começa com uma intenção. Mesmo que você esteja usando de novo o exemplo jurídico, se perguntar sobre uma regra específica que quer aplicar a um domínio específico, vai precisar analisar as normas internacionais aplicáveis e depois verificar se elas se aplicam a esse caso. Há muitas informações condicionais que não estão predefinidas na tarefa; cabe ao agent encontrá-las. Por isso, o conhecimento que não é código depende muito do contexto e do significado

05:52 — o que é muito mais difícil do que código. E isso levou ao fato de que nada do que estou dizendo é novidade: as pessoas fazem trabalho do conhecimento há muito, muito tempo, e isso resultou em dois ciclos intermináveis. Há um ciclo das ferramentas, que começou quando estávamos conversando e, em algum momento, alguém disse: “Vamos escrever as coisas.” Depois, em Alexandria, tivemos o caso do Pínakes, quando o curador da Biblioteca de Alexandria teve a ideia de que talvez devêssemos ter uma maneira de catalogar todos os livros que temos. Depois, nós

06:23 desenvolvemos a escrita. Depois, desenvolvemos bibliografias. Depois, chegamos à versão atual do sistema Dewey para bibliotecas e, hoje em dia, temos mecanismos de busca. Mas também havia um ciclo de organização, que se cruza com o ciclo das ferramentas, mas também é independente dele. Antes, havia o especialista prodigioso: todos já ouvimos falar dos polímatas do passado, pessoas que simplesmente sabiam tudo sobre um domínio ou sobre todos os domínios, e a quem você recorria quando precisava de informação. Mas isso não é escalável. Então, acabamos com os mosteiros, que eram guardiões do conhecimento; depois, tivemos as universidades e, por fim, chegamos

06:55 criando as burocracias, e acabamos criando a organização moderna do trabalho, em que temos empresas muito especializadas. Por exemplo, nos hospitais, há o médico, o médico sênior, o profissional de enfermagem avançada, os enfermeiros, os auxiliares de saúde, e todos eles se especializam, por assim dizer, em diferentes níveis de tarefas. Essa é uma forma realmente boa de otimização. Mas a questão é que, na verdade, trata-se de um único ciclo. Estou mostrando dois ciclos aqui, mas, na verdade, eles são um só: temos novos conhecimentos, e novos conhecimentos significam que precisamos de ferramentas melhores; ferramentas melhores significam que acabamos criando novos workflows e novas funções, como

07:29 precisamos de pessoas treinadas para usar essas ferramentas, pessoas que entendam o que a nova ferramenta faz. Se você tem alguém que sabe ir à biblioteca e diz: “Certo, use o Google”, essa pessoa precisa saber o que é o Google. Ela precisa aprender que aquilo é um mecanismo de busca, que basta digitar coisas nele, sem precisar ir fisicamente até lá. Isso significa que você treina essas pessoas novamente e obtém novos trabalhadores do conhecimento, mais eficientes. Assim, eles produzem mais conhecimento, então precisamos de novas ferramentas, e assim por diante. Portanto, tanto o ciclo das ferramentas quanto o ciclo organizacional são, na verdade, esse único ciclo de auto-otimização que, por assim dizer, aciona o outro sem parar. E a questão das ferramentas e da

08:04 otimização é que elas não são complementos neutros. Como eu disse, continuamos otimizando ferramentas, surgem coisas e criamos coisas novas a partir dessas ferramentas. Mas isso nunca é neutro. Ferramentas não são apenas “ah, minha busca ficou 5% melhor”. Ter uma ferramenta ou não ter uma ferramenta é o que determina se uma tarefa — não se ela é possível, porque dá para fazer coisas sem a ferramenta certa — pode ser escalada e realizada a baixo custo. Afinal, algo ser barato significa que pode ser escalado. E, claro, se você vai à Biblioteca de Alexandria antes dos papiros,

08:35 é provável que leve duas ou três semanas para encontrar seu manuscrito, onde quer que você esteja procurando. Então, você vai precisar muito, muito, muito desse conhecimento. Mas, se houver um catálogo da biblioteca, isso levará 10 minutos. Aí fica muito mais fácil pensar: “Ah, certo, preciso saber mais sobre isso, então vou pesquisar”. Da mesma forma, se você tiver um diretório de mapas, ou mesmo um mapa, para começar — o que, por si só, é uma ferramenta de informação —, explorar o mundo passa a ser uma ideia muito melhor. Você não vai depender de descobrir a América por acaso, a caminho das Índias, sabe? Você sabe para onde está indo. E, da mesma forma, se você tiver

09:07 uma plataforma de busca multimodal, poderá pesquisar milhões de PDFs de um jeito que antes não era possível. Assim, muitos casos de uso que antes levavam a pensar “ah, está no arquivo, não vou mexer nisso” passam a ser realmente úteis. E, na prática, isso se parece com o que estou mostrando. Agora vou entrar em aspectos mais técnicos, começando por uma tarefa simples de pesquisa aprofundada. Este é o placar do BrowseComp+, criado para avaliar a qualidade de ferramentas de busca em uma tarefa bem delimitada de pesquisa aprofundada. Há 200.000 documentos e consultas específicas. [limpa a garganta] Bio falou sobre isso hoje de manhã, e é um benchmark muito útil para analisar

09:41 consultas. E o que vemos é que uma ferramenta ruim — algo de que as pessoas costumam reclamar —, bem, há dois BM25 aqui: um otimizado e outro não otimizado. Isso porque as pessoas costumam dizer que BM25 não é muito bom. E dizem isso porque não existe um único BM25. Há centenas deles. É uma forma de fazer busca lexical. Você sempre deve otimizar suas linhas de base. Deve sempre otimizar aquilo em que está apostando. E o que vemos aqui é que uma ferramenta mal otimizada é inútil.

10:11 Ela tem apenas 60% de acurácia. Você não vai confiar em alguém que acerta só 60% das vezes; vai simplesmente fazer isso por conta própria. Quando você começa a otimizar as ferramentas, vê que chegamos a 70%, 80%. E então a melhor — a melhor de fato — é o harness híbrido, que chega a 98%. Mas talvez essa não seja a parte mais interessante, porque em certo ponto começamos a atingir um platô. O salto de 88,9 para 90,2 está dentro da variação entre execuções, então não importa. O que importa aqui, porém, é que você chega a 90,2% de acurácia com 20% menos chamadas de ferramenta. E isso é enorme

10:44 porque, na prática, isso significa 20% menos tokens e 20% menos recursos usados. É basicamente 20% de dinheiro grátis. E, se você comparar com a linha de base não otimizada, está gastando cerca de 5% do que gastava antes. Portanto, é a ferramenta que faz a tarefa valer a pena. Ninguém continuaria usando essa ferramenta se ela exigisse 25 chamadas, mas, se exigir oito, você pensa: “Ah, sim, legal. Esse é um workflow que posso implementar”. E a segunda parte, que vem junto com as ferramentas, é, na minha opinião, igualmente importante, porque o BrowseComp+ do slide anterior é interessante, mas é

11:16 fácil. São 100.000 documentos. É só texto. É apenas uma pergunta. Não é muito aberto; é apenas um pouco complexo. Mas, quando você está fazendo trabalho do conhecimento de verdade, há aquele workflow que você vê e que tentei rabiscar: há um cliente que vai falar com alguém importante, procura um advogado, que é sócio da agência, e diz: “Certo, esta é a minha situação. Este é o meu problema”. Eles se reúnem, mas o sócio não vai fazer toda a pesquisa jurídica. Não vai executar cada etapa

11:47 do problema. O que ele faz é entender que, certo, essa pessoa tem este problema, que vai causar aquilo; esses são os fatos. Preciso das leis relevantes, destes aspectos e assim por diante. Depois, há os objetivos das partes. Ele conta com assistentes, e são os assistentes que fazem essa pesquisa. Eles vão usar o conjunto de ferramentas que foram treinados para usar e produzir um memorando, e então o entregam às pessoas importantes. Talvez elas [limpa a garganta] pesquisem um ponto para esclarecer, mas, em geral, confiam no que seus agentes de busca — se quiser chamar assim —, os assistentes, encontraram para elas. E essa é a resposta que

12:18 você vai receber. Isso reforça o que eu disse antes: em programação, quando você usa o Claude Code, está fazendo esse trabalho por conta própria. Você já dividiu a consulta em partes; sabe o que quer fazer, tem um artefato linear, tem algo que está passando para o agent na vida real, ou tem um cliente com um problema muito aberto, que você precisa decompor por conta própria. E o seu agent também precisa decompor por conta própria; depois, precisa usar subagents para fazer essa pesquisa. É assim que ferramentas melhores e organização trabalham juntas. Este é o MQA, que é outra forma de benchmark de conhecimento. QA [limpa a garganta] foi lançado em conjunto pela Hugging Face e pela Snowflake. É baseado em PDFs e em tarefas empresariais. Tem PDFs e versões dos PDFs processadas por OCR. E o estado atual do placar realmente mostra que tanto as ferramentas quanto as organizações são necessárias. Dá para ver isso pelo fato de que, com BM25, independentemente de quanto seja otimizado, o humano e o Gemini 3 chegam ao mesmo limite. Isso não significa que o Gemini 3 seja tão bom quanto um humano; significa que até mesmo

12:48 O Knowledge Benchmark QA [limpa a garganta] é algo que a Hugging Face e a Snowflake lançaram juntas. Ele é baseado em PDF e é uma tarefa corporativa: contém PDFs e versões dos PDFs com OCR. E o estado atual do placar realmente mostra que tanto as ferramentas quanto as organizações são necessárias. Dá para ver isso pelo fato de que, com o BM25, por mais otimizado que fique, o humano e o Gemini 3 chegam ao mesmo teto. E isso não significa que o Gemini 3 seja tão bom quanto um humano; significa que até mesmo o

13:19 Um humano não consegue obter as informações certas, mesmo com buscas ilimitadas usando BM25. Então, temos a configuração das ferramentas e precisamos de ferramentas melhores para avançar. Essa é a parte de otimização de ferramentas do ciclo. Felizmente, temos ferramentas melhores. Temos modelos que conseguem lidar com PDFs. Temos visão. Não precisamos depender do texto extraído por OCR. E o que vemos com isso é outro salto: o Jina e a ferramenta de busca da Mixedbread, que é totalmente multimodal. Assim, ela consegue ler o PDF, extrair as tabelas e tudo mais que é útil na busca, e isso nos dá um grande salto de precisão. Mas a

13:51 parte interessante é que isso não funciona tão bem quanto gostaríamos. Por que meu agent está acertando 88,9, se o humano acerta 99,4? Isso significa que estou deixando 10% na mesa. Mas não entendo: isso é um agent. Acho que ele recebe 10 turnos no benchmark. Então, é um sistema totalmente agentic. Ele pode refletir sobre os resultados e, ainda assim, está deixando a desejar no desempenho. E foi aí que apresentamos o agent da Mixedbread, que faz exatamente aquela decomposição do trabalho que vimos antes: basicamente, dizemos ao agent principal, quando ele vai responder à

14:21 pergunta: “Certo, esse é um tema amplo, com milhares de PDFs. Você não vai fazer a busca sozinho. Por favor, divida o problema para mim. Escreva consultas sobre os aspectos que você considera importantes para responder à pergunta de fato.” E temos searchers que partem por conta própria, encontram os resultados certos e trazem um pequeno memorando para o agent, que então responde à pergunta. Isso aumenta a precisão em 3,5 pontos. Pode não parecer muito, mas gosto de pensar nisso como uma lacuna até o oráculo. A lacuna até o oráculo é a diferença entre os documentos perfeitos e o seu sistema de busca. Aqui, antes de usar os agents, essa lacuna era de cerca de 10

14:56 pontos; depois de usar o agent, caiu para seis pontos. Isso significa que reduzimos os erros em cerca de 40%. A diferença entre humanos e agents diminui 40% só por termos uma arquitetura melhor para fazer a busca. Acho que este é o fim dos meus slides, porque estou ficando sem tempo, e isso é perfeito. Este é o slide com a mensagem principal. O que quero que vocês levem desta palestra é que sabemos como projetar melhor o trabalho com conhecimento para humanos, e os AI agents realmente se beneficiam desse

15:27 padrão. Nós o projetamos e sabemos como fazer isso. Os humanos trabalham assim há séculos. As pessoas sempre precisaram de mais conhecimento. Os impérios costumavam ter bibliotecários. Temos paralegais. Temos escritórios de advocacia. Sabemos muito bem como o setor jurídico resolveu isso. O setor médico também resolveu. E nada disso se parece com programação. A programação tem um sistema muito diferente porque é um caso de uso muito específico, e deveríamos aprender com o trabalho do conhecimento para saber como projetar agents que façam trabalho do conhecimento. E então não devemos exagerar

16:00 nas ferramentas, porque elas não existem para realizar tarefas por conta própria. As ferramentas existem para superar limites. Você quer uma ferramenta melhor quando percebe que atingiu um limite e que seu desempenho não está onde gostaria. Então, projetamos ferramentas melhores para superar esses limites. E, mais importante, as ferramentas precisam ser projetadas em conjunto com os agents: eles precisam saber como usá-las. Uma coisa que vemos com frequência é que os agents tentam escrever consultas de grafo porque grafos aparecem por toda parte nos dados de treinamento, e BM25 também aparece por toda parte nos dados de consulta. Mas nem sempre é disso que você precisa. Às vezes, você precisa de busca semântica em um PDF, e não dá para

16:32 fazer BM25 em um PDF: você precisa escrever uma consulta melhor. Por isso, é muito importante que seus harnesses agentic, ou até mesmo seus modelos agentic, saibam que têm mais de uma ferramenta à disposição. O que importa são as primitivas: grafos são uma primitiva, BM25 é uma primitiva e a busca semântica é uma primitiva. E os modelos precisam ser muito bem treinados em todas elas; precisam conhecer cada uma.

17:02 E a última coisa é que a orquestração certa da busca vai proporcionar resultados muito melhores, porque o contexto é um recurso finito. Mesmo que cheguemos a um modelo com um contexto de 100 milhões de tokens, isso vai custar muito caro e ainda assim não vai ser suficiente: não chega nem à metade do código jurídico de um estado, quanto mais ao dos Estados Unidos, ao direito internacional ou a cursos especializados, etc. Então, você precisa de uma maneira de dividir sua tarefa e de ter um orquestrador, seus agents principais e pessoas que consigam organizar o conhecimento para eles. E é isso. Temos dois minutos para perguntas. [aplausos]

17:34 Obrigado.

Transcrição original

[00:01] [music] Okay. So, hi everyone. I’m going to give the quickest introduction to myself. I’m Ben Clavier. I worked at Mix Bread where we do retrieval. I’m French and I live in Tokyo. And today I’m going to talk talk to you [clears throat] about the fact that agents should do knowledge work. And so we should design them like knowledge workers. Like we should design them like knowledge agents and not

[00:32] coding agents. And I’m going to explain the difference and why I think that’s important. It’s a bit of a hot tech talk but let’s start now. So the first thing is like first agents gave us fun trivia and I’m talking like early agents 2022 agents back when all you had was you know rag but agents couldn’t even the tool call back then. So all you had is like you had an if statement. You did search. You got like cool you could talk to your PDF. That was the very first form of agentic work. It was not very useful. We’re not going to talk about that for long. What came next was programming agents and that’s

[01:04] been all the rage. Like once agents started being able to search actually properly search actually properly understand things car tasks out call tools we started designing coding agents and coding agents are a big thing. I don’t think there’s anyone in this room that does not use coding agents. would use code, codeex, etc. And that’s a form of knowledge work. But agents were not knowledge workers at the time. Like agents were coding agents. And now they’re becoming knowledge worker. And by knowledge worker, I mean that knowledge work is a big supererset. And kind of every workflow you’ve thought of

[01:37] before is a form of knowledge agents just because of the nature of knowledge. So it’s like if you have an agent that’s a lawyer that’s looking for legal documents, if you go financial agent, if you’re looking for you know medication information like you’ve got a lot of people on Twitter that try to do those self diagnosis and you’ve got just a lot of medical usage. All of that is coding agents for getting an agent. It’s trying to find say knowledge agents. is trying to find knowledge, trying to make use of knowledge and coding is part of that of course and even the small rag bit that we talked about like in the first slide

[02:09] is part of that but that’s a very very small proportion of the actual full thing like there’s so much more to knowledge than any one domain and what even is knowledge work because I’m saying that it’s important they do knowledge work coding is knowledge work and I think there’s two ways to define it in my opinion one of them is knowledge work is work Your main input is information. Like your main input is not an actual physical material. It’s not something that you can touch. It’s knowledge is information. And the nature

[02:41] of knowledge work is that you process this information which is by nature very ambiguous, very diffuse. And the main output you get from that is something actionable. It’s a judgment. It’s a decision. It’s some if it’s a lawyer, you’re going to get, you know, their findings on your case and they might plead for you. you’re going to get an actual actionable thinking item like something still not tangible but that exists as knowledge. There’s also a topological definition which makes sense here is that if you need search it’s a knowledge problem and if it’s a knowledge problem you need

[03:12] search. So it’s very easy self-defined and in the real world that’s basically most of the work that we see in the service economy is a form of knowledge work like lawyers knowledge workers academics knowledge workers actuaries knowledge workers software engineers researchers also knowledge workers and the fact that there’s so much knowledge work in society has contributed to like a never improving structuring of knowledge work like there’s actually very very well definfined workflows for how we should do knowledge work for how knowledge works in itself and how we evolve that.

[03:44] But so far, agentics kind of focused on the special case and I try to generalize from it. And that special case is coding and software engineering. And the thing is code is knowledge, but not all knowledge is code. And code is a very very unique form of knowledge because it has very durable cues like on in a codebase there’s going to be a lot of references to like an identifier or a file or a path. And okay when we vibe code that can change but most of the time it’s not going to change all that much like all the things are like very very durable. Then you’ve got that surface obviously is like now and

[04:19] grapable like there’s keywords there’s method definition there’s a lot of things that by definition you can grab in code and the task and this one’s actually very important and we don’t talk about it a lot but people are like oh why is ge good enough for programming or why can an agent do programming and then you’re telling me it can do like deep research for a legal question and one of those is because we don’t realize it but like when we interact with coding agents we are giving them extremely in our task like we’re not actually expecting that much from them like everything is always kind of about a

[04:50] feature about like a given ticket like there’s a task at hand you’re not going to tell the agent like discover a new programming paradigm and then implement it in this new app I don’t know what’s going to do good luck but in know that’s often the case like first of all you don’t have those double cues like the meaning is always implicit and more importantly the same clue can mean a lot of different things we don’t have function definitions in knowledge work like if receive 30 days. If your agent’s looking for 30 days, is it a deadline? Is it a grace period? Is it a retention rule? Is it even in the same

[05:21] domain? Like are you searching for 30 days on the contract and you’re getting medication? There’s a lot of contextual information. Yeah. But more importantly, the search starts from an intent. Like even if you’re doing again legal example, if you’re asking about like a specific rule that you want to apply to a specific domain, you’re going to need to look at the international norms that apply and then do they apply in this case. there’s a lot of conditional information that is not predefined in the task like that’s all up for the agent to find and so non-code knowledge is very contextual and meaning driven

[05:52] which is much harder than code and that’s led to the fact that none of what I’m saying is new like people have been doing knowledge work for a very very long time and that’s resulted in like two endless loops you have a tool loop which is at the start we were we were like talking then at some point some guy was like we write stuff down. Then in Alexandria, we had the pin case which was the curator of the library of Alexandria came up with an idea that maybe we should have a way to catalog all of the books we have. Then we

[06:23] developed writing. Then we developed bibliographies. Then we ended up with like the current version of the like Dewey system for libraries and nowadays we have search engines. But we also had an organization loop which is joint but also disjoint from the tool one which is it used to be the one gifted expert like we’ve all heard of the polymath of the past the person who just knew everything about one domain or all domains and you just went to them if you had information but that doesn’t scale. So we ended up with like monasteries which were like guardians of knowledge and then we had universities and then we ended up

[06:55] creating the bureaucracies and now we ended up creating the modern organization of work where we have very specialized firms like at hospitals you’ve got the doctor you’ve got the senior doctor you’ve got the nurse practitioner the nurses the healthcare assistants and all of them kind of like specialize on different levels of tasks and that’s a really good form of optimization but the thing is that it’s actually just the one loop like I’m showing two loops here but they’re actually just the one loop which is we have new knowledge and new knowledge means that we need better tools and better tools mean that we end up creating new workflows new roles like

[07:29] we need people that are trained to use those tools people that understand what the new tool does if you have a guy that knows how to go to the library and you’re like okay use Google you need the knowledge of what Google is like that person needs to be taught that’s a search engine you can just type stuff in it there’s no need to physically go there and that means you retrain you get new knowledge workers who are more efficient so they create more knowledge so we need new tools and so on and so on. So both the tool loop and the organizational loop are actually just this one selfoptimizing loop that kind of like triggers the other endlessly. And the thing about like tooling and

[08:04] optimization is that they’re not neutral add-ons. Like I said that we keep optimizing tools and things come up and we create new things out of those tools. But that’s never actually a neutral thing. Like tooling is not just oh my search is 5% better. the fact that we have a tool or the fact that we don’t have a tool is what decide if a task not if the task is possible because you can do things without the right tool but if the task is actually scalable and can be carried out cheaply because something being cheap means it can scale and it’s like yes of course if you go to the library of Alexandria before the pakis

[08:35] you can find your manuscript somewhere like wherever you’re looking for it there it’s probably going to take two three weeks so you’re going to really really really need that knowledge but if there’s a library catalog it’s going to take you 10 minutes and now like it’s way easier to just oh okay I need to know something more about this so I’m going to search for it likewise if you have a map directory or if you even have a map in the first place which in itself is a tool for information then exploring the world is a much better idea like you’re not going to rely on randomly discovering America on your way to the indies you know like you know where you’re going and likewise if you have

[09:07] like a multimodel search platform then you can search millions of PDF in a way that we couldn’t before so now there’s a lot of use cases where you were like oh it’s in the archives I’m not going to touch that that become actually useful and in practice this kind of looks like that and I’m getting into the more technical stuff here which is on a simple deep research task. So this is the browse comp plus leaderboard which is made to evaluate the quality of search tools on a very bonded deep research task. You have 200,000 documents and you have like specific queries. [clears throat] Bio talked about this this morning and it’s a really useful benchmark to like analyze

[09:41] queries. And what we see that like okay a bad tool. So that’s a thing that people often rant about. You’ll see that there’s two BM25 here. There’s two like optimized and unoptimized. And that’s because quite often people will tell you BM25 is not great. And the reason they’ll tell you BM25 is not great is because there’s not one BM25. There’s hundreds of them. It’s a way to do lexical search. You should always optimize your baselines. You should always like optimize what you’re betting. And so what you see here is like a badly optimized tool is useless.

[10:11] Like 60% accuracy. You’re not going to trust someone that’s right 60% of the time. You’re just going to do it yourself. When you start optimizing the tools, you can see we go up to 70 80. And then the best the actual best is the hybrid harness that gets to 98. But that’s maybe not the most interesting part because we start kind of plateauing at one point like the jump from 889.8 to 90.2 is in run variance that don’t matter. What matters here however is that 90.2% accuracy. You reach it with 20% fewer tool calls. And that’s huge

[10:44] because in practice that’s 20% fewer tokens, 20% like fewer resources that you use. That’s basically 20% free cash. And if you compare it to the unoptimized baseline, you’re spending like 5% of what you were spending in the first place. So the tool is actually what makes the task worth doing. Nobody would keep using that tool. If it takes 25 calls, but if it takes eight calls, you’re like, “Oh yeah, cool. That’s a workflow I can introduce.” And the second part which goes with tooling and I think it’s just as important because Bruscom plus in the previous slide is interesting, but it’s

[11:16] easy. It’s 100,000 documents. It’s just text. It’s just the one question. It’s not really that open-ended. It’s just a bit convoluted. But when you’re actually doing like real life knowledge work, there’s that workflow that you see that I try to doodle, which is you have a client, they come to the big shot, they come to the lawyer, that’s the partner of the agency, and they’re like, “Okay, this is my situation. That’s my problem.” And they meet together, but then what the partner does is they’re not going to be the ones doing all the legal research. They’re not going to be the ones like doing every single step of

[11:47] the problem. What they’ll do is kind of understand that like okay this person is has this problem that’s going to cause them that those are the facts. I need the relevant laws with this that and so on aspects and then they’ve got party goals. They’ve got assistants and the assistants are going to be doing this research. They’re going to be using like the sales of tools they’ve been trained to use and they’re going to produce memo and not and then they’re going to give that back to the big shots that maybe they’ll [clears throat] research like one clarification point but they mostly rely on what their searcher agents if you want like the assistants have found for them and that’s the respond that

[12:18] you’re going to get and that’s echoing the point I made before which is in code when you’re using cloud code you’re kind of doing that work yourself you’ve already broken down the query you know like you know what you want to do you’ve got a linear artic you’ve got something that you’re giving the agent in the real or you’ve got a client that’s got a very open-ended problem and you need to break it down yourself and your agent needs to break it down itself and then needs to use sub agents that do this research and this is how better tools and organization work together because this one is MQA which is another form of

[12:48] knowledge benchmark QA [clears throat] is something that hugging face and snowflake jointly released and it’s PDF based and enterprise task it’s got PDFs and it’s got OCR OCR versions of the PDF and the current state of The board really show that like both tools and organizations are necessary and you can see that in the fact that with BM25 however optimized it gets the human in Gemini 3 reach the same ceiling and that doesn’t mean that Gemini 3 is as good as a human that means that even the

[13:19] human cannot get the right information given unlimited searches with PM25. So you have the tool setting and you need better tools to go forward. That’s the like tool optimization part of the loop. Thankfully, we’ve got better tools. You know, we’ve got we’ve got models that can handle PDS. We’ve got vision. We don’t need to rely on OCR text. And what we see with that is that we get another jump which is Gina and the mixbride search tool which is fully multimodel. So, it can read the PDF, you get the tables, you get all that nice stuff in your search and that gets us a big jump in accuracy. But the

[13:51] interesting part is that like that doesn’t work. the well that don’t work that does work but that don’t work as well as we would like because why is my agent getting 88.9 if the human is getting 99.4 for like that’s 10% I’m leaving on the table here. But that I don’t understand that’s an agent. It gets I think 10 turns in the benchmark. So it’s a fully agentic system. It gets to think about its results and yet it’s missing performance. And that’s where we introduced the mixbr agent which is exactly that breaking down of work we saw earlier where we basically tell the the main agent once answering the

[14:21] question being like okay that’s that’s a big topic there is like thousands of PDFs. You’re not going to like search yourself. Just please break down the problem for me. Please write queries about the aspects that you think are important to answer the actual query. And we get searcher that go off on their own and they find the right results and they bring you like a little memo to your agent and then your agent actually answers that. And that gets the accuracy up by 3.5 points. And that don’t sound like a lot, but I like to think of it as like an oracle gap. And the oracle gap is the difference between perfect documents and your search system. And the oracle gap here is about about 10

[14:56] points before using the agents and it goes down to six points after using the agent. So that means that we have about a 40% reduction in mistakes. Like the gap between humans and agents goes down by 40% just by like having a better architecture to search through it. And I think this is the end of my slide because I’m running out of time and that’s perfect. That’s my takeaway slide. And what I want you to like get from this talk is that we know how to design better knowledge work for humans and AI agents really benefit from this

[15:27] pattern like we have designed this. We know how to do this. Humans have worked on this for centuries. Like [snorts] people have always needed more knowledge. The empires used to have librarians. We have parallel. We’ve got legal firms. We know exactly how legal the legal industry has figured out. The medical industry has figured it out. And none of it looks like programming. Programming has a very different system because it’s a very specific use case and we should really learn from the knowledge wall to know how to design agent that will do work for knowledge wall and then you must not like overfeit

[16:00] on tools because tools don’t exist as a way to do things by themselves. Tools exist as a way to overcome ceilings. You want a better tool when you see that you’re hitting a ceiling that your performance is not where you want it to be. So we design better tools to overcome that savings and more importantly the tools need to be co-designed with the agents like the agents need to know how to use tools because one thing you will often see is agents will try to write grape queries because grapes everywhere in the training data BM25 is everywhere in the query in the data and that’s not always what you need. Sometimes you need semantic search over a PDF and you can’t

[16:32] grab a PDF you can BM25 a PDF you need to like write a better query. So it’s very important that your agentic harnesses or even your agentic models know that they have got more than one tools and it’s about primitives grabs a primitive. PM25 is a primitive and semantic search is a primitive and all of those need to be like very well trained like the models need to know about all of them. And the last one is that the right orchestration of search will get you much better results because context is a finite resource and even if

[17:02] we get to a model that’s got like 100 million token context a that’s going to cost you a lot of money and b that’s still nothing you’re not even getting half of like one state’s legal code let alone the US let alone international law let alone specialist course etc. So you need to have a way to break down your task and you need to have your orchestrator, your main agents and people that can actually organize the knowledge for them. And yeah, so we’ve got two minutes for questions. [applause]

[17:34] Thank you.