#AI는 어떻게 애플(회사)과 사과(과일)를 구분하는가 — 엔티티 추출·링킹·중의성 해소

← 전체 목차 · 이전: 그래프 DB ≠ 지식 그래프 · 다음: 지식 그래프가 벡터 DB를 대체할 것인가

뉴스 정리 시스템을 만들어 테크 회사 애플의 최신 동향을 모으려 했는데, 시스템이 과수원 풍작·사과 가격 하락 뉴스를 잔뜩 밀어 준다. 글자 층위의 검색은 성공했지만(「애플」이라는 글자를 확실히 찾아냈다) 결과는 완전히 빗나갔다.

이름을 보았다고 해서 그 객체를 아는 것은 아니다.

컴퓨터가 사람의 언어를 이해할 때 이름을 찾는 것은 첫 단계일 뿐이고, 두 가지 문제가 더 남아 있다.

#1단계 · 엔티티 추출: 전문 영역에서는 개체명 인식이라 부른다

핵심 과제는 매우 단순하다: 연결된 텍스트 안에서 사람, 회사, 장소, 제품을 대표하는 단어를 네모로 표시해내는 것.

왜 이 단계가 필요한가: 컴퓨터의 눈에 한 문장은 이어 붙은 문자열일 뿐이며, 어떤 단어가 이름인지 모른다.

예문: 마윈이 알리바바를 창업했다

엔티티 추출 프로그램이 해야 할 두 가지:

1. 정밀 분리 — 「마윈」과 「알리바바」 두 단어를 연속 텍스트에서 잘라낸다.
2. 대략적인 라벨 부착 — 시스템에게 알려준다: 마윈은 인명일 가능성이 있고, 알리바바는 회사일 가능성이 있다.

**"가능성이 있다", "대략적인 라벨"**이라는 표현에 주목할 것 — 이 단계가 주는 것은 유형에 대한 초기 판단이지 신원에 대한 결론이 아니다.

#엔티티 추출의 경계

엔티티 추출이 답한 질문: 텍스트 안 어디에 엔티티가 있는가?     → ✅ 해결됨
엔티티 추출이 답하지 않은 질문: 이 이름 뒤의 구체적 대상이
                              현실 세계의 어느 객체인가?      → ❌ 미해결

#2단계 · 엔티티 링킹: 지식베이스는 거대한 주민등록부다

핵심 문제: 텍스트에 나타난 이름을 지식베이스의 어떤 유일한 객체에 대응시키는 것.

• 지식베이스를 거대한 주민등록부라고 상상하자.
• 각 현실 세계의 객체에는 유일한 주민등록번호가 있다.

링킹은 텍스트의 이름과 주민등록부의 번호를 짝짓는 것이다.

#별칭 폭발

일상 대화와 글에서 같은 객체를 부르는 호칭은 천차만별이다.

처리하지 않으면 시스템은 이것들이 서로 다른 세 회사라고 여기고, 그들에 관한 정보를 서로 다른 곳에 분산 저장한다.

엔티티 링킹이 하는 일은 이 서로 다른 표기들을 전부 지식베이스의 그 유일한 기업 계정에 매핑하는 것이다. 링킹이 성공해야만 시스템이 사방팔방의 서로 다른 문서에서 온 사실들을 같은 객체의 이름 아래 정확히 집계할 수 있다.

#3단계 · 엔티티 중의성 해소: 다의어가 일으키는 신원 충돌

그런데 이름과 주민등록부를 짝지을 때 큰 골칫거리가 있다: 같은 이름이 완전히 다른 객체를 가리킬 수 있다.

#중의성 해소의 판단 근거: 문맥 어휘 + 엔티티 유형

1. 그 단어의 앞뒤 문맥을 본다
   예: 주변에 「판매량」「신제품 발표회」가 있는가  → 경향: 회사
       주변에 「과수원」「수확」이 있는가            → 경향: 과일
2. 그 단어의 엔티티 유형을 참조한다
   유형 정보와 문맥을 합쳐 종합 판단
→ 결론: 여러 후보 의미 중에서 유일하게 올바른 하나를 고른다

#엔지니어링 현실: 깨끗한 파이프라인이 아니다

실제 응용에서 엔티티 추출·링킹·중의성 해소 세 고리는 항상 한 단계씩 완전히 분리된 파이프라인은 아니다.

• 현대적 시스템은 추출과 링킹을 함께 놓고 공동으로 완수할 가능성이 크다(Joint Model).
• 여러 판단 근거를 동시에 써서 함께 판단한다: 미리 작성한 규칙, 전문 사전, 대규모 언어 모델의 이해 능력.

#기술 경계: 신뢰도 평가와 사람의 교정은 생략할 수 없다

얼마나 선진적인 모델을 쓰든, 이 단계에서는 반드시 결과에 대한 신뢰도 평가와 사람의 교정 메커니즘을 남겨야 한다.

이유는 이 세 단계가 지식 네트워크 구축의 기초이며 오류가 그래프 구조를 따라 확산되기 때문이다.

링킹/중의성 해소 시 대상을 잘못 고름(엉뚱한 대상에 씌움)
        ↓
이후 분석된 모든 연관 관계가
        ↓
전부 잘못된 엔티티에 매달림
        ↓
「복잡한 그물에서 매듭 하나를 잘못 묶은 것」
        ↓
그래프 전체의 데이터 품질이 심각하게 오염됨

#세 명사의 한 줄 분업

자연어 처리의 세계에서 이름을 찾은 것은 정말로 올바른 객체를 찾은 것과 다르다.

#핵심 통찰

1. 문자열 매칭 성공이 의미 과제 성공을 뜻하지 않는다 — 서두의 사고가 바로 그런 경우다. 시스템은 확실히 "애플이라는 두 글자를 찾았고" 검색 층위로는 흠잡을 데 없지만 업무 층위로는 전부 틀렸다. 추출 시스템을 평가할 때 "이름을 적중했다"와 "객체를 적중했다"는 반드시 나눠서 봐야 할 두 지표다.
2. 이름과 객체 사이에는 두 겹의 낙차가 있지 한 겹이 아니다 — 한 겹은 "여러 표기 → 같은 객체"(다대일, 링킹으로 해결), 다른 한 겹은 "같은 표기 → 여러 객체"(일대다, 중의성 해소로 해결). 두 방향의 실패 모드가 각각 다르므로 같은 수단으로 막으려 하면 대개 막히지 않는다.
3. 엔티티 추출이 주는 것은 "대략적인 라벨"이지 신원이 아니다 — "인명일 가능성이 있다", "회사일 가능성이 있다" 같은 표현이 반복된다. 유형 판단과 신원 판단은 서로 다른 입도의 결론이며, 유형 라벨을 신원 확인으로 오인하는 것이 절차상 가장 쉽게 건너뛰는 단계다.
4. 지식베이스의 가치는 "유일한 신원"에 있지 "몇 건을 저장했는가"에 있지 않다 — 주민등록부 비유의 관건은 그것이 두껍다는 것이 아니라 각 객체에 주민등록번호가 하나뿐이라는 것이다. 이 유일성이 없으면 서로 다른 문서에서 온 사실들을 같은 객체 아래 집계할 수 없고, 지식베이스는 서로를 알아보지 못하는 파편 더미로 퇴화한다.
5. 중의성 해소는 본질적으로 "후보 집합 + 채점"의 객관식이지 이해 문제가 아니다 — 하나의 이름에 여러 후보 의미가 있고 → 문맥 어휘와 엔티티 유형으로 종합 판단해 → 후보 중 유일하게 올바른 하나를 고른다. 객관식으로 이해하면 "후보는 어디서 오는가", "무엇으로 채점하는가", "점수가 낮으면 어떻게 하는가"라는 엔지니어링 가능한 질문들이 자연히 따라온다.
6. 그래프 구조는 오류를 희석하는 것이 아니라 증폭한다 — 관계형 데이터에서 한 행을 잘못 쓰면 대개 그 한 행에만 영향을 주지만, 지식 그래프에서 객체 하나를 잘못 링킹하면 이후 분석되는 모든 연관 관계가 잘못된 엔티티에 매달린다. "매듭 하나를 잘못 묶었다"는 비유의 요점은 오류의 영향 범위가 오류의 개수가 아니라 그래프의 연결성에 의해 결정된다는 것이다.
7. 모델이 선진적일수록 신뢰도 평가와 사람의 교정을 없앨 수 없다 — 이것은 모델 능력의 함수가 아니라 이 층이 시스템에서 차지하는 위치의 함수다. 기초층이므로 그 오류를 받아 줄 하류가 없다.
8. 파이프라인은 설명 순서이고 공동 모델이 엔지니어링 형태다 — "추출 → 링킹 → 중의성 해소" 3단은 이해에 편하지만, 현대적 시스템은 추출과 링킹을 함께 놓고 공동으로 완수할 가능성이 크다. 배울 때는 나눠서 배우고 만들 때는 굳이 나누지 않아도 된다.

#엔지니어링 실전 Tips

• 요구를 논하기 전에 "이름"과 "객체" 두 단어를 먼저 구분할 것: 요구 문서에 "회사를 식별한다"고 쓸 때, 회사명을 네모로 표시하겠다는 것인지 어느 회사인지 확정하겠다는 것인지 명확히 할 것 — 작업량이 두 단계나 차이 난다.
• 별칭 표가 링킹층의 일급 시민이다: 알리 / 알리바바 그룹 / Alibaba 세 표기를 처리하지 않으면 시스템이 세 회사로 여겨 정보가 분산 저장된다. 별칭 수집이 완전하지 않으면 링킹층의 리콜이 올라가지 않는다.
• 중의성 해소 단서는 두 종류이며 하나만 쓰지 말 것: 문맥 어휘(판매량·신제품 발표회 / 과수원·수확)는 국소 증거이고 엔티티 유형은 사전 증거이며, 강조되는 것은 종합 판단이다. 문맥 어휘만 보면 문맥이 희박한 짧은 텍스트에서 속수무책이 된다.
• 같은 단어의 정답은 장면에 따라 변한다: 장안은 옛 시에서 고대 지명이고 자동차 포럼에서는 자동차 브랜드다. 코퍼스 출처 자체가 강력한 단서이므로 중의성 해소 시 문서의 장면 정보를 버리지 말 것.
• 결과에 신뢰도 필드를 남길 것: 점수가 있어야 분류 처리를 논할 수 있다 — 고득점은 자동 적재, 저득점은 사람에게.
• 사람의 교정 입구는 하류가 아니라 링킹/중의성 해소 층에 세울 것: 오류가 잘못된 엔티티에 매달리면 연관 관계를 따라 확산되며, 하류 분석 리포트에서 문제가 생긴 뒤에 소급하면 비용이 이미 그래프 전체의 데이터 품질 문제가 된다.
• 설명 순서가 시스템 아키텍처는 아니다: 현대적 시스템은 추출과 링킹을 공동으로 완수할 가능성이 크므로, 3단식 직관에 맞추려고 억지로 모듈을 쪼개지 말 것.
• 더 파고들 방향: 후보 생성의 엔지니어링 방식(후보 집합을 어떻게 리콜하고 크기를 어떻게 통제할 것인가), 신뢰도 임계값의 결정과 저신뢰 샘플의 사람 재심사 절차, 공동 모델 vs 단계별 파이프라인의 취사선택(설명 가능성·디버깅 용이성·교정 입도), 그래프가 이미 구축된 뒤에 이런 잘못된 링킹을 발견하고 롤백하는 방법.