Elasticsearch를 통한 엔티티 해석, 4부: 최종 과제

이제 두 가지 방식으로 구현된 지능형 엔티티 해석을 확인했습니다. 두 접근 방식 모두 동일한 방식으로 시작합니다. 즉, 엔티티 준비 및 추출을 거쳐 Elasticsearch로 후보 검색이 진행됩니다. 그 후, 프롬프트 기반 JSON 생성 또는 함수 호출을 통해 대규모 언어 모델(LLM)을 사용하여 후보를 평가하며, 모델이 판단에 대한 투명한 설명을 제공하도록 요구합니다.

이전 게시물에서 앞서 보았듯이, 함수 호출이 제공하는 일관성은 단순한 최적화가 아닌 필수 사항입니다. 평가 루프에서 구조적 오류를 제거하자 표준 시나리오(예: 티어 4 데이터 세트)의 결과가 크게 향상되었습니다.

하지만 아직 답변이 필요한 질문도 분명히 남아 있습니다.

상황이 아주 복잡해질 때도 이 접근 방식이 여전히 효과가 있을까요?

실제 엔티티 해석은 단순한 경우로 인해 실패하는 일이 거의 없습니다. 이름이 언어, 문화, 문자 체계, 시대, 조직 경계를 넘나들 때 실패하게 됩니다. 사람들이 이름 대신 직함으로 언급되거나, 회사가 이름을 바꾸거나, 음역이 일관되지 않거나, 철자가 아니라 컨텍스트만이 실제 세계의 엔티티와 연결되는 유일한 요소일 때 실패하게 됩니다.

그래서 이 시리즈의 마지막 포스팅에서 시스템에 '궁극의 도전'이라는 과정을 진행했습니다.

이것이 궁극적인 도전인 이유는 무엇입니까?

이전 평가에서는 점점 더 복잡한 데이터 세트를 사용하여 시스템을 테스트했습니다. 이전 게시물에서 논의된 티어 4에 도달했을 때는 이미 별명, 직함, 다국어 이름 및 의미 참조의 혼합을 다루고 있었습니다. 해당 테스트 결과, 아키텍처 자체는 견고했음에도 특히 잘못된 JSON 형식과 같은 신뢰성 문제로 인해 재현율이 저해되는 것으로 나타났습니다.

함수 호출이 구현됨에 따라 마침내 안정적인 기반을 마련할 수 있었습니다. 덕분에 더 흥미로운 질문을 할 기회가 생겼습니다.

하나의 통합 파이프라인이 여러 종류의 엔티티 해석 문제를 동시에 처리할 수 있을까요?

궁극의 과제 데이터 세트는 바로 그러한 차원을 시험하기 위해 설계되었습니다.

별명이나 음역과 같은 단일한 문제에 집중하는 대신, 이 데이터 세트는 다음과 같은 50개 이상의 다양한 과제 유형을 결합합니다.

• 문화적 지명 관습
• 직함 기반 참조
• 비즈니스 관계와 역사적 이름 변경 사항.
• 다국어 및 교차 스크립트 언급
• 위의 여러 가지가 혼합된 복합 과제입니다.

무엇보다 중요한 것은 이것이 단 하나의 제한적인 사용 사례에 대한 최적화가 아니라는 것입니다. 엔티티 간에 규칙이 변경될 때 설계 패턴이 유지되는지 테스트하는 것이 중요한 부분입니다.

데이터 세트 개요

궁극의 과제 데이터 세트는 다음과 같이 구성됩니다.

• 사람, 조직, 기관이 포함된 50개 엔티티.
• 다양한 구조와 언어적 복잡성을 지닌 약 60개의 기사.
• 51개의 뚜렷한 과제 카테고리가 다음과 같이 넓게 그룹화됩니다.
  • 문화적 지명 관습
  • 직함 및 전문적 맥락.
  • 비즈니스 및 조직적 관계
  • 다국어 및 음역 문제.
  • 결합 및 극단 시나리오

이 시리즈의 초반부에서 생성형 AI(GenAI)를 사용하여 데이터 세트를 생성하는 것에 장단점이 있다는 것을 확인했습니다. 생성형 AI가 없으면 충분히 크고 다양한 테스트 데이터를 구성하는 것이 매우 어려워집니다. 그러나 제어하지 않으면 모델이 작업을 지나치게 쉽게 만드는 경향이 있습니다.

초기 세대 합격 예시를 보면 모델이 블라디미르 푸틴의 명시적 별칭으로 '러시아 대통령'과 같은 구문을 포함시켰다는 사실이 발견되었습니다. 현재로서는 합리적으로 보일 수 있지만, 이는 상황별 해결 테스트의 목적을 무효화합니다. 기사가 1990년대 러시아에 대해 논의하고 있다면 어떻게 될까요? 시스템은 하드코딩된 별칭에 의존하지 않고 컨텍스트에서 올바른 엔티티를 추론해야 합니다.

그러한 이유로, 이 데이터 세트는 지름길이 통하지 않도록 의도적으로 설계되었습니다. 별칭은 시스템이 의미를 유추해야 할 때 명시적으로 나열되지 않습니다. 설명적 구문이 엔티티에 사전 연결되어 있지 않습니다. 정확한 일치는 단순한 로컬 텍스트가 아닌 문서 수준의 컨텍스트에 의존하기도 합니다.

중요 사항: 다양한 시나리오에서 시스템의 기능을 시연하는 것이지만 이는 교육용 프로토타입임을 알려드립니다. 실제 제재 대상 엔티티 모니터링을 처리하는 프로덕션 시스템에는 추가적인 검증, 규정 준수 점검, 감사 추적 및 민감한 사용 사례에 대한 전문적인 처리가 필요합니다.

이러한 시나리오가 어려운 이유

이 시리즈의 첫 번째 게시물에서 “새로운 Swift 업데이트가 도착했습니다!”라는 간단하지만 모호한 예를 소개했습니다. 문제는 'Swift'가 상황에 따라 실제 세계의 여러 엔티티로 해석될 수 있다는 것입니다. 이 예시는 더 큰 진실을 드러냅니다. 자연어가 본질적으로 모호하다는 것이죠.

따라서 엔티티 해석은 단순히 스트링 일치 문제가 아닙니다. 인간은 일상적으로 공유된 지식, 문화적 규범, 상황적 맥락에 의존하여 참조를 해결하며, 그렇게 하고 있다는 사실을 거의 인지하지 못합니다.

고려해야 할 일반적인 케이스:

• 지정학 및 시대적 컨텍스트가 없다면 '대통령'과 같은 직함은 의미가 없습니다.
• 회사 이름은 기사 작성 시기에 따라 모회사, 자회사 또는 이전 브랜드를 가리킬 수 있습니다.
• 사람의 이름은 언어와 문화에 따라 다른 순서, 문자 체계 또는 음역으로 표현될 수 있습니다.
• 동일한 문구가 다른 컨텍스트에서 다른 엔티티를 정당하게 참조할 수 있으며, 시스템은 일치 항목을 수락하는 것만큼 자신 있게 거부할 수 있어야 합니다.

이러한 모든 상황을 깔끔하게 처리할 수 있는 단일 규칙 세트는 없습니다. 그래서 이 프로토타입은 우려 사항을 매우 철저하게 분리합니다.

• Elasticsearch는 후보 공간을 효율적이고 투명하게 좁힙니다.
• LLM은 판단이 필요하고 스스로 설명해야 하는 경우에만 사용됩니다.
• 검색과 추론은 여전히 뚜렷하게 구분됩니다.

과제 유형이 다양해질수록 이러한 분리가 더욱 중요해집니다.

시스템이 특별 사례 없이 다양성을 처리하는 방식

이 평가에서 가장 흥미로운 결과 중 하나는 변하지 않은 부분입니다.

• 일본어 이름에 대한 특별한 로직을 추가하지 않았습니다.
• 아랍어 부칭에 대한 사용자 지정 규칙을 추가하지 않았습니다.
• 과거 회사 이름에 하드코딩된 매핑을 추가하지 않았습니다 .

대신 이 시스템은 이 시리즈에서 앞서 소개된 것과 동일한 핵심 요소에 의존했습니다.

• 시맨틱 검색을 위해 인덱싱된 컨텍스트가 풍부한 엔티티
• Elasticsearch 내 하이브리드 검색(정확성, 별칭, 의미론적 검색)
• 잘 정의된 소규모 후보 일치 집합
• 함수 호출 및 최소 스키마에 의해 제한되는 LLM 판단

이는 시스템의 유연성이 점점 늘어나는 규칙 집합이 아니라 표현과 구조에서 온다는 것을 시사합니다.

시스템이 성공하는 경우는 올바른 후보가 검색되고, LLM이 참조가 특정 엔티티에 매핑되거나 매핑되지 않는 이유를 설명할 충분한 맥락을 제공하기 때문입니다.

결과: 성능은 어떠했습니까?

궁극의 과제 데이터 세트에서 시스템은 다음과 같은 종합적인 결과를 도출했습니다.

• 정밀도: ~91%
• 재현율: ~86%
• F1 점수: ~89%
• LLM 합격률: ~72%

도전 과제 유형 전반에 걸친 성과

과제 유형별로 결과를 분석하면 강점과 한계가 드러납니다.

가장 강한 성능(100% F1 점수)은 다음과 같은 영역에서 관찰되었습니다.

• 스크립트 간 매칭(키릴 문자, 한국어, 중국어 사업체)
• 히브리어 시나리오(부칭, 전문 직함, 종교 직함, 음역)
• 비즈니스 계층(항공우주, 다각적인 제조, 다사업부 기업)
• 전문직 칭호(학문적, 군사적, 정치적, 종교적).
• 여러 문자 체계를 포함하는 결합된 일본어 시나리오입니다.

강력한 성능(80–99% F1 점수) 포함 사항:

• 국제 정치인(98%)
• 과거 이름 변경 내역(90%)
• 복잡한 비즈니스 계층(89%)
• 일본 회사 이름(93%)
• 교차 문자 체계 음역(86%)
• 아랍어 애칭(86%)

더 까다로운 영역 포함:

• 고급 음역(중국어, 한국어): 0% F1.
• 특정 일본어 시나리오(경어법, 이름 순서, 쓰기 체계 변형): ~67% F1.
• 일부 아랍어 시나리오(회사명, 기관 참조): ~40% F1.

여기서 중요한 것은 이 사례에서 시스템이 어려움을 겪은 이유입니다. 이러한 실패는 전반적인 접근 방식이 고장났기 때문이 아니라 특정 구성 요소, 특히 특정 다국어 시나리오에서 시맨틱 검색에 사용되는 고밀도 벡터 모델의 한계로 인한 것이었습니다.

검색과 판단이 명확하게 분리되어 있기 때문에, 성능 향상을 위해 시스템을 다시 작성할 필요가 없습니다. 보다 뛰어난 다국어 임베딩 모델로 교체하거나, 엔티티 컨텍스트를 강화하거나, 검색 전략을 개선하면 핵심 아키텍처를 변경하지 않고도 이러한 카테고리 전반에 걸쳐 결과를 향상시킬 수 있습니다.

아키텍처 관점에서는 그것이 진정한 성공 지표입니다.

디자인에 대해 알 수 있는 내용

시리즈를 되돌아보면, 몇 가지 패턴이 눈에 띕니다.

• 영리한 매칭보다 준비가 더 중요합니다. 사전에 컨텍스트로 엔티티를 보강하면 이후 모호성을 크게 줄일 수 있습니다.
• LLM은 검색자가 아니라 심사 위원으로서의 가치가 가장 뛰어납니다.검색하라고 요청하는 것보다 일치하는 이유를 설명해달라고 요청하는 것이 훨씬 효과적입니다.
• 신뢰성이 정확성을 뒷받침합니다. 함수 호출은 JSON을 정리하는 것뿐만 아니라, 검색 단계에서 이미 잠재되어 있던 기억력을 끌어내는 역할을 했습니다.
• 일반화가 전문화보다 우수합니다.잘 선택한 소규모 추상화를 통해 사용자 정의 로직 없이 수십 가지 과제 유형을 처리할 수 있었습니다.

이것이 바로 프로토타입이 의도적으로 Elasticsearch 네이티브 방식으로 설계되었고, LLM 사용 방식에 있어서도 의도적으로 보수적인 접근 방식을 취한 이유입니다. 목표는 검색을 대체하는 것이 아니라, 의미가 중요한 상황에서 검색을 설명 가능하게 만드는 것입니다.

결론

궁극의 과제는 완벽한 지표를 추구하기 위한 것이 아니라, 더 근본적인 질문에 답하기 위한 것입니다.

투명한 검색 우선의 LLM 기반 아키텍처가 규칙이나 블랙박스로 전락하지 않고 실제 세계의 엔티티 모호성을 처리할 수 있을까요?

이 교육용 프로토타입의 경우 프로덕션 강화, 규정 준수, 모니터링 및 데이터 품질과 관련된 명확한 주의사항이 있지만 그 답은 '예'입니다. 엔티티 일치가 이루어진 이유를 정당화해야 하는 시스템을 구축하는 경우, 이 패턴을 진지하게 고려할 가치가 있습니다. 이 시리즈를 통해 엔티티 해결이 불가사의하지 할 이유가 없다는 것을 알게 되셨기를 바랍니다. 문제를 제대로 분리하면 엔티티 해결을 이해하고, 측정하고, 개선할 수 있습니다.

이 작업은 또한 더 광범위한 아키텍처 패턴을 제안합니다. 이를 통해 고전적인 Retrieval-Augmented Generation(RAG) 방식의 미미하지만 중요한 진화가 드러납니다. 검색이 생성에 직접 정보를 제공하게 하는 대신, 명시적인 평가 단계를 도입했습니다. LLM이 먼저 사용되어 검색된 후보를 심사하고 무결성을 확인하며 승인된 결과만 생성을 보강하는 것이 허용됩니다. 이를 Generation-Augmented Retrieval-Augmented Generation with Evaluation, 즉 GARAGE라고 생각하시면 됩니다. 이렇게 좋은 약어를 마다할 사람은 없겠죠?

이 패턴이 다른 어떤 사용 사례에 도움이 될 수 있을까요? 신뢰, 투명성 및 변호 가능한 추론이 필요한 시스템이 당연히 후보가 될 것입니다. 이 분야의 향후 작업은 여기서 본 결과만큼이나 매력적일 것입니다. 커뮤니티가 다음에 어떤 방향으로 나아갈지 정말 기대됩니다.

다음 단계: 직접 사용해 보기

궁극의 과제가 실제로 작동하는 모습을 확인하고 싶으세요? 실제 구현, 자세한 설명 및 실습 예제가 포함된 궁극의 과제 노트북을 확인해 보세요.

완전한 엔티티 해석 파이프라인은 프로덕션 환경에 필요한 핵심 개념과 아키텍처를 보여줍니다. 이를 기반으로 모든 과정에서 투명성과 설명 가능성을 유지하는 동시에 뉴스 기사를 모니터링하고, 엔티티 언급을 추적하며, 어떤 엔티티가 어떤 기사에 등장하는지에 대한 질문에 답하는 시스템을 구축할 수 있습니다.