Grep ou embeddings? Busca agentic em documentos empresariais — George He, LlamaIndex

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: Grep or Embeddings? Agentic Search Over Company Documents — George He, LlamaIndex · Canal: AI Engineer · 22:51 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de prompts e contexto, Modelos multimodais, RAG, busca e recuperação de informação

Resumo

George He apresenta como escolher entre busca local por arquivos e recuperação com embeddings para pesquisar documentos empresariais. A busca local pode funcionar bem em repositórios de código pequenos e organizados, mas conjuntos corporativos maiores e multimodais exigem indexação, controle de permissões e atenção à atualização dos dados. A proposta é combinar busca híbrida, ferramentas de navegação e leitura de arquivos e pré-processamento de documentos, deixando que um harness coordene as etapas. Na demonstração, um agent pesquisa relatórios financeiros da Alphabet e reúne dados de vários arquivos para produzir uma resposta fundamentada.

Pontos-chave

Busca local por arquivos é prática quando os dados são pequenos, estruturados e já estão disponíveis localmente, como costuma ocorrer com código em um repo.
Em conjuntos empresariais grandes e heterogêneos, a escala, as permissões e a falta de hierarquia tornam a busca local isolada menos adequada.
Um harness pode permitir que o agent combine busca semântica, busca por palavras-chave, filtros de metadados e navegação por arquivos.
A busca híbrida combina busca por palavras-chave, como BM25, e busca vetorial; reclassificar os resultados pode melhorar a recuperação.
Ferramentas para listar, filtrar, pesquisar e ler arquivos ajudam o agent a explorar documentos sem carregar o corpus inteiro no context window.
Documentos multimodais podem precisar de parsing estruturado, extração de tabelas e gráficos e geração de capturas de tela para apoiar a interpretação.
Sistemas de produção precisam lidar com multitenancy, permissões e atualização dos dados sem reindexar ou reprocessar tudo a cada mudança.
O palestrante recomenda persistir os dados em disco e usar uma camada de memória para acelerar a recuperação.
Na demonstração, o agent usa busca híbrida e navegação por arquivos para montar uma resposta sobre fluxo de caixa a partir de relatórios financeiros da Alphabet.

Capítulos

Início	Capítulo	Resumo
00:01	Busca local ou recuperação pré-indexada	George He apresenta a palestra e compara a busca por arquivos com embeddings e pré-indexação, destacando por que a abordagem local funciona para código, mas não necessariamente para dados empresariais.
04:42	Escala dos dados e papel do harness	A escolha da estratégia depende do volume de arquivos e da curadoria disponível, e um harness pode combinar busca semântica com navegação local.
08:50	Ferramentas de recuperação e documentos multimodais	A palestra descreve ferramentas para localizar, filtrar e ler arquivos, além de técnicas de parsing e renderização para documentos complexos.
13:30	Parsing, permissões e sincronização	O palestrante discute a qualidade da extração, a distribuição do parsing e os desafios de manter atualizados os dados e metadados de permissões.
17:36	Armazenamento e demonstração com relatórios financeiros	A demonstração usa busca híbrida e ferramentas de navegação para pesquisar relatórios da Alphabet e reunir informações de vários documentos.
20:46	Resposta fundamentada e conclusão	O agent revisa resultados, capturas de tela e contexto para montar uma resposta sobre fluxo de caixa, e a palestra conclui que o harness ajuda a tornar os resultados confiáveis.

Citações

No fim das contas, tudo se resume a manter os elementos fundamentais certos. — 05:14

Para casos de uso empresariais, geralmente recomendamos uma abordagem híbrida. — 10:54

Precisamos garantir que os metadados sejam marcados na camada de armazenamento vetorial. — 17:36

A busca ajuda você a encontrar informações, e o harness fornece resultados em que você pode confiar. — 22:51

Conceitos e entidades

George He (pessoa): Líder de engenharia da LlamaIndex e apresentador da palestra.
LlamaIndex (empresa): Startup que trabalha com parsing de documentos, orquestração e gestão do conhecimento.
Claude Code (ferramenta): Ferramenta citada como exemplo de busca local por arquivos sem pré-indexação vetorial.
busca híbrida (conceito): Combina busca por palavras-chave e busca semântica ou vetorial para recuperar documentos.
BM25 (conceito): Método de busca por palavras-chave mencionado como uma das opções de recuperação.
LlamaParse (ferramenta): Produto da LlamaIndex apresentado para parsing de documentos.
LightParse (ferramenta): Ferramenta open source da LlamaIndex para extração estruturada de conteúdo.
TurboPuffer (ferramenta): Armazenamento vetorial usado como exemplo na discussão sobre persistência e recuperação de dados.
Tesseract (ferramenta): Mecanismo de OCR mencionado como opção para processar documentos.
Amazon Textract (ferramenta): Pipeline de OCR citado como exemplo para extrair conteúdo de documentos.

Tradução completa (pt-BR)

00:01 [música] Vamos começar. É um prazer conhecer todos vocês. Meu nome é George. Hoje vou falar sobre busca, busca em documentos e sobre como conseguimos melhores resultados aqui na Llama Index. Meu nome é George. Sou o chefe de engenharia aqui na Llama Index. Somos uma startup série A. Nosso foco é bastante em

00:31 análise de documentos, orquestração e gestão do conhecimento. Hoje, o tema da palestra será como ajudamos clientes corporativos a ampliar a busca com GPT e, de modo geral, a gerenciar contexto usando orquestração agentic e ferramentas de infraestrutura em geral. O plano de hoje é discutir — ou debater — como orquestrar e realizar da melhor forma a busca em documentos, como obter os melhores

01:01 resultados e percorrer os desafios técnicos que encontramos, até chegar a uma demonstração ao vivo no final, se tivermos tempo. Certo. Para começar, a pergunta que gosto de fazer a todos é: quando e por que, especificamente, os agents precisam de contexto vetorial em algumas discussões — ou simplesmente de contexto, ponto final? A principal conclusão aqui é que, nos últimos anos, os modelos melhoraram muito em orquestração e em seguir instruções.

01:32 Eles conseguem percorrer sistemas de arquivos locais. Conseguem trabalhar com skills e MCP para recuperar informações de maneiras melhores do que antes. Mas ainda temos os problemas de busca local e de contexto local, certo? Para gerenciar grandes corpora e documentos complexos, a maneira mais fácil ainda é fazer isso localmente. Assim, há duas abordagens em evolução para orquestração: GPT — ou o que gosto de chamar de busca e execução de arquivos locais — e embeddings ou

02:04 pré-indexação e recuperação prévia. Vamos conversar sobre o que cada abordagem oferece, quando você pode preferir uma em vez da outra e quando faz sentido combinar as duas. Para começar a entender onde esse problema surgiu no setor, quando o Claude Code foi lançado, houve muita discussão sobre a mecânica interna de como o Claude Code funciona. É realmente interessante pensar em como percorrer e gerenciar o sistema de arquivos local quando se está fazendo programação como solução ou como

02:36 problema. A Anthropic adotou a abordagem de usar o sistema de arquivos local, leitura prévia e gerenciamento com glob, basicamente para gerenciar o sistema de arquivos local. Isso é perfeito para as necessidades de execução local, porque o código é fácil de gerenciar localmente. É conciso e já está em formato de texto. Mas você também vai notar que este tuíte de Boris, criador do Claude Code, destaca que o Claude Code experimentou um banco de dados vetorial, mas acabou não o escolhendo. E os motivos não são apenas

03:09 de desempenho, mas também de escalabilidade prática e manutenção. É difícil manter um índice vetorizado pré-indexado sincronizado, especialmente porque o código continua sendo atualizado. Assim, especificamente, a solução adotada pelo Claude Code — sem pré-indexação, sem RAG, sem busca vetorial — funciona muito bem, mas apenas por causa de algumas características do código. Eles não se preocuparam com a pré-indexação das informações porque o código no seu repo geralmente é pequeno. Geralmente é semiestruturado. Normalmente, seu código deixa

03:39 pistas sobre o que mais está sendo importado e testado. Também deixa uma hierarquia natural para orientar como um agent pode se movimentar pelo sistema de arquivos. E o mais importante é que o código já está no disco e localmente disponível, especialmente se o agent tiver contexto. Então, por que complicar as coisas com um sistema de recuperação prévia? A realidade é que, quando você passa para conjuntos de dados maiores de empresas — com imagens, PDFs e apresentações do PowerPoint misturados —, fica mais difícil

04:11 porque não há exatamente uma pasta para pesquisar. Não dá para pesquisar as pastas de um conjunto de dados de uma empresa, porque ele não é organizado como código, certo? Você precisa pensar em quanto esforço foi investido para organizar o código que você escreve, certo? Ele precisa estar sintaticamente correto. Precisa ter referências adequadas. Aí você olha para o banco de dados da empresa ou para o que estiver no seu data lake e percebe que é muito difícil manter tudo sincronizado, certo? A escala é completamente diferente. Você se preocupa muito mais com segurança: quem pode acessar quais informações. O formato não é padronizado. Você pode ter PDFs realmente

04:42 complexos, esquemas e diagramas de fabricação misturados, e a escala faz com que não seja mais possível executar isso localmente. Então, como manter um sistema sincronizado? O setor passou por muitas soluções diferentes. Você pode usar um servidor MCP ou tentar gerenciar isso usando o CLAUDE.md da Anthropic. Assim, além de ter esse conjunto de dados disponível em algum lugar, você acompanha a estrutura e informa ao agent: “Ei, você pode percorrer os dados deste jeito”, certo? Então, skills de MCP, Claude, arquivos de agent, arquivos de instruções: estas são

05:14 todas opções para acompanhar algum tipo de hierarquia. Mas a principal conclusão aqui é que tudo se resume à escala dos dados que você tem e ao esforço de organização que vai investir para manter esse sistema de recuperação ou de gestão de dados. Faz sentido, certo? As pessoas estão falando de engenharia de contexto, de harness, de criar um harness, mas, no fim das contas, tudo se resume a manter os elementos fundamentais certos no lugar. Mas, para fazer isso, você precisa entender a escala com que está lidando. Então, se você tem

05:45 de 100 a, sabe, 100 ou de 100 a mil arquivos, talvez seja adequado ficar apenas com a busca em arquivos locais, porque seu agent consegue gerenciar isso no contexto. Não vai consumir muitos tokens apenas percorrendo os arquivos ou lidando com os nomes literais dos arquivos enquanto navega. Mas, à medida que você cresce, chegando a milhares ou milhões de arquivos, isso não é possível. Você não quer consumir esses tokens. Não quer ler os arquivos todas as vezes. Você quer ter uma ideia aproximada de onde procurar, como uma agulha no palheiro; se não encontrar a agulha, pelo menos terá uma bússola aproximada para indicar

06:15 a direção que deve seguir, certo? Então, vamos falar um pouco sobre qual é a abordagem certa entre busca híbrida, busca semântica e a navegação tradicional por arquivos. Outro motivo para se importar com isso é, obviamente, que cada modelo aumenta sua capacidade de memória, certo? Agora temos contexto de 1 milhão de tokens. Antes eram 200 mil; antes disso, 100 mil; e ainda menos antes disso. O importante a considerar é que, conforme as capacidades dos modelos

06:46 aumentam, também aumenta o que você está disposto a pagar durante esse processo, certo? Você quer enviar esses tokens pelo pipeline de ingestão do modelo? Quer enviar dados binários para o modelo, para que ele tente renderizá-los talvez no próprio mecanismo e depois extraia os dados para a busca? Isso fica extremamente caro, certo, usar o contexto do modelo para ingestão e busca. E há soluções para usar subagents: um agent maior emite subcomandos para que um agent menor possa lidar com o contexto de memória, o excesso de memória e simplesmente devolver uma resposta. Mas

07:18 o problema é que cada subagent precisa de contexto completo, porque os subagents — embora possam usar modelos mais baratos ou simples —, se você já percebeu, no Claude Code, às vezes sua sessão principal pode emitir comandos para sub-sessões com modelos mais fracos para executar as tarefas. Os ambientes, na verdade, consomem muitos tokens e têm muita latência, certo? Então, para acelerar seu processo e garantir que você não consuma tokens

07:49 à toa, reprocessando documentos toda vez, talvez valha a pena criar um sistema de pré-indexação. Vamos falar um pouco sobre isso. Ao criar um harness e permitir que o agent escolha o que fazer, certo? Especificamente, não queremos que nosso sistema, nem qualquer sistema que possa escalar, decida manualmente: devo usar uma abordagem de RAG híbrida ou devo simplesmente

08:19 pesquisar individualmente os arquivos, e a maneira mais limpa que encontramos nesta era da engenharia é gerenciar isso com um harness. Então, dê ao seu agent as ferramentas necessárias para pesquisar arquivos específicos usando o bom e velho grep, o bom e velho cat, filtragem por nome de arquivo ou por metadados, além de filtragem semântica. E, assim, você consegue meio que aproveitar o melhor dos dois mundos ao percorrer os arquivos. Assim, consegue ter uma direção geral de quais arquivos quer pesquisar e usar a busca semântica para restringir o conjunto de arquivos.

08:50 e depois usar os recursos integrados de navegação por arquivos do seu agent para mergulhar no conteúdo detalhado e, assim, fundamentar de fato as respostas, em vez de alucinar. Então, quais são as cinco ferramentas que vamos abordar hoje para habilitar a busca em documentos — ou a busca complexa em documentos, como se vê nos setores de seguros, finanças e saúde, certo? Onde há uma enorme quantidade de dados sem categorização ou sem rótulos completos. Quais são as ferramentas que vamos usar? Certo? A primeira pergunta é: onde é que eu vou procurar?

09:21 Qual é a direção da bússola que vamos seguir? E aí você tem três ferramentas que estarão disponíveis e, sabe, há muitas outras no seu sistema de arquivos local para descobrir o que realmente existe nesse subconjunto, ou nesse subcorpus, de documentos que identificamos com a direção da bússola. Certo? Então, listar arquivos, percorrê-los por metadados, usar grep em arquivos específicos para verificar se há várias palavras-chave que tornam determinado documento mais relevante. Tudo isso pode ser executado em um pipeline de pré-indexação ou em um pipeline em tempo real. E a última é meio que

09:52 saber o que o documento realmente diz. E, especificamente para documentos multimodais, você precisa de uma maneira de renderizar previamente os documentos. Esta é uma abordagem um tanto singular para esquemas com várias páginas ou longos: no processo de pré-indexação, uma das partes mais importantes é dividir o documento em trechos digeríveis, certo? Mas isso se aplica não apenas ao lado textual, como também ao lado da renderização. Porque uma das partes mais difíceis da renderização de documentos em formato livre é que você precisa rasterizar ou renderizar o documento em uma

10:23 visualização adequada para humanos. Esses casos de uso geralmente envolvem situações em que uma pessoa teria feito isso, em vez de uma IA, certo? Esses esquemas, PDFs e PowerPoints não foram realmente criados para serem consumidos exclusivamente por máquinas. Então, dar ao agent um índice de capturas de tela já criado para pesquisar também é muito útil quando você está usando RAG. Certo. Vamos dar uma olhada em alguns detalhes da própria ferramenta. Então, em relação à recuperação em si, certo,

10:54 que é a direção da bússola. Há inúmeras abordagens possíveis. Existe graph RAG, RAG tradicional e a velha busca por palavras-chave BM25. Em geral, recomendamos uma abordagem híbrida para casos de uso corporativos. Principalmente porque a busca por palavras-chave tem seu lugar para desenvolvedores. Ela também tem seu lugar para agents de IA que procuram palavras específicas pré-indexadas em um corpus, certo? Ao mesmo tempo, o significado semântico e a similaridade são muito importantes. Combinar os dois por meio de uma busca híbrida costuma proporcionar resultados muito melhores.

11:25 Você pode ver em vários conjuntos de dados de benchmark que a busca bruta por palavras-chave ou por vetores leva a um patamar básico. Mas, quando você adiciona uma fusão, combinando e ponderando a busca por palavras-chave e a busca vetorial, obtém resultados melhores, porque não fica limitado pelas especificidades do seu método de busca. E reclassificar os resultados finais — por exemplo, pegar os 100 primeiros e reclassificá-los usando um LLM ou algum outro processo mais aprofundado — acaba levando a resultados de recuperação muito melhores. Mas essa é só uma parte do pipeline, certo? Essa é a busca nos documentos. O que nos importa são

11:56 os resultados. E então, vamos falar e mostrar mais tarde as ferramentas de dois a quatro. Depois de ter a direção da bússola — qual é o grupo geral de arquivos que pode ser relevante, quais metadados podem estar mais relacionados à sua consulta —, como talvez o seu agent não conheça todos os metadados nem o conteúdo extraído do seu sistema no início, ele pode percorrer a hierarquia de arquivos, procurar arquivos semelhantes no corpus que nem sequer apareceram na busca inicial, para ampliar a busca e depois restringir ainda mais

12:27 os resultados. Então, é muito importante dar ao seu agent as operações básicas para listar os arquivos, usar grep e ler os que você tem localmente, em um sistema de arquivos compartilhado e distribuído — especialmente se você não quiser baixar os arquivos para o contexto do agent toda vez, o que pode sair caro. E, aprofundando um pouco mais no próprio conteúdo, certo? É aqui que documentos complexos — por exemplo, materiais com gráficos, digitalizados ou com esquemas —

12:58 deixam de funcionar bem com o fluxo de trabalho tradicional de indexação e divisão em trechos de documentos, porque não são uma linha de texto legível por humanos; são uma representação separada. Então, também é importante pensar em como fazer o fluxo de pré-indexação e de análise sintática para não precisar reler os documentos toda vez que usar seu agent. Você não quer gastar esses tokens codificados em binário toda vez que quiser ler um documento novo. Por isso, geralmente recomendamos pré-indexar ou analisar previamente seus documentos usando um fluxo de análise estruturada. Temos um

13:30 produto chamado Llama parse. Também disponibilizamos como open source uma ferramenta chamada light parse, que lida com a extração de conteúdo estrutural. Isso serve, por exemplo, se você tem tabelas, gráficos ou informações segmentadas: quer codificá-los em Markdown ou em algum formato cuja disposição espacial o seu agent consiga realmente entender. Porque, quando você tem dados multimodais, o raciocínio espacial é importante. A última coisa é que, claro, no seu fluxo de análise prévia, geralmente você quer gerar capturas de tela enquanto renderiza a página. Então, seja lá o que estiver fazendo para analisar previamente os documentos, provavelmente também vai querer armazenar e

14:01 preservar as capturas de tela geradas durante a renderização dos documentos. Nem sempre fica claro se algo é texto ou se tem metadados associados. Provavelmente, você vai querer combinar as duas coisas. Então, a análise sintática é uma parte importante, mas não é a única parte de um pipeline. Em geral, recomendamos que as pessoas pensem em como distribuir a análise e em como expandir a escala para melhorar o pipeline de análise. Há algumas métricas que eu recomendaria considerar, caso sejam relevantes para o seu pipeline, e meio que

14:32 como otimizar ou melhorar o pipeline em cada uma dessas dimensões. Então, se você despejar seus dados em um pipeline tradicional de OCR, como o Textract, ou usar um mecanismo de OCR como o Tesseract, ele realmente captura as tabelas e sua representação? Até que ponto ele preserva a disposição real do conteúdo? Certo? Porque, se você errar nisso, o LLM vai sofrer mais adiante, na etapa de leitura semântica. Talvez tudo funcione bem no começo, mas, se o LM não entender a localização e o raciocínio espacial, tudo

15:03 desmorona em algum momento. Certo, antes de chegarmos à demonstração, há apenas algumas ressalvas a considerar ao montar um pipeline de produção de verdade, certo? Isso é importante quando você tem clientes de verdade que se importam em usá-lo e ampliá-lo. Há algumas questões que sempre aparecem. Por exemplo, a multilocação: uma pessoa consegue ver os dados de outra? Como os metadados de permissões são incorporados? Certo? Se estou usando o Google Drive ou o SharePoint, como faço para obter esses metadados de permissões sem fazer com que todo o sistema

15:34 parar por completo ou funcionar sem reindexar e reprocessar os pipelines toda vez? E isso está relacionado ao último ponto, que é a atualização dos dados, certo? É mais ou menos por isso que a Anthropic e muitas outras empresas desistiram de tentar pré-indexar dados: é muito difícil manter os dados atualizados quando eles são complexos e também há metadados que precisam estar atualizados. Certo. Para explicar isso de um jeito mais simples, gostamos de pensar no processo de sincronização em três etapas, certo? A primeira é a ingestão propriamente dita. Conseguimos colocar todos os seus

16:04 documentos em um sistema sincronizado? A segunda etapa é a análise sintática: como convertemos de fato seus documentos para um formato padronizado? Para os casos de uso de hoje, vamos falar sobre converter todos os documentos para um formato Markdown ou de texto. Mas também há outros formatos que você pode usar se só se importar com representações multimodais. E a última etapa, obviamente, é reorganizar esses dados e exportá-los para um estado pré-indexado, para torná-los disponíveis para todas as ferramentas e etapas sobre as quais falamos

16:35 antes. Certo. Vou pular esta parte por causa do tempo. Um ponto importante que queremos destacar aqui é que armazenar seus dados é realmente importante. Para distribuir seus dados, normalmente você quer algum tipo de sistema de armazenamento em camadas. Muitos serviços de armazenamento vetorial guardam tudo na memória. Em geral, é preciso lidar com a seguinte escolha: quero manter os dados no disco e carregá-los depois em um armazenamento mais rápido na memória, ou quero manter tudo no armazenamento em memória?

17:05 Para nós, lidamos com esse problema em um nível multi-tenant, com milhões, dezenas de milhões de documentos. Nossa recomendação é persistir os dados em disco e, em seguida, ter uma camada de memória isolada para recuperar os dados com mais eficiência. Para os casos de uso de hoje, vamos analisar o turbopuffer. O turbopuffer, assim como a maioria dos armazenamentos vetoriais, também lida com permissões, certo? Então, quais metadados você tem? Como você carrega os dados? Isso é uma parte realmente importante para o sucesso do seu sistema

17:36 porque, quando você tem documentos demais, precisa filtrá-los por metadados. Então, colocamos isso na camada de armazenamento vetorial. À medida que os dados são ingeridos, vamos garantir que essas informações sejam marcadas nos armazenamentos vetoriais. Certo. Vamos passar para uma demonstração. Para a demonstração de hoje, a ideia é pensar em como o agent vai usar os subcomponentes para fornecer uma resposta fundamentada, que consiga percorrer vários documentos e realmente apresentar um resultado com o qual você fique bastante

18:07 satisfeito. Certo. Vamos passar por isso aqui. Vamos ver. Certo. Nesta demonstração, teremos um conjunto de documentos pré-indexados, disponível a partir de uma fonte de dados que definimos previamente. São 135 arquivos derivados dos relatórios financeiros da Alphabet, certo? Então,

18:39 temos todos esses arquivos HTML, misturados com arquivos PDF brutos. Se você olhar para eles, verá que importamos os metadados sobre onde essas informações podem ser encontradas. Se você tiver metadados dos arquivos disponíveis, poderá depois marcá-los com o ano de origem ou com a empresa específica a que pertencem, o que dá aos seus agents a capacidade de filtrar os dados. E o que vamos ver aqui é que, no seu fluxo de recuperação híbrida, você terá a opção de

19:10 priorizar mais palavras-chave ou mais a semântica no fluxo de recuperação. Por enquanto, vamos equilibrar os dois e pesquisar quaisquer demonstrações de fluxo de caixa. Vamos conversar sobre as ferramentas que seu agent usaria durante esse processo. Certo? O que vocês estão vendo à direita é o conjunto de trechos retornados pela nossa consulta, além de capturas de tela das páginas correspondentes, que mostram essencialmente a página de onde vieram. Então, essas duas coisas

19:41 juntas dão aos seus agents a capacidade de filtrar até um trecho específico e pedir o contexto em torno dele de um jeito muito mais simples do que antes. Depois, você pode pensar em como faria um grep por um trecho específico de texto no arquivo, certo? E se você tiver um padrão de expressão regular que esteja procurando? Neste caso, você está procurando especificamente por fluxo de caixa e pode encontrá-lo facilmente. Para encontrá-lo em um arquivo específico, basta executar um comando grep e ler o deslocamento desse comando, além do tamanho máximo que você quer.

20:13 Então, este é um arquivo diferente. Vou dar um exemplo. Se avançarmos 500 caracteres e buscarmos os mil seguintes, teremos este texto disponível, certo? Com essas duas ferramentas, esse conjunto de ferramentas, seu agent não precisa mais dos arquivos em um sistema de arquivos local. Você pode interagir com o que, na prática, é um armazenamento remoto de arquivos, sem precisar inicializar ou baixar todos os dados que teriam de ser transferidos para o seu sistema. Isso dá ao agent um conjunto de capacidades muito mais amplo

20:46 sem precisar baixar todas as informações e gastar tokens. Vamos para um exemplo de conversa, que vou abrir aqui. Então: “Mostre o fluxo de caixa em uma tabela, de 2021 a 2025, e a receita em uma tabela.” Certo. Só um instante. Executar

21:17 isso de novo. Aguarde alguns segundos. Enquanto isso está rodando, vou mostrar a vocês os resultados finais. Vamos para a conversa. Isso vai aparecer na linha do tempo do fluxo da conversa. Vamos ver. Ainda está processando. Enquanto o agent percorre o processo de recuperar as respostas do corpus, ele vai analisar o

21:48 corpus emitindo comandos de busca, certo? À medida que emite esses comandos, você quer que seu agent possa revisar as capturas de tela, revisar o contexto e, então, determinar de forma mais abrangente o que é realmente relevante para a busca. Assim, você consegue acompanhar o processo, ler arquivos específicos, pesquisar os arquivos novamente e ajustar o escopo das consultas. No fim, isso dá um resultado muito mais claro, certo? Nesta resposta do agent, você pode ver o resumo do fluxo de caixa, que foi

22:20 extraído de vários arquivos como parte do processo de raciocínio. Quando entramos no fluxo de navegação, geralmente conseguimos encontrar e fundamentar as respostas em um arquivo específico, o que dá muito mais confiança de que seus agents encontraram o componente ou trecho correto. É isso que buscamos, no fim das contas, na recuperação baseada em agents. Certo, vamos voltar aqui. Vamos conferir essa sessão quando terminar de transmitir. Mas a ideia e a conclusão são que a busca ajuda você a encontrar informações, e o harness fornece resultados em que você pode confiar. Então, certo, se tiver interesse, fique à vontade para visitar o código QR aqui. Obrigado. >> [música]

22:51 A principal conclusão é que, sabe, a busca ajuda você a encontrar informações, e o harness fornece resultados em que você pode confiar. Então, se tiver interesse, fique à vontade para acessar o QR code aqui. Obrigado. >> [música]

Transcrição original

[00:01] [music] We’re going to get going. Nice to meet you everyone. Uh my name is George. Uh today uh we’ll be going over a talk on search document search and uh how we get better results here at Llama Index. Um my name is George. I’m the head of engineering here at Llama Index. We are a series A startup. We focus quite a bit

[00:31] on document parsing, orchestration and uh knowledge management. Um today the topic of the talk will center around how we’ve helped enterprise customers scale up search GP and generally manage context using aentic orchestration and just general infrastructure tooling. Uh the plan today is going to be going through a discussion or a debate around uh how to best orchestrate and perform document search uh how to get the best

[01:01] results and we’ll iterate through their uh technical challenges that we’ve seen all the way to a live demo at the end if we do have time. All right. So to get started um the question that I like to pose to everyone is when and why specifically do agents need vector context in some discussions or just context period. Um and the major takeaway here is over the last few years models have gotten much better at orchestration and instruction following.

[01:32] They’re able to traverse local file systems. They’re able to work with skills MCPS in order to retrieve information in ways that are better than before. But you still have your local search and your local context problems, right? Um in order to manage large corpuses, in order to manage complex documents, easiest way is still to manage it locally. Um and so there are kind of two evolving approaches to orchestration uh between GP or what I like to call kind of local file search and file execution or embeddings or

[02:04] pre-indexing pre- retrieval. Um we’ll kind of talk through what the different approaches offer and when you might prefer one over the other or when it’s appropriate to do a hybrid of both. Uh to get started in understanding where this problem kind of popped up in industry u when cloud code launched uh you know there was a lot of discussion around the internal mechanics of how cloud code works. It’s actually a really interesting problem to think about how you’re going to traverse and manage your local file system if you’re going to go through coding right as a solution or a

[02:36] problem. Um, and Anthropic’s taken the approach of using your local file system prep read using glob management basically to manage your local file system and it’s perfect for your local execution needs because code is easy to manage locally. It’s concise and it’s already in text format. But you’ll also notice that um this tweet by Boris uh cloud code creator kind of highlights that uh cloud code experimented with a vector database didn’t end up choosing it and the reasons aren’t just for

[03:09] performance reasons but because of practical scaling and maintenance reasons. It’s hard to keep a pre-indexed vectorized index in sync especially as code keeps on updating. And so specifically the solution that cloud code took which was no pre-indexing, no rag, no vector search, uh works really well but only because of a few characteristics of code. Um they did not care about pre-indexing information because the code in your repo is usually small. It’s usually semistructured. Usually your code leaves

[03:39] breadcrumbs for what else is being imported, what else is being tested. Um and it leaves a natural hierarchy for how an agent might move about your file system. Um and the largest part there is code is already on disk and local uh especially if your agent has context. So why complicate it with a pre pre- retrieval system? And the reality is when you switch over to larger company data sets uh where you have images, you have PDFs, you have powerpoints mixed in uh it’s harder

[04:11] because there’s not really a folder to grip. Uh you can’t really grip the folders across a company data set because it’s not organized like code, right? You have to think about how much effort has been put into curating the code that you write, right? It must be syntactically sound. It must have proper references. And then you see your company database or you know whatever is in your data lake. Um and you realize it’s really hard to keep things in sync, right? The scale is at a completely different level. Uh you care quite a bit more about security. Uh who can access what information. Uh the format is not standardized. you might have really

[04:42] complex PDFs, schematics, manufacturing diagrams mixed in and the scale just makes it so that you can’t run this locally anymore. So, how do how do you keep a system in sync? Right? The industry has gone through many different solutions. Um, you can use MCP server, you can try to manage this using Anthropics CloudMD. So, you in addition to having just this blob of a data source available somewhere, you keep track and let your agent know, hey, you can traverse the data this way, right? So MCP skills, claude, claude, uh agent

[05:14] files, instruction files, these are all options for keeping track of some type of hierarchy. But the major takeaway here is actually it really comes down to the scale of the data that you have and how much curation effort you’re going to put in in order to maintain that retrieval system or that data management system. That makes sense, right? People are talking about context engineering, about harness, you know, making a harness, but at the end of the day, it’s all about keeping the right primitives in place. Um but in order to do that you have to understand what’s the scale that you’re dealing with right so if you have

[05:45] 100 to you know 100 or you know 100 to a thousand files uh it may be appropriate to just keep down to local file search because your agent can manage this in context. It won’t burn too many tokens just iterating through files or managing the literal file names as it traverses. Um but as you scale out right to thousands or millions of files that’s not possible. You don’t want to burn those tokens. uh you don’t want to read the files every single time. You want to have some needle in the haststack sense of roughly where you’re looking for at least if it’s not the needle in the haststack. It’s a rough compass on the

[06:15] direction you should be going, right? Um and so we’ll talk a bit about kind of what the right approach is uh between hybrid based search, semantic based search as well as uh your old school file traversal here. Uh the other reason for why you might care about this is obviously as each model increases in its memory capabilities, right? We got 1 million token context length now. Uh before it used to be 200k, before that 100k and even smaller before that. Um the important thing to think about here is actually as the model capabilities

[06:46] increase what you’re willing to pay as you’re going through this process, right? Do you want to shove those tokens through the model’s ingestion pipeline? Do you want to uh send binary data over to your model for it to try to render in maybe its own engine and then extract data out of uh for your search? um it just becomes extremely expensive, right? In order to use your model context for ingestion and search. Um and you know there have been solutions around how you can use sub agents right have one larger agent issue subcomands so that a smaller

[07:18] agent can deal with the memory context the memory bloat and just give a response back. Um but the issue there is because each sub aent needs full context because sub aents uh even though they might use cheaper or simpler models uh if you’ve noticed in cloud code sometimes your you know main session may issue commands to weaker model uh sub sessions in order to execute the jobs. um the environments are actually rather tokenheavy and latencyheavy, right? So in order to speed up your process and make sure that you’re not burning tokens

[07:49] unnecessarily reprocessing documents each time, uh you may actually think about building out a pre-indexing system. Um and so we’ll kind of talk about that here. Um in kind of building out a harness and letting it agent choose what’s going on, right? So uh specifically we don’t really want our system or any system that can scale out to be manually deciding uh should I use a hybrid rag approach or should I just

[08:19] individually search through files and the cleanest way that we found that in this era of engineering is uh managing that with a harness. So give your agent the tools needed to either search through specific files using your old school GP, your old school cat, file name filtering or metadata filtering in addition to semantic filtering. Um, and that way you can get kind of the best of both worlds going through traversal. uh so you can get the rough direction of which files you want to search and use semantic search to down scope your files

[08:50] and then using your agent’s built-in file traversal capabilities to dig into the meat of the details so that you can actually ground your answers instead of hallucinating them. So the five tools that we’ll talk through today um in enabling kind of document search or uh complex document search uh as you might see in like insurance, finance, healthcare industries, right? Where you just have a ton of unatategorized or semilablled data is what are the tools that we’re going to use? Right? So the question first is where am I even going to look?

[09:21] What’s the compass direction we’re going to go? Um and then you have three tools that are going to be there and you know you have a lot more of these in your local file system to figure out what actually is in this subset or this subcorpus of documents that we’ve identified with our compass direction. Right? So listing files, traversing files by metadata, uh gpping specific files to see if there are multiple keywords available that make a specific document more desirable. These are all things that you could run in a pre-indexing pipeline or a live pipeline. Um, and the last one is kind

[09:52] of, you know, what does the document actually say? And specifically for multimmodal documents, you need a way to pre-render the documents. And this is one kind of unique approach uh to multi-page or long schematics, which is in your pre-indexing process, one of the most important parts is to chunk or break your document down into digestible portions, right? But that applies to not just the textual side, but also the rendering side. uh because one of the hardest parts of free form document rendering is you actually have to rasterize or render the document into a

[10:23] human compatible view. Uh these use cases are usually where you have an actual person that would have done this uh instead of AI, right? So these schematics, these PDFs, these PowerPoints, they’re not really built for pure machine consumption. Um so giving the agent a pre-built screenshot index to search through is also very useful as you’re performing rag. All right. So, we’ll take a look at some of the details of the tool itself. Um, so in terms of retrieval itself, right,

[10:54] which is the compass direction. There are tons of approaches you can take here. There’s graph rag, there’s traditional rag, there’s kind of your old school keyword- based BM25 search. Um, we we usually recommend a hybrid for enterprise use cases. And that’s just mostly because uh keyword-based search has its place for developers. Keyword based search also has its place for AI agents that are looking for specific pre-indexed words in a corpus, right? Um at the same time, semantic meaning and similarity is really important. Uh combining the two through a hybrid based search usually gives to much gives you

[11:25] much better results. Um you can see in various benchmarking data sets that you know just raw keyword or vector will get you to a baseline. But when you put in a fusion, you know, you combine and weight uh keyword as well as vector search, you get better results uh because you aren’t blinded by, you know, specifics of your search uh method. And re-ranking the final results, you know, you might take the top 100, re-rank them using an LLM or some other deeper process uh ultimately gets you much better retrieval results. U but that’s just one part of the pipeline, right? That’s the document search. Uh we care about

[11:56] results. Um and so tools two through four we’ll talk through and kind of show later which is um once you have the compass direction of what are the what is the general group of files that might matter right what’s the metadata that might associate most closely with your query uh because your agent at the start might not know all the metadata or the extracted content of your system um it can then traverse through the file hierarchy uh search for similar files inside of your corpus that weren’t even returned in that initial search in order to expand out and then further narrow

[12:27] down its results. Um, so giving your agent the primitives of listing out the files GP and read that you have locally is really important in a shared and distributed file system, especially if it’s one that you don’t want to download onto your agents context every single time, which can get expensive. And um, diving a bit deeper into the content itself, right? Um this is where uh complex documents like you know stuff with charts, stuff that’s scanned in, stuff that has uh you know schematics

[12:58] for example kind of breaks apart for your traditional document indexing and chunking workflow because it is not a human read line of text right it’s a separate representation. Um and so thinking about how you do your pre-indexing flow and parsing flow uh so that you don’t have to reread the documents every single time using your agent is also important. you don’t want to burn those uh you know binary encoded tokens every single time you want to read a new document. So we usually recommend pre-indexing uh or pre-parssing your documents using uh structured parsing flow. Um we have a

[13:30] product called Llama parse. We’ve also open sourced a tool called light parse which handles structural content extraction. So this is like if you have tables, charts or segmented uh information, you want to encode that as either markdown or just something that your agent really can understand the spatial reasoning of. uh because when you have multimmodal data uh spatial reasoning is important. Last one there is of course uh in your pre-parssing flow you usually want to generate those screenshots as you actually render the page right. So whatever you’re doing for pre-parssing you probably also want to store and

[14:01] persist screenshots as they’re being generated from document rendering. Uh it’s not always clear if something is text or is you know got metadata associated with it. You probably want to combine the two together. Um and so parsing is an important part but it’s not the only part of a pipeline. Uh we usually you know advocate for people to think about how you can distribute parsing um and think about scaling out to improve your parsing pipeline right um there are some metrics that I would advocate for people to think about you know if they’re relevant to your pipeline and uh kind of

[14:32] how you can optimize or uh improve your pipeline for each of those dimensions. So if you dump your data into a traditional OCR pipeline like Textract uh or you use a OCR engine like Tesseract um does it actually capture the tables the table representation? How faithful is it to act the actual content layout? Right? Because if you get those wrong your LLM on its semantic reading side later down the line is going to pay for it. Uh it might be fine at the start but if your LM doesn’t understand the location and spatial reasoning it falls

[15:03] apart um at some point. All right, so before we get to the demo, uh there are just a few caveats to think about with building out an actual production pipeline, right? Which is when you have actual customers that care about using it and scaling it out. There are a few things that will always be brought up. Um there’s like multi-tenency, you know, can one person see another person’s data? How does permissioning metadata get pulled in? Right? if I’m using Google Drive or if I’m using SharePoint, how do I pull in and yank that permission metadata without causing the whole system to

[15:34] grind to a halt or without reindexing and repparssing the pipelines each time? Um, and that’s related to the last one which is freshness, right? This is kind of why Anthropic, a lot of other companies have kind of given up on trying to pre-index data uh because data freshness is really hard to achieve if your datas are complex, your data is complex, and you also have metadata that needs to be up to date. All right. So, uh in order to break it down more easily, um we like to think about the synchronization process as three steps, right? One is pure ingestion. You know, can we get all your

[16:04] documents into a synchronized system? Uh the second step is going to be parsing, which is how do we actually convert your document to a standardized format. Uh for our use cases today, we’ll talk through converting all documents into a markdown or a text format. But there are also other formats you can use if you only care about multimodal representations. Um and last stage is obviously uh rebungging that data and then exporting it into a pre-index state um in order to make it available for all of the tools and steps that we talked

[16:35] about before. All right. So uh I’m going to skip through this uh for the sake of time. Um, one major thing that we want to highlight here is, you know, storing your data is actually quite important. Um, in order to distribute your data out, you usually want some type of layered storage system. Um, a lot of vector storage, uh, services store everything on memory. Um, usually you’re playing with some trade-off of do I want it on disk and then loaded into a faster memory store or do I want everything

[17:05] just in the memory store. Um, for us, you know, we’ve dealt with this problem at the multi-tenant level to, you know, millions, tens of millions of documents. Our recommendation here is to try to persist your data onto disk and then have a shielded memory layer in order to retrieve the data more efficiently. Uh for our use cases today, we’ll be looking at turbopuffer. Um and turbopuffer as well as most vector stores will also handle uh permissioning, right? So what’s the metadata that you have? How do you pull the data in? Uh is actually quite an important part of your system success

[17:36] because when you have too many documents, you need to filter by metadata. Um, so we push that into the vector storage layer. You know, as the data is being ingested, let’s just make sure we tag that into the vector stores. All right. So, uh, we’re going to jump through a demo. Um, and for the demo today, the the process to think about is, you know, how is the agent going to use the subcomponents in order to actually give you a response that’s grounded that actually can traverse multiple documents and actually gets you gets you a result that you’re pretty

[18:07] happy with. Um, all right. So, we’ll go through there here. Uh, let’s see. All right. So, in this demo, um, we will have a pre-index set of documents um that is available from a data source that we’ve defined ahead of time. This is going to be 135 files uh that are derived from Alphabet’s financial reports, right? So,

[18:39] we have all these uh htm files, they’re mixed in with raw PDF files and if you actually look at them, uh we’ve pulled in the metadata for where this information can be found. So if you have file metadata available along with uh you know later on you can tag this with uh the year that it came from or the specific company it came from that gives your agents the capabilities to filter down uh the data. Um and what we’ll see here is uh in your hybrid retrieval flow right uh you’ll have the option of if

[19:10] you want to be more keyword based or more semantic based in your retrieval flow. Um let’s just do a even balance for now and we’re going to search for uh just any cash flow statements and we’ll talk through kind of the tools that your agent would want to use along this process. Right? So um what you’ve seen here on the right is the set of chunks that are returned from our query as well as page screenshots that correspond to uh what is essentially uh the page that it came from. Right? So these two

[19:41] together gives your agents the capability to uh filter down to a specific chunk and request context around that specific chunk in a much cleaner way than before. Um you then might want to think about how you would GP for a specific uh piece of text in the file, right? So what happens if you have a reax pattern that you’re looking for uh you know now you’re looking specifically for cash flow um and you can find that easily. uh in order to find that in a specific file, all you need to do is issue a GP command and then read from that specific command

[20:13] kind of what that offset is and then uh kind of what the max length is that you want. So, uh this is a different file. So, I’ll just give an example. You know, if we offset 500 characters and pull in the next thousand, we’ll end up with this text being available, right? So, with these two tools, this suite of tools together, your agent doesn’t really need the files on a local file state anymore. um you can interact with what is effectively a remote file storage without needing to spin up or download all the data that would need to be streamed to your system. Um and that uh gives the agent a much more capable

[20:46] uh set of capabilities without actually downloading all the information and burning the tokens. So we will uh go to a chat example and I’m going to pull it up here. So uh give me the cash flow from as a table from 2021 to 2025 income as a table. All right. So give me a second here. Run

[21:17] this again. Give it a few seconds. Uh, while that’s running, I’m going to show you guys the end results. Uh, let’s go to the chat. So, this is going to be in the chat flow timeline. Um, let’s see. Still thinking there. So, as the as an agent is running over the over the process of, you know, retrieving your answers from the corpus, it’s going to look through uh your

[21:48] corpus by issuing search commands, right? And as it’s issuing the search commands, you want your agent to be able to review the screenshots, review the context, and then determine what is actually relevant for its search in a much more holistic way, right? So you get to think through the process, you get to read specific files, you get to search through files again and rescope your queries. And in the end, that gives you a much cleaner result, right? So uh in this agent response uh you can see the cash flow summary uh by you know and

[22:20] you can see that it’s been pulled in from multiple files as part of its thinking process. So when we do go into the traversal flow um you can usually find and ground your answers in uh in a specific file and that gives you much more confidence that your agents found the right component or the right chunk. Um, you know, that’s what we’re looking for at the end of the day for agent-based retrieval. All right, so we’re going to jump back here. We’ll take a look at uh that session once it finishes streaming. Uh, but you know, the idea here and the

[22:51] takeaway is that, you know, search helps you find information and the harness gives you the results that you can trust. So, okay, if you’re interested, um, feel free to, uh, visit the QR code here. Thank you. >> [music]