Como vimos na postagem anterior, a consistência proporcionada pela chamada de função não é apenas uma mera otimização; é essencial. Uma vez removidos os erros estruturais do ciclo de avaliação, os resultados em cenários padrão (como os do conjunto de dados de nível 4) melhoraram significativamente.

No entanto, há uma pergunta óbvia a ser respondida:

Essa abordagem ainda funciona quando as coisas realmente ficam confusas?

A resolução de entidades no mundo real raramente falha por causa de casos simples. Ela falha quando nomes cruzam línguas, culturas, sistemas de escrita, períodos de tempo e fronteiras organizacionais. Ela falha quando as pessoas são referenciadas por títulos em vez de nomes, quando as empresas mudam de nome, quando as transliterações não são consistentes e quando o contexto (não a ortografia) é a única coisa que vincula uma menção a uma entidade do mundo real.

Então, para o post final desta série, colocamos o sistema no que chamamos de desafio definitivo.

O que faz disso o desafio definitivo?

Em avaliações anteriores, testamos o sistema usando conjuntos de dados cada vez mais complexos. Quando chegamos ao nível 4, discutido no post anterior, já estávamos lidando com uma mistura de apelidos, títulos, nomes multilíngues e referências semânticas. Esses testes mostraram que a arquitetura em si era sólida, mas que problemas de confiabilidade, especialmente JSON malformado, estavam prejudicando o recall.

Com a chamada de função implementada, finalmente tivemos uma base estável. Isso nos deu a oportunidade de fazer uma pergunta mais interessante:

Um único pipeline unificado consegue lidar com vários tipos diferentes de problemas de resolução de entidades simultaneamente?

O conjunto de dados de desafio definitivo foi projetado para explorar precisamente essa dimensão.

Em vez de se concentrar em uma única dificuldade (como apelidos ou transliteração), este conjunto de dados combina mais de 50 tipos de desafios distintos, incluindo:

• Convenções culturais de nomeação.

• Referências baseadas em títulos.

• Relações comerciais e mudanças históricas de nome.

• Menções multilíngues e em diferentes sistemas de escrita.

• Desafios complexos que misturam vários dos itens acima.

O mais importante é que isso não se trata de otimizar para um caso de uso específico. Trata-se de testar se o padrão de design se sustenta quando as regras mudam de entidade para entidade.

Visão geral do conjunto de dados

O conjunto de dados de desafio definitivo consiste em:

• 50 entidades, abrangendo pessoas, organizações e instituições.

• Cerca de 60 artigos, com estrutura e complexidade linguística variadas.

• 51 categorias distintas de desafios, agrupadas de forma ampla em:

  • Convenções culturais de nomeação.

  • Títulos e o contexto profissional.

  • Relacionamentos empresariais e organizacionais.

  • Desafios multilíngues e de transliteração.

  • Cenários combinados e casos limite.

No início da série, vimos que usar IA generativa (GenAI) para criar conjuntos de dados pode ser uma faca de dois gumes. Sem ele, reunir dados de teste suficientemente grandes e diversos seria extremamente difícil. Mas, se não for controlado, o modelo tende a simplificar demais as coisas.

Em uma etapa inicial de geração, por exemplo, descobrimos que o modelo incluía frases como "o presidente russo" como apelidos explícitos para Vladimir Putin. Isso pode parecer razoável hoje, mas anula o propósito de testar a resolução contextual. O que acontece se o artigo estiver discutindo a Rússia nos anos 1990? O sistema deve inferir a entidade correta a partir do contexto, não depender de um alias fixo.

Por esse motivo, este conjunto de dados foi deliberadamente projetado para que os atalhos não funcionem. Os pseudônimos não são explicitamente listados quando se espera que o sistema deduza o significado. Frases descritivas não são vinculadas previamente a entidades. As correspondências corretas frequentemente dependem do contexto em nível de artigo, não apenas do texto local.

Observação importante: embora demonstremos os recursos do sistema em diversos cenários, este ainda é um protótipo educacional. Os sistemas de produção que lidam com o monitoramento real de entidades sob sanção exigiriam validação adicional, verificações de conformidade, trilhas de auditoria e tratamento especializado para casos de uso sensíveis.

Por que esses cenários são difíceis?

No primeiro post desta série, apresentamos um exemplo simples, mas ambíguo: "A nova atualização do Swift chegou!" O desafio é que "Swift" pode corresponder a múltiplas entidades do mundo real, dependendo do contexto. Esse exemplo captura uma verdade mais ampla: a linguagem natural é inerentemente ambígua.

A resolução de entidades, portanto, não é apenas um problema de correspondência de strings. As pessoas normalmente se baseiam normalmente em conhecimento compartilhado, normas culturais e contexto situacional para resolver referências, e raramente percebemos que estamos fazendo isso.

Considere alguns casos comuns:

• Um título como “o presidente” não tem significado sem contexto geopolítico e temporal.

• O nome de uma empresa pode se referir a uma controladora, uma subsidiária ou uma marca anterior, dependendo de quando o artigo foi escrito.

• O nome de uma pessoa pode aparecer em diferentes ordens, sistemas de escrita ou transliterações, dependendo da língua e da cultura.

• A mesma frase pode se referir legitimamente a diferentes entidades em diferentes contextos, e o sistema deve ser capaz de rejeitar correspondências com a mesma confiança com que as aceita.

Não existe um conjunto único de regras que lide com tudo isso de forma clara. É por isso que este protótipo separa as responsabilidades de forma tão clara:

• O Elasticsearch reduz o conjunto de candidatos de forma eficiente e transparente.

• O LLM é usado apenas quando o julgamento é necessário e é obrigado a se explicar.

• Recuperação e raciocínio continuam sendo etapas distintas.

Essa separação se torna ainda mais importante à medida que a diversidade de tipos de desafios aumenta.

Como o sistema lida com a diversidade sem exceções específicas

Um dos resultados mais interessantes desta avaliação é o que não mudou:

• Não adicionamos lógica especial para nomes japoneses.

• Não adicionamos regras personalizadas para patronímicos árabes.

• Não adicionamos mapeamentos fixos para nomes históricos de empresas.

Em vez disso, o sistema se baseou nos mesmos elementos centrais apresentados anteriormente na série:

• Entidades enriquecidas por contexto indexadas para busca semântica.

• Recuperação híbrida (exata, alias e semântica) no Elasticsearch.

• Um pequeno e bem definido conjunto de correspondências candidatas.

• Julgamento de LLM restrito por chamada de função e esquemas mínimos.

Isso sugere que a flexibilidade do sistema vem da representação e da arquitetura, não de uma coleção de regras em constante crescimento.

Quando o sistema tem sucesso, é porque os candidatos certos são recuperados e o LLM tem contexto suficiente para explicar por que uma referência corresponde (ou não) a uma entidade específica.

Resultados: Como foi o desempenho?

No conjunto de dados de desafio definitivo, o sistema produziu os seguintes resultados gerais:

• Precisão: ~91%

• Recall: ~86%

• Pontuação F1: ~89%

• Taxa de aceitação em LLM: ~72%

Desempenho em diferentes tipos de desafio

A análise dos resultados por tipo de desafio revela pontos fortes e limitações:

O desempenho mais forte (100% na pontuação F1) foi observado em áreas como:

• Correspondência de entidades entre sistemas de escrita (cirílico, coreano e chinês).

• Cenários hebraicos (patronímicos, títulos profissionais, títulos religiosos, transliteração).

• Hierarquias de negócios (aeroespacial, manufatura diversificada, corporações multidivisionais).

• Títulos profissionais (acadêmicos, militares, políticos, religiosos).

• Cenários combinados em japonês envolvendo múltiplos sistemas de escrita.

Forte desempenho (pontuação F1 de 80–99%) incluiu:

• Figuras políticas internacionais (98%).

• Alterações históricas de nome (90%).

• Hierarquias empresariais complexas (89%).

• Nomes de empresas japonesas (93%).

• Transliteração entre escrituras (86%).

• Patrônimos árabes (86%).

Áreas mais desafiadoras incluíram:

• Transliteração avançada (chinês, coreano): 0% de pontuação F1.

• Certos cenários japoneses (honoríficos, ordem dos nomes, variação do sistema de escrita): ~67% F1.

• Alguns cenários árabes (nomes de empresas, referências institucionais): ~40% F1.

O que é importante aqui é por que o sistema teve dificuldades nesses casos. As falhas não foram causadas por problemas na abordagem geral, mas por limitações em componentes específicos, especialmente o modelo vetorial denso usado para busca semântica em determinados cenários multilíngues.

Como recuperação e julgamento estão claramente separados, melhorar o desempenho não exige reescrever o sistema. A substituição por um modelo de embeddings multilíngue mais capaz, o enriquecimento do contexto da entidade ou o refinamento das estratégias de recuperação melhoraria os resultados nessas categorias sem alterar a arquitetura central.

Do ponto de vista arquitetônico, essa é a verdadeira métrica de sucesso.

O que isso nos diz sobre o design

Olhando para trás na série, alguns padrões se destacam:

• A preparação é mais importante do que a combinação inteligente. Enriquecer entidades com contexto desde o início reduz drasticamente a ambiguidade depois.

• Os LLMs são mais valiosos como juízes, não como recuperadores. Pedir que expliquem por que uma combinação faz sentido é muito mais poderoso do que pedir que busquem.

• A confiabilidade possibilita precisão. A chamada de funções não apenas limpou o JSON; ela revelou o recall que já estava latente na etapa de recuperação.

• A generalização supera a especialização. Um pequeno número de abstrações bem definidas lidou com dezenas de tipos de desafios sem lógica personalizada.

Por isso, o protótipo é intencionalmente nativo do Elasticsearch e conservador na forma como utiliza LLMs. O objetivo não é substituir a busca; é tornar a busca explicável em situações onde o significado importa.

Conclusão

O desafio final não era buscar métricas perfeitas; era sobre responder a uma pergunta mais fundamental:

Uma arquitetura transparente, orientada para busca e assistida por LLM, pode lidar com a ambiguidade de entidades no mundo real sem se limitar a regras ou caixas-pretas?

Para este protótipo educacional, a resposta é sim, com claras ressalvas sobre robustez para produção, conformidade, monitoramento e qualidade dos dados. Se você estiver criando sistemas que precisem justificar por que foi feita uma correspondência de entidade, vale a pena considerar seriamente esse padrão. Espero que esta série tenha mostrado que a resolução de entidades não precisa ser algo misterioso. Com a separação certa das preocupações, torna-se algo sobre o qual você pode refletir, medir e melhorar.

Este trabalho também sugere um padrão arquitetônico mais amplo. O que surge é uma leve, mas importante, evolução da Retrieval-Augmented Generation (RAG). Em vez de permitir que a recuperação alimente diretamente a geração, introduzimos uma etapa explícita de avaliação. O LLM é usado primeiro para avaliar e verificar a consistência dos candidatos recuperados, e apenas os resultados aprovados podem ampliar a geração. Você pode pensar nisso como Retrieval-Augmented Generation com Avaliação, ou GARAGE, porque quem não gosta de uma boa sigla.

Quais outros casos de uso poderiam se beneficiar desse padrão? Sistemas que exigem confiança, transparência e raciocínio defensável são candidatos naturais. Trabalhos futuros nessa área devem ser tão interessantes quanto os resultados que vimos aqui, e estou entusiasmado para ver para onde a comunidade vai levar isso a seguir.

Próximos passos: Experimente por conta própria

Quer ver o desafio definitivo em ação? Confira o Notebook do desafio definitivo para ver um passo a passo completo, com implementações reais, explicações detalhadas e exemplos práticos.

O pipeline completo de resolução de entidades demonstra os conceitos centrais e a arquitetura necessários para uso em produção. Você pode usá-lo como base para construir sistemas que monitorem artigos de notícias, rastreiem menções de entidades e respondam a perguntas sobre quais entidades aparecem em quais artigos, tudo isso mantendo transparência e explicabilidade.

1. A nova atualização do Swift chegou! Os desenvolvedores estão ansiosos para experimentar os novos recursos.

2. A nova atualização do Swift chegou! O novo álbum será lançado no próximo mês.

Com esse contexto adicional, devemos conseguir resolver o nome "Swift" para a entidade correta.

Na postagem anterior, configuramos nossa lista de observação e enriquecemos as entidades com contexto adicional. Olhando nossos exemplos acima, precisamos ter pelo menos as seguintes duas entidades na lista: Taylor Swift e Swift Programming Language. Também abordamos como extraímos menções a entidades do texto. Ambos os exemplos extrairiam "Swift". Com esses ingredientes prontos, a lista de observação enriquecida e as entidades extraídas, finalmente estamos prontos para apresentar a estrela do show: a correspondência de entidades.

Lembre-se: este é um protótipo educacional projetado para ensinar conceitos de correspondência de entidades. Os sistemas de produção podem usar diferentes modelos de linguagem grande (LLMs), regras de correspondência personalizadas, pipelines de julgamento especializados ou abordagens de conjunto que combinam várias estratégias de correspondência.

O problema: por que a correspondência é difícil

A linguagem humana é algo extraordinário. Uma das propriedades mais interessantes é sua criatividade infinita. Podemos gerar e entender um número infinito de novas frases. Será que é de se estranhar, então, que correspondências exatas na resolução das entidades sejam raras? Autores se esforçam para ser criativos quando podem. Ficaria bastante cansativo se tivéssemos que escrever e ler nomes completos sempre que uma entidade fosse mencionada. Portanto, embora as correspondências exatas sejam fáceis, a realidade é que precisamos de uma abordagem mais sofisticada para a resolução de entidades: uma que seja robusta o suficiente para lidar com pelo menos parte da criatividade ilimitada de autores humanos. Por isso, dividimos o problema em duas etapas: usar o Elasticsearch para recuperar candidatos plausíveis em larga escala, e depois usar um LLM para julgar se esses candidatos realmente se referem à mesma entidade do mundo real.

A solução: correspondência em três etapas com julgamento transparente do LLM

Estamos no meio de uma mudança de paradigma na forma como usamos computadores. Assim como a ascensão da Internet nos levou da computação localizada para uma rede conectada globalmente, a IA generativa (GenAI) está mudando fundamentalmente a forma como o conteúdo, o código e as informações são criados. Na verdade, o protótipo educacional que acompanha essa série foi quase exclusivamente "codificado por vibração" usando um LLM, com orientação cuidadosa do autor. Isso não quer dizer que os LLMs tenham ou que alcançarão o tipo de produtividade inerente à linguagem humana, mas significa que agora temos um recurso poderoso para ajudar na resolução de entidades.

Um padrão comum que usamos com GenAI é a retrieval augmented generation (RAG). Aqui, retrieval significa recuperar entidades candidatas (não gerar respostas), e o LLM é usado estritamente para avaliação e explicação da correspondência. Embora pudéssemos pedir a um LLM para nos ajudar com a resolução de entidades de ponta a ponta, essa abordagem é dispendiosa, tanto em termos de tempo quanto de dinheiro. A RAG ajuda os LLMs a realizar seu trabalho usando maneiras mais eficientes de fornecer contexto ao LLM, capacitando-o a auxiliar de forma eficiente na resolução de entidades.

Para a parte de recuperação do RAG, voltamos novamente ao Elasticsearch. Primeiro, encontramos possíveis correspondências usando uma combinação de correspondência exata, correspondência com aliases e busca híbrida, que combina busca semântica e por palavra-chave. Assim que encontramos essas possíveis correspondências, as enviamos para um LLM para julgamento. O LLM atua como avaliador final de correspondência. Também fazemos o LLM explicar seu raciocínio, um diferenciador importante em relação a outros sistemas de resolução de entidades. Sem essas explicações, a resolução de entidades é uma caixa preta; com elas, podemos ver por nós mesmos por que uma correspondência faz sentido.

Conceitos-chave: correspondência em três etapas, busca híbrida e julgamento transparente de LLM

O que é a correspondência em três etapas? No início deste projeto, hipotetizamos que a busca semântica será uma parte crucial do sistema, mas nem toda correspondência exige uma busca tão sofisticada. Para encontrar correspondências de forma eficiente, adotamos uma abordagem progressiva ao problema. Primeiro, verificamos correspondências exatas usando busca por palavras-chave. Se encontrarmos essa correspondência, nosso trabalho estará feito e poderemos seguir em frente. Se a correspondência exata falhar, recorremos à correspondência de alias. No protótipo, a correspondência de alias também é feita usando correspondência exata com palavras-chave, para simplificar. Na produção, você pode expandir essa etapa com normalização, regras de transliteração, correspondência fuzzy ou tabelas de alias curadas. Se ainda não encontramos uma possível correspondência nas duas primeiras etapas, é hora de introduzir a busca semântica por meio da busca híbrida do Elasticsearch com fusão recíproca de classificação (RRF).

O que é busca híbrida? No Elasticsearch, podemos usar a busca semântica para encontrar correspondências significativas que levem em conta o contexto. O Elasticsearch é amplamente utilizado para busca vetorial e recuperação híbrida. A semelhança semântica é poderosa para o significado, mas não substitui a filtragem estruturada (por exemplo, por intervalos de tempo, locais ou identificadores) e geralmente é desnecessária quando uma correspondência exata está disponível. O Elasticsearch se destacou com a busca lexical, que é ótima em tarefas onde a busca semântica não se encaixa. Para aproveitar ao máximo ambas as abordagens, usamos a busca lexical junto com a busca semântica em uma única consulta híbrida. Depois, juntamos os resultados para encontrar as correspondências mais prováveis usando o RRF. No protótipo, os dois melhores resultados tornam-se correspondências potenciais que podem ser enviadas para avaliação do LLM.

Por que julgamento de LLM? Julgamentos e explicações de LLM permitem que nosso sistema trate ambiguidade e contexto de forma transparente. Isso é vital para casos como "o presidente", que pode se referir a múltiplas entidades, dependendo do contexto, mas também faz com que apelidos e variações culturais funcionem bem no sistema. Finalmente, quando consideramos tarefas de missão crítica, como identificar entidades a partir de listas de sanções, precisamos saber por que uma combinação foi aceita para confiar no sistema. Crucialmente, o LLM não busca o corpus completo; ele avalia apenas o pequeno conjunto de candidatos retornados pelo Elasticsearch.

Resultados do mundo real: correspondência com raciocínio de LLM

Um dos principais desafios de qualquer tarefa de processamento de linguagem natural é a criação de um documento de referência, um "gabarito" que nos diga quais são os resultados esperados. Sem isso, é praticamente impossível avaliar o desempenho de um sistema em uma tarefa, mas criar um documento desse tipo pode ser um processo trabalhoso. Para o protótipo de resolução de entidades, recorremos novamente à GenAI para nos ajudar a configurar os dados que pudéssemos usar para os testes.

Primeiro, definimos vários tipos de desafios, como apelidos e transliteração, e então pedimos ao LLM para criar uma coleção em camadas de conjuntos de dados que se tornariam progressivamente maiores e mais desafiadores para o sistema. A criação dos conjuntos de dados foi menos simples do que se esperava. O LLM tinha uma forte propensão para "trapacear" ao tornar muito fácil obter a resposta certa. Por exemplo, um dos tipos de desafio focou no contexto semântico. Este tipo incluiu coisas como resolver "autor russo" para "Liev Tolstói". O LLM incorretamente colocou "autor russo" como um alias para "Leo Tolstoy", o que negou a necessidade de uma busca híbrida para encontrar a correspondência.

Após várias refatorações para corrigir problemas como esse, tínhamos cinco níveis de conjunto de dados para trabalhar. Os níveis 1 a 4 eram progressivamente maiores, com mais tipos de desafio. O Tier 5 era o conjunto de dados do "desafio supremo", composto pelos exemplos mais difíceis de todos os tipos de desafio. Todos os dados dos testes estão disponíveis no diretório de avaliação completo.

Para avaliar nossa abordagem de resolução de entidades baseada em prompts, focamos nossa atenção no conjunto de dados de nível 4. Um ponto importante é que a avaliação foi realizada como um experimento controlado para que pudéssemos focar na qualidade da correspondência de entidades. Os dados da lista de observação foram pré-enriquecidos com contexto, e as entidades foram extraídas do artigo antecipadamente. Isso garantiu que a avaliação fosse focada em correspondência, e não na precisão da extração. Isso isola a qualidade da correspondência; o desempenho de ponta a ponta também dependeria da qualidade do recall e do enriquecimento da extração.

Conjunto de dados de avaliação

O conjunto de dados de avaliação de nível 4 fornece um teste abrangente das capacidades do sistema:[1]

• Entidades da lista de observação: 66 entidades de diversos tipos (pessoas, organizações, locais).

• Artigos de teste: 69 artigos que abrangem cenários reais de resolução de entidades.

• Correspondências esperadas: 206 correspondências de entidades esperadas em todos os artigos.

• Tipos de desafio: 15 tipos diferentes de desafio que testam vários aspectos da resolução de entidades.

Os tipos de desafios incluídos no conjunto de dados são:

• Apelidos: "Bob Smith" → "Robert Smith" (sete artigos).

• Títulos e honoríficos: "Dr. Sarah Williams" → "Sarah Williams" (cinco artigos).

• Contexto semântico: "autor russo" → "Liev Tolstói" (oito artigos).

• Nomes multilíngues: manuseio de nomes em diferentes scripts (seis artigos).

• Entidades empresariais: variações de nome corporativo (sete artigos).

• Referências executivas: "CEO da Microsoft" → "Satya Nadella" (cinco artigos).

• Líderes políticos: referências baseadas em títulos (cinco artigos).

• Iniciais: "J. Smith" → "John Smith" (três artigos).

• Variações na ordem dos nomes: diferentes convenções de ordenação de nomes (três artigos).

• Nomes truncados: correspondências parciais de nomes (três artigos).

• Divisão de nomes: nomes divididos no texto (três artigos).

• Falta de espaços/hífens: variações de formatação (dois artigos).

• Transliteração: correspondência de nomes entre escrituras (dois artigos).

• Desafios combinados: Vários desafios em um único artigo (seis artigos).

• Negócios complexos: relações comerciais hierárquicas (cinco artigos).

Vamos ver como a resolução de entidades baseada em prompts foi realizada.

Desempenho geral

Os resultados mostram que a avaliação de correspondência baseada no LLM é muito promissora, mas também revelam um problema significativo de confiabilidade. Como cada par de candidatos deve ser avaliado pelo LLM, falhas na saída estruturada podem suprimir a aceitação e a recuperação, mesmo quando a recuperação está funcionando bem.

Métrica

Valor

Precisão

83,8%

Recall

62,6%

Pontuação F1

71,7%

Total de correspondências encontradas

344

Taxa de aceitação do LLM

44,8%

Taxa de erro

30,2%

O problema da taxa de erro

Lembre-se de que o primeiro passo que damos no protótipo é criar potenciais pares de correspondência usando o Elasticsearch. Cada uma dessas possíveis correspondências precisa ser avaliada pelo LLM. Para processar eficientemente todas essas correspondências, agrupamos as chamadas de LLM em lote. Isso reduz os custos da API e a latência, mas também há um risco aumentado de obter JSON malformado na saída. À medida que o tamanho do lote aumenta, o JSON se torna mais longo e complexo, tornando mais provável que o LLM gere JSON inválido. É daí que decorre a taxa de erro de 30%. Na avaliação, usamos um tamanho de lote de cinco correspondências por solicitação. Mesmo com este tamanho de lote conservador, ainda vemos falhas na análise JSON, o que distorce significativamente os resultados da avaliação.

O que vem a seguir: otimização da integração com LLMs

Agora que combinamos entidades usando busca semântica e julgamento de LLM, temos um pipeline completo de resolução de entidades. Essa abordagem introduz um novo modo de falha, no entanto, quando o julgamento do modelo está correto, mas sua saída não é utilizável. Podemos otimizar a integração do LLM para maior confiabilidade e eficiência de custos. No próximo post, exploraremos como usar o chamado de função para saída estruturada, que garante estrutura e segurança de tipos, ao mesmo tempo em que reduz erros e custos.

Experimente você mesmo

Quer ver a correspondência de entidades em ação? Confira o notebook do Entity Matching para ver um passo a passo completo com implementações reais, explicações detalhadas e exemplos práticos. O caderno mostra exatamente como combinar entidades usando busca em três etapas, busca híbrida com RRF e julgamento baseado em LLM com raciocínio.

Lembre-se: este é um protótipo educacional projetado para ensinar os conceitos. Ao construir sistemas de produção, considere fatores adicionais, como seleção de modelos, otimização de custos, requisitos de latência, validação de qualidade, tratamento de erros e monitoramento, que não são abordados neste protótipo focado em aprendizado.

Notas

1. Esses conjuntos de dados são sintéticos e projetados para educação; eles se aproximam de desafios reais, mas não representam nenhum domínio de produção específico.