Início Tecnologia Esta estrutura de pesquisa em árvore atinge 98,7% em documentos onde a...

Esta estrutura de pesquisa em árvore atinge 98,7% em documentos onde a pesquisa vetorial falha

9
0

Uma nova estrutura de código aberto chamada Índice de página resolve um dos velhos problemas da geração aumentada de recuperação (RAG): lidar com documentos muito longos.

O fluxo de trabalho RAG clássico (agrupar documentos, calcular embeddings, armazená-los em um banco de dados vetorial e recuperar as principais correspondências com base na similaridade semântica) funciona bem para tarefas básicas, como perguntas e respostas sobre documentos pequenos.

PageIndex abandona totalmente o método padrão de “pedaço e incorporação” e trata a recuperação de documentos não como um problema de pesquisa, mas como um problema de navegação.

Mas à medida que as empresas tentam migrar o RAG para fluxos de trabalho de alto risco – auditoria de demonstrações financeiras, análise de contratos legais, navegação em protocolos farmacêuticos – elas estão atingindo uma barreira de precisão que a otimização de blocos não consegue resolver.

AlphaGo para documentos

O PageIndex aborda essas limitações pegando emprestado um conceito da IA ​​dos jogos, em vez dos mecanismos de pesquisa: pesquisa em árvore.

Quando os humanos precisam encontrar informações específicas em um livro denso ou em um longo relatório anual, eles não examinam cada parágrafo de forma linear. Eles consultam o índice para identificar o capítulo relevante, depois a seção e, finalmente, a página específica. PageIndex força o LLM a replicar esse comportamento humano.

Em vez de pré-calcular vetores, o framework constrói um “Índice International” da estrutura do documento, criando uma árvore onde os nós representam capítulos, seções e subseções. Quando chega uma consulta, o LLM realiza uma pesquisa em árvore, classificando explicitamente cada nó como relevante ou irrelevante com base no contexto completo da solicitação do usuário.

Como funciona o PageIndex (fonte: PageIndex GitHub)

“Em termos de ciência da computação, um índice é uma representação estruturada em árvore de um documento, e navegar nele corresponde à pesquisa em árvore”, disse Zhang. “O PageIndex aplica a mesma ideia central – pesquisa em árvore – para recuperação de documentos e pode ser pensado como um sistema estilo AlphaGo para recuperação, e não para jogos.”

Isso muda o paradigma arquitetônico da recuperação passiva, onde o sistema simplesmente busca o texto correspondente, para a navegação ativa, onde um modelo de agente determine onde procurar.

Os limites da similaridade semântica

Há uma falha elementary na forma como RAG tradicional lida com dados complexos. A recuperação vetorial assume que o texto mais semanticamente semelhante à consulta de um usuário é também o mais relevante. Nos domínios profissionais, esta suposição frequentemente falha.

Mingtian Zhang, cofundador da PageIndex, aponta os relatórios financeiros como um excelente exemplo deste modo de falha. Se um analista financeiro perguntar a uma IA sobre “EBITDA” (lucro antes de juros, impostos, depreciação e amortização), um banco de dados vetorial padrão recuperará cada pedaço onde aquela sigla ou termo semelhante aparecer.

“Várias seções podem mencionar o EBITDA com redação semelhante, mas apenas uma seção outline o cálculo preciso, os ajustes ou o escopo do relatório relevante para a questão”, disse Zhang à VentureBeat. “Um recuperador baseado em similaridade luta para distinguir esses casos porque os sinais semânticos são quase indistinguíveis.”

Esta é a lacuna “intenção versus conteúdo”. O usuário não deseja encontrar a palavra “EBITDA”; eles querem entender a “lógica” por trás disso naquele trimestre específico.

Além disso, os embeddings tradicionais retiram o contexto da consulta. Como os modelos de incorporação têm limites rígidos de comprimento de entrada, o sistema de recuperação geralmente vê apenas a pergunta específica que está sendo feita, ignorando os turnos anteriores da conversa. Isso separa a etapa de recuperação do processo de raciocínio do usuário. O sistema compara os documentos com uma consulta curta e descontextualizada, em vez do histórico completo do problema que o usuário está tentando resolver.

Resolvendo o problema de raciocínio multi-hop

O impacto no mundo actual desta abordagem estrutural é mais visível em consultas “multi-hop” que exigem que a IA siga uma trilha de localização em diferentes partes de um documento.

Em um teste de benchmark recente conhecido como FinanceBench, um sistema construído em PageIndex chamado “Mafin 2.5“alcançou uma pontuação de precisão de última geração de 98,7%. A lacuna de desempenho entre esta abordagem e os sistemas baseados em vetores fica clara ao analisar como eles lidam com referências internas.

Zhang oferece o exemplo de uma consulta sobre o valor whole dos ativos diferidos em um relatório anual do Federal Reserve. A seção principal do relatório descreve a “mudança” no valor, mas não lista o whole. No entanto, o texto contém uma nota de rodapé: “Ver Apêndice G deste relatório… para informações mais detalhadas.”

Um sistema baseado em vetores normalmente falha aqui. O texto no Apêndice G não se parece em nada com a consulta do usuário sobre ativos diferidos; provavelmente é apenas uma tabela de números. Como não há correspondência semântica, o banco de dados vetorial a ignora.

O recuperador baseado no raciocínio, entretanto, lê a sugestão no texto principal, segue o hyperlink estrutural para o Apêndice G, localiza a tabela correta e retorna o valor exato.

A compensação da latência e a mudança de infraestrutura

Para arquitetos corporativos, a preocupação imediata com um processo de pesquisa orientado por LLM é a latência. As pesquisas de vetores ocorrem em milissegundos; fazer com que um LLM “leia” um índice implica uma experiência do usuário significativamente mais lenta.

No entanto, Zhang explica que a latência percebida para o usuário ultimate pode ser insignificante devido à forma como a recuperação é integrada ao processo de geração. Numa configuração clássica do RAG, a recuperação é uma etapa de bloqueio: o sistema deve pesquisar o banco de dados antes de começar a gerar uma resposta. Com o PageIndex, a recuperação acontece inline, durante o processo de raciocínio do modelo.

“O sistema pode iniciar o streaming imediatamente e recuperá-lo à medida que é gerado”, disse Zhang. “Isso significa que o PageIndex não adiciona uma ‘porta de recuperação’ additional antes do primeiro token, e o Time to First Token (TTFT) é comparável a uma chamada LLM regular.”

Essa mudança arquitetônica também simplifica a infraestrutura de dados. Ao eliminar a dependência de incorporações, as empresas não precisam mais manter um banco de dados de vetores dedicado. O índice estruturado em árvore é leve o suficiente para ser colocado em um banco de dados relacional tradicional como o PostgreSQL.

Isso aborda um problema crescente em sistemas LLM com componentes de recuperação: a complexidade de manter os armazenamentos de vetores sincronizados com documentos vivos. PageIndex separa a indexação da estrutura da extração de texto. Se um contrato for alterado ou uma política atualizada, o sistema poderá lidar com pequenas edições reindexando apenas a subárvore afetada, em vez de reprocessar todo o corpus do documento.

Uma matriz de decisão para a empresa

Embora os ganhos de precisão sejam convincentes, a recuperação da pesquisa em árvore não é um substituto common para a pesquisa vetorial. A tecnologia é melhor vista como uma ferramenta especializada para “trabalho profundo”, em vez de uma ferramenta abrangente para todas as tarefas de recuperação.

Para documentos curtos, como e-mails ou registros de bate-papo, todo o contexto geralmente cabe na janela de contexto de um LLM moderno, tornando desnecessário qualquer sistema de recuperação. Por outro lado, para tarefas puramente baseadas na descoberta semântica, como recomendar produtos similares ou encontrar conteúdo com uma “vibração” semelhante, os embeddings vetoriais continuam sendo a escolha superior porque o objetivo é a proximidade, não o raciocínio.

O PageIndex se encaixa perfeitamente no meio: documentos longos e altamente estruturados onde o custo do erro é alto. Isso inclui manuais técnicos, registros da FDA e acordos de fusão. Nestes cenários, o requisito é auditabilidade. Um sistema empresarial precisa ser capaz de explicar não apenas a resposta, mas também o caminho que percorreu para encontrá-la (por exemplo, confirmando que verificou a Seção 4.1, seguiu a referência ao Apêndice B e sintetizou os dados ali encontrados).

PageIndex versus RAG

Crédito da imagem: VentureBeat com Nano Banana Professional

O futuro da recuperação de agente

A ascensão de estruturas como PageIndex sinaliza uma tendência mais ampla na pilha de IA: a mudança em direção a “RAG Agente.” À medida que os modelos se tornam mais capazes de planejar e raciocinar, a responsabilidade de encontrar dados passa da camada de banco de dados para a camada de modelo.

Já estamos vendo isso no espaço de codificação, onde agentes como Código Claude e Cursor estão abandonando pesquisas simples de vetores em favor da exploração ativa de base de código. Zhang acredita que a recuperação genérica de documentos seguirá a mesma trajetória.

“Os bancos de dados vetoriais ainda têm casos de uso adequados”, disse Zhang. “Mas seu papel histórico como banco de dados padrão para LLMs e IA se tornará menos claro com o tempo.”

avots

DEIXE UMA RESPOSTA

Por favor digite seu comentário!
Por favor, digite seu nome aqui