이전 게시물에서 앞서 보았듯이, 함수 호출이 제공하는 일관성은 단순한 최적화가 아닌 필수 사항입니다. 평가 루프에서 구조적 오류를 제거하자 표준 시나리오(예: 티어 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라고 생각하시면 됩니다. 이렇게 좋은 약어를 마다할 사람은 없겠죠?

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

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

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

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

1. Swift 업데이트 도착! 개발자들은 새로운 기능을 사용해 보고 싶어 합니다.

2. Swift 업데이트 도착! 새 앨범이 다음 달에 발매될 예정입니다.

이 추가 맥락을 통해 "Swift"라는 이름을 올바른 엔터티로 해석할 수 있습니다.

이전 게시물에서는 감시 목록을 설정하고 엔터티를 추가 맥락으로 보강했습니다. 위의 예시를 보면, 목록에 최소한 다음 두 개의 엔터티, "Taylor Swift"와 "Swift 프로그래밍 언어"가 있어야 합니다. 텍스트에서 엔터티 언급을 추출하는 방법도 다뤘습니다. 이 두 예시 모두 "Swift"를 추출합니다. 보강된 감시 목록과 추출된 엔터티라는 재료가 갖추어졌으니, 이제 주요 주제인 엔터티 매칭을 다룰 준비가 되었습니다.

유의 사항: 이것은 엔터티 매칭 개념을 교육하기 위해 설계된 교육용 프로토타입입니다. 프로덕션 시스템에서는 다양한 대규모 언어 모델(LLM), 사용자 지정 매칭 규칙, 특수 판단 파이프라인 또는 여러 매칭 전략을 결합한 앙상블 접근 방식을 사용할 수 있습니다.

문제: 매칭이 어려운 이유

인간의 언어는 놀라운 것입니다. 가장 흥미로운 속성 중 하나는 끝없는 창의성입니다. 우리는 무한하게 많은 수의 새로운 문장을 생성하고 이해할 수 있습니다. 그렇다면 엔터티 해석에서 정확한 일치가 드문 것이 과연 놀라운 일일까요? 작성자들은 가능한 한 창의적으로 되려고 노력합니다. 엔터티가 언급될 때마다 전체 이름을 쓰고 읽어야 한다면 매우 지루할 것입니다. 정확한 일치는 간편하지만, 실제로는 엔터티 해석을 위해 더 정교한 접근 방식이 필요합니다. 인간 작성자의 무한한 창의성을 최소한 어느 정도는 처리할 수 있을 만큼 강력한 접근 방식이 필요합니다. 그래서 우리는 문제를 두 단계로 분리합니다. Elasticsearch를 사용하여 가능성 있는 후보를 대규모로 검색하고, 그런 다음 LLM을 사용하여 이러한 후보가 실제로 동일한 실제 엔터티를 참조하는지 판단하는 것입니다.

해결책: 투명한 LLM 판단을 사용한 3단계 매칭

우리는 컴퓨터 사용 방식에서 패러다임 전환의 중심에 있습니다. 인터넷의 등장으로 로컬 컴퓨팅에서 글로벌 연결 네트워크로 전환된 것처럼, 생성형 AI는 콘텐츠, 코드 및 정보 생성 방식을 근본적으로 변화시키고 있습니다. 실제로, 이 시리즈에 포함된 교육용 프로토타입에서는 작성자의 세심한 프롬프트에 따라 거의 전적으로 LLM을 통한 "바이브 코딩" 방식을 사용했습니다. LLM이 인간 언어에 내재한 생산성에 도달했거나 도달할 것이라는 의미는 아니지만, 이제 엔터티 해석에 도움이 되는 강력한 리소스를 갖게 되었다는 것은 명백합니다.

생성형 AI에서 흔히 사용하는 패턴은 Retrieval-Augmented Generation(RAG)입니다. 여기서 검색(Retrieval)은 엔터티 후보를 검색하는 것(답변 생성이 아님)을 의미하며, LLM은 매칭 평가와 설명에만 엄격히 사용됩니다. LLM에 엔드 투 엔드 엔터티 해석을 요청할 수도 있지만, 시간과 비용 면에서 비용이 많이 듭니다. RAG는 LLM에 더 효율적으로 맥락을 제공하는 방식을 사용함으로써 LLM이 엔터티 해석을 효율적으로 지원하도록 돕습니다.

RAG의 검색 부분에서는 다시 Elasticsearch를 사용합니다. 먼저 정확한 매칭, 별칭 매칭, 그리고 키워드와 시맨틱 검색을 결합한 하이브리드 검색을 조합하여 잠재적 매칭을 찾습니다. 이 잠재적 매칭을 찾으면 LLM에 보내 판단을 받습니다. LLM은 최종 매칭 평가자 역할을 합니다. 또한 LLM은 그 추론을 설명하게 하는데, 이는 다른 엔터티 해석 시스템과의 중요한 차별점입니다. 이러한 설명이 없으면 엔터티 해석은 블랙박스와도 같습니다. 설명이 있어야 매칭이 타당한 이유를 알 수 있습니다.

핵심 개념: 3단계 매칭, 하이브리드 검색, 투명한 LLM 판단

3단계 매칭이란? 이 프로젝트의 시작 시점에 우리는 시맨틱 검색이 시스템의 중요한 부분이 될 것이라고 가정했지만, 모든 매칭이 그러한 정교한 검색을 요구하지는 않습니다. 일치하는 항목을 효율적으로 찾기 위해서, 문제에 대해 점진적인 접근 방식을 취합니다. 먼저 키워드 검색을 사용하여 정확히 일치하는 항목을 확인합니다. 정확히 일치하는 항목을 찾으면 작업이 완료되고 다음 단계로 넘어갈 수 있습니다. 정확히 일치하는 항목이 없으면, 별칭 매칭으로 전환합니다. 프로토타입에서는 간편함을 위해 별칭 매칭에서도 키워드를 사용한 정확한 일치 방식을 사용합니다. 프로덕션 환경에서는 이 단계를 정규화, 음역 규칙, 퍼지 매칭 또는 큐레이션된 별칭 테이블로 확장할 수 있습니다. 처음 두 단계에서 잠재적인 일치 항목을 찾지 못하면, Elasticsearch의 하이브리드 검색과 상호 순위 결합(RRF)을 통해 시맨틱 검색을 사용할 차례입니다.

하이브리드 검색이란? Elasticsearch에서는 시맨틱 검색을 사용하여 맥락을 고려한 의미 있는 일치 항목을 찾을 수 있습니다. Elasticsearch는 벡터 검색 및 하이브리드 검색에 널리 사용됩니다. 시맨틱 유사성은 의미 파악에 효과적이지만, 구조화된 필터링(예: 시간 범위, 위치 또는 식별자 기준)을 대체할 수 없으며 정확한 일치 항목이 있을 경우에는 불필요한 경우가 많습니다. Elasticsearch는 시맨틱 검색이 맞지 않는 작업에 뛰어난 어휘 검색으로 두각을 나타냈습니다. 두 접근법을 모두 활용하기 위해 단일 하이브리드 쿼리에서 어휘 검색과 시맨틱 검색을 사용합니다. 그런 다음 결과를 병합해서 RRF로 일치 가능성이 가장 높은 항목을 찾습니다. 프로토타입에서는 상위 두 결과가 LLM 판단을 위해 보낼 수 있는 잠재적 일치 항목이 됩니다.

LLM 판단이 필요한 이유? LLM의 판단과 설명을 통해 시스템은 모호성과 맥락을 투명하게 처리할 수 있습니다. 이는 맥락에 따라 여러 개체를 지칭할 수도 있는 "The President" 같은 사례에 매우 중요할 뿐 아니라, 별명이나 문화적 변형 같은 항목도 시스템에서 잘 작동하도록 해줍니다. 마지막으로, 제재 목록에서 엔터티를 식별할 때와 같이 중대한 작업을 고려할 때 시스템을 신뢰하기 위해서는 일치 항목이 수락된 이유를 알아야 합니다. 결정적으로, LLM은 전체 말뭉치를 검색하는 것이 아니라 Elasticsearch가 반환한 작은 후보 집합만 평가합니다.

실제 결과: LLM 추론을 사용한 매칭

자연어 처리 작업에서 가장 큰 과제 중 하나는 기대 결과를 알려주는 문서, 즉 "정답지"를 만드는 것입니다. 이것 없이는 작업에서 시스템의 성능을 판단하기가 거의 불가능하지만, 이러한 문서를 작성하는 과정은 어려울 수 있습니다. 엔터티 해석 프로토타입 개발을 위해, 테스트에 사용할 데이터를 설정하는 데 다시 한번 생성형 AI의 도움을 받았습니다.

먼저 별명과 음역법 같은 여러 과제 유형을 정의한 후, 시스템에 점차 더 커지고 어려워지는 티어형 데이터 세트 모음을 만들도록 LLM에 요청했습니다. 데이터 세트 생성은 기대만큼 간단하지 않았습니다. LLM은 정답을 너무 쉽게 찾도록 만들어서 "속임수"를 쓰는 경향이 강했습니다. 예를 들어, 과제 유형 중 하나는 의미론적 맥락에 초점을 맞췄습니다. 이 유형에는 "러시아 작가(Russian author)"를 "레프 톨스토이(Leo Tolstoy)"로 해석하는 것과 같은 것들이 포함되었습니다. LLM은 "러시아 작가(Russian author)"를 "레프 톨스토이(Leo Tolstoy)"의 별칭으로 잘못 표기했으며, 이로 인해 일치 항목을 찾기 위한 하이브리드 검색의 필요성이 없어졌습니다.

이와 같은 문제를 해결하기 위해 여러 차례 리팩토링을 거친 후, 5개의 데이터 세트 티어를 사용하게 되었습니다. 티어 1~4는 점점 더 커지고 더 많은 유형의 과제를 포함했습니다. 티어 5는 모든 과제 유형 중에서 가장 까다로운 예제들로 구성된 "궁극의 도전 과제" 데이터 세트였습니다. 모든 테스트 데이터는 종합 평가 디렉터리에서 확인할 수 있습니다.

프롬프트 기반 엔터티 해석 접근 방식을 평가하기 위해 티어 4 데이터 세트에 집중했습니다. 중요한 점은 이 평가가 통제된 실험으로 수행되어 엔터티 매칭 품질에 집중할 수 있었다는 것입니다. 감시 목록 데이터는 맥락 정보로 사전 보강되었으며, 엔터티는 문서에서 미리 추출되었습니다. 이를 통해 추출 정확도보다는 매칭에 초점을 맞춰 평가할 수 있었습니다. 이를 통해 매칭 품질에 집중합니다. 엔드 투 엔드 성능은 추가적으로 추출 재현율 및 보강 품질에 따라 달라질 수 있습니다.

평가 데이터 세트

티어 4 평가 데이터 세트는 시스템의 기능을 종합적으로 테스트합니다.[1]

• 감시 목록 엔터티: 다양한 유형의 엔터티 66개(사람, 조직, 위치).

• 테스트 문서: 실제 엔터티 해석 시나리오를 다룬 문서 69개.

• 예상 일치 항목: 모든 문서에서 예상 엔터티 일치 항목 206개.

• 과제 유형: 엔터티 해석의 다양한 측면을 테스트하는 과제 유형 15가지.

데이터 세트에 포함된 과제 유형은 다음과 같습니다.

• 별명: "Bob Smith" → "Robert Smith"(7개 문서).

• 직함 및 경칭: "Dr. Sarah Williams" → "Sarah Williams"(5개 문서).

• 의미론적 맥락: "Russian author" → "Leo Tolstoy"(8개 문서).

• 다국어 이름: 여러 스크립트로 이름 처리(6개 문서).

• 비즈니스 엔터티: 법인명 변형(7개 문서).

• 임원 참조: "Microsoft CEO" → "Satya Nadella"(5개 문서).

• 정치 지도자: 직함 기반 참조(5개 문서).

• 이니셜: "J. Smith" → "John Smith"(3개 문서).

• 이름 순서 변형: 다양한 이름 순서 규칙(3개 문서).

• 잘린 이름: 부분 이름 일치(3개 문서).

• 이름 분할: 텍스트에 걸쳐 이름 분할(3개 문서).

• 누락된 공백/하이픈: 서식 변형(2개 문서).

• 음역: 교차 스크립트 이름 매칭(2개 문서).

• 결합된 과제: 하나의 문서에 여러 과제(6개 문서).

• 복잡한 비즈니스: 계층적 비즈니스 관계(5개 문서).

프롬프트 기반 엔터티 해석이 어떻게 수행되었는지 살펴보겠습니다.

전반적인 성능

결과는 LLM 기반 매치 평가에 많은 가능성이 있음을 보여주지만, 동시에 심각한 신뢰성 문제도 드러났습니다. 각 후보 쌍은 LLM에 의해 평가되어야 하므로, 검색이 잘 작동하더라도 구조화된 출력에 오류가 있으면 허용률과 재현율을 억제할 수 있습니다.

메트릭

값

정밀도

83.8%

재현율

62.6%

F1 점수

71.7%

검색된 총 일치 항목 수

344

LLM 합격률

44.8%

오류율

30.2%

오류율 문제

앞에서 설명한 대로, 프로토타입에서 가장 먼저 한 일은 Elasticsearch를 사용하여 잠재적인 일치 쌍을 생성하는 것입니다. 이러한 잠재적 일치 항목 각각은 LLM에 의해 평가되어야 합니다. 모든 일치 항목을 효율적으로 처리하기 위해 LLM 호출을 배치 처리합니다. 이렇게 하면 API 비용과 지연 시간이 줄어들지만, 출력에 잘못된 형식의 JSON이 포함될 위험도 높아집니다. 배치 크기가 증가함에 따라 JSON은 더 길고 복잡해지므로 LLM이 유효하지 않은 JSON을 생성할 가능성이 높아집니다. 여기에서 30% 오류율이 발생합니다. 평가에서는 요청당 5개의 일치 항목을 배치 크기로 사용했습니다. 이처럼 보수적인 배치 크기를 사용했음에도 불구하고 여전히 JSON 구문 분석 오류가 발생하여 평가 결과가 크게 왜곡됩니다.

다음 단계: LLM 통합 최적화

이제 시맨틱 검색과 LLM 판단을 사용하여 엔터티를 매칭했으므로 완전한 엔터티 해석 파이프라인을 갖추게 되었습니다. 하지만 이 접근 방식은 모델의 판단은 정확하지만 출력 결과가 사용 불가능할 때 새로운 오류 모드를 불러옵니다. 안정성과 비용 효율성을 높이기 위해 LLM 통합을 최적화할 수 있습니다. 다음 게시물에서는 구조화된 출력을 위해 함수 호출을 사용하는 방법을 탐구할 것입니다. 이는 구조와 유형 안전성을 보장하면서 오류와 비용을 줄여줍니다.

직접 사용해 보기

엔터티 매칭을 직접 확인해 보고 싶으신가요? 실제 구현, 자세한 설명 및 실제 예제가 포함된 엔터티 매칭 노트북을 확인해 보세요. 이 노트북은 3단계 검색, RRF를 사용한 하이브리드 검색, 그리고 추론을 포함한 LLM 기반 판단을 통해 엔터티를 매칭하는 방법을 정확하게 보여줍니다.

유의 사항: 이것은 개념을 교육하기 위해 설계된 교육용 프로토타입입니다. 프로덕션 시스템을 구축할 때는 이 학습 중심 프로토타입에서 다루지 않는 모델 선택, 비용 최적화, 지연 시간 요구 사항, 품질 검증, 오류 처리 및 모니터링과 같은 추가 요소를 고려하세요.

참고

1. 이 데이터 세트는 교육용으로 설계된 합성 데이터 세트입니다. 실제 문제를 어느 정도 반영하지만 특정 프로덕션 환경을 대표하는 것은 아닙니다.