Building Enterprise AI Automation Systems 시리즈의 Part 3

서론

개체명 인식 (Named Entity Recognition, NER)은 자연어 처리 (Natural Language Processing, NLP) 분야에서 가장 오래된 문제 중 하나입니다.

대부분의 튜토리얼은 다음과 같은 예시를 사용하여 NER을 소개합니다:

• 인물 (Person)
• 조직 (Organization)
• 위치 (Location)
• 날짜 (Date)

예를 들어:

Elon Musk founded SpaceX in California.

은 다음과 같이 변환됩니다:

PERSON
ORGANIZATION
LOCATION

이 방식은 NLP의 기초를 배우는 데는 유용하지만, 엔터프라이즈 소프트웨어와는 관련성이 거의 없습니다.

기업은 전기(biographies)를 자동화하지 않습니다.

기업은 운영(operations)을 자동화합니다.

엔터프라이즈 문서에는 완전히 다른 언어가 포함되어 있습니다.

송장 (Invoices).

계약서 (Contracts).

구매 주문서 (Purchase Orders).

은행 명세서 (Bank Statements).

송금 통지서 (Remittance Advice).

결제 내역 (Payment Narratives).

ERP 수출 데이터 (ERP Exports).

이러한 문서 내부에서 중요한 개체는 "PERSON"이나 "LOCATION"이 아닙니다.

대신, 다음과 같은 비즈니스 개념입니다:

• 고객 (Customer)
• 계약 (Contract)
• 송장 (Invoice)
• 구매 주문서 (Purchase Order)
• 결제 유형 (Payment Type)

이러한 개체를 이해하는 것이 지능형 자동화를 향한 첫 번째 단계입니다.

이 글에서는 가공되지 않은 엔터프라이즈 거래 내역을 구조화된 비즈니스 지식으로 변환할 수 있는 금융 개체명 인식 (Financial Named Entity Recognition) 파이프라인을 구축할 것입니다.

일반적인 NER과 엔터프라이즈 NER의 차이점

전통적인 NER은 언어적 개체 (linguistic entities)에 집중합니다.

엔터프라이즈 NER은 운영적 개체 (operational entities)에 집중합니다.

다음 문장을 고려해 보십시오.

PART PMT ALPHABRIDGE SOLUTIONS MFG-INV-000157

일반적인 언어 모델은 다음과 같이 식별할 수 있습니다:

Organization

그리고 나머지는 모두 무시합니다.

비즈니스 관점에서 이는 거의 쓸모가 없습니다.

우리가 실제로 필요로 하는 것은 다음과 같습니다:

PAYMENT_TYPE
COMPANY
INVOICE

목표는 언어 이해가 아닙니다.

목표는 비즈니스 이해입니다.

1단계 — 비즈니스 분류 체계 (Business Taxonomy) 설계

모델을 학습시키기 전에, 모델이 무엇을 배워야 하는지 정의해야 합니다.

이 단계는 머신러닝 (machine learning) 프로젝트에서 가장 간과되기 쉬운 단계 중 하나입니다.

많은 팀이 분류 체계 (taxonomy)를 먼저 정의하지 않고 즉시 어노테이션 (annotation)을 시작합니다.

그 결과, 어노테이션이 일관되지 않게 됩니다.

모델은 혼란에 빠집니다.

평가는 신뢰할 수 없게 됩니다.

우리의 트랜잭션 인텔리전스 (transaction intelligence) 시스템을 위해, 우리는 다음과 같은 엔티티 (entities)를 정의했습니다:

COMPANY

INVOICE
...

이 엔티티들이 문법적 개념보다는 비즈니스 개념에 대응한다는 점에 주목하십시오.

파이프라인의 모든 다운스트림 (downstream) 구성 요소는 이 분류 체계에 의존합니다.

단계 2 — 어노테이션 전의 정형 데이터 (Canonical Data)

어노테이션 프로젝트에서 자주 발생하는 실수 중 하나는 가공되지 않은 운영 파일 (raw operational files)을 직접 라벨링 (labeling)하는 것입니다.

대신, 우리는 먼저 MT950 명세서를 정형 JSON 구조 (canonical JSON structure)로 변환했습니다.

원본 트랜잭션:

:61:240226C3979,85NTRFNONREF

:86:PART PMT ALPHABRIDGE SOLUTIONS MFG-INV-000157

정형 표현:

{
    "transaction_id": "TXN-000001",
    "amount": 3979.85,
...

이러한 분리는 여러 이점을 제공합니다.

파서 (parser)는 MT950을 이해합니다.

NER 모델은 내러티브 (narratives)를 이해합니다.

두 구성 요소 모두 상대방에 대한 지식이 필요하지 않습니다.

이러한 분리는 유지보수성 (maintainability)을 크게 향상시킵니다.

단계 3 — 어노테이션 전략 구축하기

어노테이션은 단순히 텍스트를 하이라이트 하는 것이 아닙니다.

그것은 비즈니스 의미론 (business semantics)을 정의하는 것입니다.

예를 들어:

PART PMT ALPHABRIDGE SOLUTIONS MFG-INV-000157

은 다음과 같이 변합니다:

PART PMT
────────
PAYMENT_TYPE
...

각 어노테이션은 운영 개념 (operational concept)을 나타냅니다.

목표는 양보다는 일관성입니다.

작더라도 고품질인 데이터셋은 거의 항상 방대하지만 일관성 없는 데이터셋보다 성능이 뛰어납니다.

단계 4 — 자동 사전 라벨링 엔진을 구축한 이유

수동 어노테이션은 비용이 많이 듭니다.

수천 개의 트랜잭션 내러티브를 라벨링하는 데는 며칠 또는 몇 주가 걸릴 수 있습니다.

처음부터 시작하는 대신, 우리는 규칙 기반 (rule-based) 사전 라벨링 (pre-labeling) 엔진을 만들었습니다.

워크플로우는 다음과 같습니다:

MT950 Narrative
        │
        ▼
...

사전 라벨링은 인간 어노테이터 (annotators)를 대체하는 것이 아니라, 반복적인 작업을 줄여줍니다.

어노테이터 (annotators)는 라벨을 직접 생성하는 대신 라벨을 검증합니다.

이는 어노테이션 (annotation) 속도를 극적으로 향상시킵니다.

단계 5 — Doccano를 이용한 어노테이션 (Annotation)

사전 라벨링 (pre-labeling) 이후, 데이터셋은 Doccano로 임포트 (import)됩니다.

각 레코드에는 이미 제안된 라벨이 포함되어 있습니다.

검토자들은 엔티티 (entities)를 수동으로 찾는 대신, 단순히 다음 항목들을 확인합니다:

• 회사명 (Company names)
• 송장 번호 (Invoice numbers)
• 계약 식별자 (Contract identifiers)
• 구매 주문서 (Purchase orders)
• 결제 유형 (Payment types)

이 프로세스는 일관성 (consistency)과 어노테이션 처리량 (annotation throughput)을 모두 개선합니다.

Doccano는 수동 라벨링 도구가 아닌 품질 보증 (quality assurance) 도구가 됩니다.

단계 6 — 학습을 위한 데이터 준비

머신러닝 (machine learning) 모델은 토큰 레벨 (token-level) 라벨을 필요로 합니다.

따라서 어노테이션된 스팬 (annotated spans)은 BIO 형식 (BIO format)으로 변환됩니다.

예시:

PART        B-PAYMENT_TYPE
PMT         I-PAYMENT_TYPE
ALPHABRIDGE B-COMPANY
...

BIO 인코딩 (encoding)을 통해 트랜스포머 (transformer) 모델은 개별 단어가 아닌 엔티티 경계 (entity boundaries)를 학습할 수 있습니다.

이는 여러 개의 토큰으로 구성된 회사명에 특히 중요합니다.

단계 7 — 도메인 특화 트랜스포머 (Domain-Specific Transformer) 파인튜닝 (Fine-Tuning)

처음부터 학습시키는 대신, 사전 학습된 언어 모델 (pretrained language model)을 파인튜닝 (fine-tuned)했습니다.

워크플로우는 다음과 같습니다:

합성 데이터셋 (Synthetic Dataset)
        │
        ▼
...

모델이 이미 언어를 이해하고 있기 때문에, 비즈니스 개념만을 학습하면 됩니다.

이는 학습 요구 사항을 극적으로 줄여줍니다.

단계 8 — 정확도 (Accuracy)를 넘어선 평가

NER 시스템에서 정확도만으로는 통찰을 얻기 어렵습니다.

대신, 우리는 다음 항목들을 평가했습니다:

정밀도 (Precision)

예측된 엔티티 중 실제 정답은 얼마나 되는가?

재현율 (Recall)

실제 엔티티 중 얼마나 많이 찾아냈는가?

F1 스코어 (F1 Score)

정밀도와 재현율 사이의 균형.

우리는 또한 각 엔티티를 독립적으로 평가했습니다.

예시:

Entity             Precision    Recall    F1

COMPANY              94.2%      91.8%    93.0%
...

이는 전체 정확도보다 훨씬 더 실행 가능한 피드백을 제공합니다.

단계 9 — NER은 시작일 뿐입니다

많은 튜토리얼이 엔티티 추출 (entity extraction) 단계에서 끝납니다.

엔터프라이즈 시스템은 그럴 수 없습니다.

모델이 다음과 같이 예측한다고 가정해 봅시다:

COMPANY

ALPHABRIDGE

추출 (Extraction)만으로는 불충분합니다.

시스템은 여전히 다음을 결정해야 합니다:

Customer ID

CUS-00002

마찬가지로,

Invoice

MFG-INV-000157

은 다음으로 해결(resolve)되어야 합니다:

Contract

CNT-2024-587

이 과정을 개체 해소 (Entity Resolution)라고 부릅니다.

이 과정이 없다면, 추출된 엔티티 (entities)들은 고립된 텍스트 조각으로 남게 됩니다.

비즈니스 이해 (Business understanding)가 아직 일어나지 않은 것입니다.

아키텍처 개요 (Architecture Overview)

금융 NER 파이프라인은 궁극적으로 다음과 같은 형태를 가집니다:

Synthetic Dataset
        │
        ▼
...

각 단계는 단일 책임 (single responsibility)을 가집니다.

이러한 모듈형 아키텍처 (modular architecture) 덕분에 전체 시스템을 더 쉽게 확장하고 유지 관리할 수 있습니다.

교훈 (Lessons Learned)

이 프로젝트를 통해 얻은 가장 큰 교훈은 예상치 못한 것이었습니다.

트랜스포머 (transformer)를 학습시키는 것이 가장 어려운 작업은 아니었습니다.

분류 체계 (taxonomy)를 설계하는 것이 가장 어려웠습니다.

고품질의 합성 데이터 (synthetic data)를 구축하는 것이 그러했습니다.

일관된 주석 (annotations)을 만드는 것도 그러했습니다.

모델은 단순히 그러한 토대로부터 학습했을 뿐입니다.

엔터프라이즈 AI 시스템은 신경망 (neural networks) 때문에 실패하는 경우가 드뭅니다.

그것들은 근본적인 비즈니스 지식이 제대로 정의되지 않았기 때문에 실패합니다.

결론 (Conclusion)

개체명 인식 (Named Entity Recognition)은 종종 자연어 처리 (natural language processing) 문제로 소개됩니다.

엔터프라이즈 소프트웨어에서 그것은 그 이상의 의미를 갖습니다.

NER은 비정형 문서 (unstructured documents)와 구조화된 비즈니스 인텔리전스 (structured business intelligence) 사이의 가교가 됩니다.

표준 데이터 (canonical data), 비즈니스 분류 체계 (business taxonomies), 자동화된 사전 레이블링 (automated pre-labeling), 인간의 검증 (human validation), 그리고 도메인 특화 트랜스포머 (domain-specific transformers)를 결합함으로써, 조직은 대규모로 운영 언어를 이해할 수 있는 시스템을 구축할 수 있습니다.

이러한 이해는 개체 해소 (entity resolution), 대조 (reconciliation), 지능형 자동화 (intelligent automation), 그리고 궁극적으로 자율적인 엔터프라이즈 운영 (autonomous enterprise operations)을 위한 토대가 됩니다.

다음 글

파트 4 — 왜 개체 해소 (Entity Resolution)가 개체명 인식 (Named Entity Recognition)보다 더 어려운가

다음 글에서는 왜 엔티티를 추출하는 것이 문제의 절반에 불과한지 탐구해 보겠습니다.

우리는 추출된 엔티티 (Entities)를 실행 가능한 비즈니스 지식으로 변환하기 위해 다음을 사용하는 프로덕션급 엔티티 해소 엔진 (Entity Resolution Engine)을 설계할 것입니다:

• 정확한 매칭 (Exact Matching)
• 별칭 매칭 (Alias Matching)
• 퍼지 매칭 (Fuzzy Matching)
• 임베딩 유사도 (Embedding Similarity)
• 신뢰도 점수 산정 (Confidence Scoring)
• 하이브리드 해소 전략 (Hybrid Resolution Strategies)