Building Enterprise AI Automation Systems 시리즈의 4부

서론

대부분의 개체명 인식 (Named Entity Recognition, NER) 튜토리얼은 예측(prediction) 단계에서 끝납니다.

모델은 다음과 같이 성공적으로 추출합니다:

COMPANY
INVOICE
CONTRACT
...

그리고 기사는 끝납니다.

노트북은 아름다운 JSON 응답을 출력합니다.

임무 완수입니다.

겉보기에는 그렇게 보입니다.

실제 기업용 시스템(enterprise systems)에서 엔티티를 추출하는 것은 시작일 뿐입니다.

다음과 같은 예측을 가정해 봅시다:

{
    "COMPANY":"ALPHABRIDGE",
    "INVOICE":"MFG-INV-000157"
...

언뜻 보기에는 모든 것이 올바르게 보입니다.

하지만 비즈니스 관점에서 보면, 시스템은 여전히 거의 아무것도 알지 못합니다.

질문들이 해결되지 않은 채 남아 있습니다.

어떤 ALPHABRIDGE인가?

어떤 고객 기록인가?

어떤 계약인가?

어떤 송장(invoice)인가?

어떤 비즈니스 관계인가?

이러한 질문들은 개체 해상도 (Entity Resolution)라고 알려진 완전히 다른 문제에 속합니다.

개체 해상도 (Entity Resolution)는 추출된 텍스트를 비즈니스 지식으로 변환합니다.

이것 없이는 AI가 단어는 이해할지언정 비즈니스는 이해하지 못합니다.

NER은 텍스트를 찾는다

개체명 인식 (Named Entity Recognition, NER)은 한 가지 질문에 답합니다:

"어떤 텍스트 조각이 의미 있는 엔티티를 나타내는가?"

예를 들어:

PAYMENT FROM ALPHABRIDGE SOLUTIONS MFG-INV-000157

은 다음과 같이 변합니다:

{
    "COMPANY":"ALPHABRIDGE SOLUTIONS",
    "INVOICE":"MFG-INV-000157"
...

이것은 추출 (extraction)입니다.

그 이상도 이하도 아닙니다.

모델은 다음 사항에 대해 전혀 알지 못합니다:

• 해당 회사가 존재하는지,
• 해당 송장(invoice)이 존재하는지,
• 해당 송장이 그 회사에 속해 있는지,
• 해당 송장이 이미 결제되었는지,
• 해당 계약이 여전히 유효한지.

추출은 구문 (syntax)입니다.

기업 자동화 (Enterprise automation)에는 의미론 (semantics)이 필요합니다.

숨겨진 문제

다음과 같은 고객 마스터(customer master)를 상상해 보십시오.

CUS-00001

ALPHABRIDGE SOLUTIONS

이제 다음과 같은 거래 내역(transaction narratives)을 받는다고 가정해 봅시다.

PAYMENT FROM ALPHABRIDGE

PAYMENT FROM ALPHABRIDGE LTD

PAYMENT FROM ABS

PAYMENT FROM ALPHA BRIDGE

인간은 이것들이 동일한 고객임을 즉시 인식합니다.

기계는 그렇지 못합니다.

컴퓨터에게 모든 문자열은 서로 다릅니다.

해상도(Resolution) 없이는 자동화가 즉시 중단됩니다.

개체 해상도(Entity Resolution)가 실제로 하는 일

개체 해상도(Entity Resolution)는 다른 질문에 답합니다.

다음과 같은 질문 대신:

"이것은 어떤 개체인가?"

다음과 같이 질문합니다:

"이 개체는 어떤 비즈니스 객체(Business Object)를 나타내는가?"

예를 들어:

개체명 인식 (NER) 출력

{
    "COMPANY":"ALPHABRIDGE"
}

개체 해상도 (Entity Resolution) 출력

{
    "customer_id":"CUS-00002",
    "legal_name":"ALPHABRIDGE SOLUTIONS",
...

차이점을 주목하세요.

출력값은 더 이상 텍스트가 아닙니다.

그것은 비즈니스 지식(Business Knowledge)입니다.

기업 데이터가 어려운 이유

기업 시스템은 수십 년에 걸쳐 진화합니다.

고객의 이름이 바뀝니다.

기업이 합병됩니다.

자회사가 생겨납니다.

법인(Legal Entity)의 명칭이 변경됩니다.

지역 사무소는 약어를 사용합니다.

그 결과:

Microsoft

Microsoft Ltd
...

이 모두 서로 다른 법인을 가리킬 수도 있습니다.

또는 정확히 동일한 법인을 가리킬 수도 있습니다.

오직 비즈니스 문맥(Business Context)만이 그 질문에 답할 수 있습니다.

해상도 전략 (Resolution Strategies)

현대의 개체 해상도(Entity Resolution) 엔진은 단일 알고리즘에 의존하는 경우가 드뭅니다.

대신, 여러 전략을 결합합니다.

1. 완전 일치 (Exact Matching)

가장 단순한 접근 방식입니다.

ALPHABRIDGE SOLUTIONS

↓
...

빠릅니다.

신뢰할 수 있습니다.

하지만 매우 제한적입니다.

2. 별칭 일치 (Alias Matching)

많은 기업이 별칭 사전(Alias Dictionary)을 유지 관리합니다.

예시:

ABS

↓
...

또는

IBM

↓
...

별칭 조회(Alias Lookup)는 재현율(Recall)을 극적으로 향상시킵니다.

3. 정규화 (Normalization)

매칭을 수행하기 전에 형식의 차이를 제거해야 합니다.

예시:

MFG INV 000157

↓
...

마찬가지로:

INV001

↓
...

정규화는 종종 머신러닝(Machine Learning)보다 더 많은 문제를 해결합니다.

4. 퍼지 매칭 (Fuzzy Matching)

어떤 차이점들은 정규화될 수 없습니다.

예시:

ALPHA BRIDGE

↓
...

레벤슈타인 거리(Levenshtein distance)와 같은 퍼지 유사도 알고리즘은 일치할 가능성이 높은 항목을 식별할 수 있습니다.

하지만 퍼지 매칭은 주의해서 사용해야 합니다.

유사도 임계값(Similarity Threshold)이 낮으면 오탐(False Positives)이 증가합니다.

5. 임베딩 유사도 (Embedding Similarity)

마지막 전략은 의미론적 표현(Semantic Representations)을 사용합니다.

문자를 비교하는 대신,

의미를 비교합니다.

문장 임베딩 (Sentence embeddings)을 사용하면 시스템이 다음과 같은 사례를 인식할 수 있습니다.

Advance Payment

Project Deposit

이들이 유사한 비즈니스 개념을 나타낼 수 있음을 말입니다.

임베딩 유사도 (Embedding similarity)는 자유 형식의 서술형 데이터 (free-form narratives)를 다룰 때 특히 유용해집니다.

하이브리드 해상 (Hybrid Resolution)

실제 운영 환경 (production)에서는 단일 전략만으로는 충분하지 않습니다.

전형적인 파이프라인은 다음과 같습니다.

NER 출력 (NER Output)
      │
      ▼
...

모든 단계는 신뢰도 (confidence)를 높입니다.

모든 단계는 모호성 (ambiguity)을 줄입니다.

신뢰도 점수 (Confidence Scores)

개체 해상 (Entity Resolution)은 단순히 일치 여부만을 반환해서는 안 됩니다.

신뢰도 또한 함께 반환해야 합니다.

예시:

{
    "customer_id":"CUS-00002",
    "match_method":"alias",
...

신뢰도가 있으면 다운스트림 시스템 (downstream systems)이 다음과 같이 결정할 수 있습니다.

높은 신뢰도 (High Confidence)

↓
...

또는

낮은 신뢰도 (Low Confidence)

↓
...

신뢰도는 실제 운영되는 AI 시스템의 가장 중요한 특징 중 하나입니다.

해상이 자동화를 가능하게 하는 이유

두 가지 시나리오를 상상해 보십시오.

개체 해상 (Entity Resolution)이 없는 경우:

{
    "COMPANY":"ALPHABRIDGE"
}

데이터를 조정 (reconcile)할 수 있습니까?

아니요.

송장 (invoices)을 검증할 수 있습니까?

아니요.

ERP를 업데이트할 수 있습니까?

아니요.

워크플로 (workflows)를 트리거할 수 있습니까?

아니요.

이제 다음을 고려해 보십시오:

{
    "customer_id":"CUS-00002",
    "contract_id":"CNT-2024-587",
...

모든 것이 바뀝니다.

비즈니스 규칙 (Business rules) 적용이 가능해집니다.

자동화 (Automation)가 가능해집니다.

의사결정 엔진 (Decision engines) 구축이 가능해집니다.

AI 에이전트 (AI Agents) 구현이 가능해집니다.

개체 해상 (Entity Resolution)은 그 가교 역할을 합니다.

해상 엔진 구축하기

우리가 구현한 아키텍처 (architecture)는 다음과 같습니다.

NER 예측 (NER Prediction)
        │
        ▼
...

각 구성 요소는 하나의 책임만을 가집니다.

이러한 모듈형 아키텍처 (modular architecture) 덕분에 시간이 지남에 따라 시스템을 더 쉽게 개선할 수 있습니다.

교훈 (Lessons Learned)

이 프로젝트를 진행하며 가장 놀라웠던 점은 개체 해상 (Entity Resolution)이 트랜스포머 (transformer) 모델 자체를 학습시키는 것보다 더 어렵다는 사실을 깨달은 것이었습니다.

모델을 학습시키는 것은 주로 엔지니어링 작업입니다.

하지만 개체 해상 (Entity Resolution)을 구축하는 데는 비즈니스가 어떻게 운영되는지에 대한 이해가 필요합니다.

도메인 지식 (domain knowledge)이 필요합니다.

마스터 데이터 (Master data).

비즈니스 규칙 (Business rules).

역사적 맥락 (Historical context).

다시 말해:

NER은 언어를 학습합니다.

Entity Resolution은 비즈니스를 학습합니다.

결론 (Conclusion)

AI에 관한 대부분의 논의는 정보 추출 (Information extraction)에 집중되어 있습니다.

기업 자동화 (Enterprise automation)에는 정보에 대한 이해가 필요합니다.

개체명 인식 (Named Entity Recognition, NER)은 개체 (Entities)를 식별합니다.

Entity Resolution은 이러한 개체들을 신뢰할 수 있는 비즈니스 객체 (Business objects)로 변환합니다.

이러한 변환을 통해 대조 (Reconciliation), 분석 (Analytics), 지능형 워크플로 (Intelligent workflows), 그리고 자율적 의사결정 (Autonomous decision-making)이 가능해집니다.

Entity Resolution이 없다면, 기업용 AI는 언어 모델 (Language model)에 머물게 됩니다.

Entity Resolution이 있다면, 그것은 운영 시스템 (Operational system)이 됩니다.

다음 단계는? (What's Next?)

제5부에서는 다음 요소들을 결합한 대조 엔진 (Reconciliation Engine)을 구축할 것입니다:

• 개체명 인식 (Named Entity Recognition)
• Entity Resolution
• 비즈니스 규칙 (Business Rules)
• 검증 로직 (Validation Logic)
• 의사결정 지능 (Decision Intelligence)

이를 통해 기업의 트랜잭션 (Transactions)이 인간의 개입 없이 자동으로 대조될 수 있는지 여부를 결정할 것입니다.

또한 거대 언어 모델 (Large Language Models, LLM) 시대에도 왜 규칙 엔진 (Rule engines)이 여전히 중요한지에 대해서도 논의할 것입니다.