Resolução de entidades com Elasticsearch, parte 4: O desafio definitivo

Agora vimos a resolução inteligente de entidades implementada de duas maneiras. Ambas as abordagens começam da mesma forma: preparação e extração de entidades, seguidas pela recuperação de candidatos com Elasticsearch. A partir daí, avaliamos esses candidatos usando um grande modelo de linguagem (LLM), seja por meio de geração de JSON baseada em prompt ou chamada de funções, e exigimos que o modelo forneça uma explicação transparente para seu julgamento.

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.