Skip to main content

AI 품질 보정과 데이터 재생산 파이프라인

AI 품질 보정과 데이터 재생산 파이프라인

1. Translator-Agent 2.0의 설계 목표

9월 초부터 수집되는 데이터의 양이 폭증하면서 AI 번역 품질이 일관되지 않다는 문제가 보고되었다. 평균 BLEU 점수는 0.82 수준이었지만 언어 간 편차가 컸고, 특정 기술 문서에서 용어가 반복적으로 오역되었다. Translator-Agent 2.0의 목적은 AI가 스스로 품질을 예측하고, 낮은 품질의 데이터를 재생산하도록 만드는 것이었다.

  • BLEU, TER, Context Vector를 이용한 품질 점수화
  • 자동 재번역 루프 (Re-Translation Loop)
  • Quality-Driven Event Routing (품질 점수 기반 라우팅)
  • 자동 승인 및 검증 리포트 생성

이 시스템에서 "품질 보정"이라 함은 AI가 생성한 결과물을 AI가 다시 검증하는 구조를 말한다. 사람이 모든 번역 결과를 하나씩 검토하는 것은 물리적으로 불가능하므로, AI가 1차 생성 후 별도의 검증 파이프라인을 거쳐 기준을 충족하지 못하는 데이터만 재처리하는 방식을 채택했다.

2. 품질 평가 메커니즘

Translator-Agent 2.0은 번역이 완료되면 즉시 BLEU와 TER을 계산하고, 품질 점수를 생성한다. 이 점수는 0~1 사이 실수값으로 표현되며, 0.75 미만이면 재번역 큐에 등록된다. BLEU는 의미 유사도, TER은 문장 수정 비율을 측정한다. 품질 점수는 Redis의 Sorted Set에 저장되어 우선순위 처리가 가능하다. 

score = (bleu * 0.7 + (1 - ter) * 0.3)
redis.zadd("i18n.quality", {key: score})
if score < 0.75:
    publish("i18n.retranslate", {"id": pid, "lang": lang, "score": score})

평균 BLEU 점수는 0.82에서 0.87로 상승했으며, TER(수정률)은 0.28에서 0.17로 개선되었다. 이 시스템은 언어별 번역 품질 차이를 자동으로 보정하는 첫 단계가 되었다.

3. Hallucination 탐지 방법

AI 번역에서 가장 심각한 문제는 hallucination이다. 번역 결과가 원문에 없는 정보를 포함하거나, 원문의 핵심 내용을 누락하는 경우를 말한다. BLEU와 TER만으로는 이런 문제를 완벽히 탐지할 수 없기 때문에 별도의 hallucination 탐지 단계를 추가했다.

탐지는 세 가지 방법으로 수행된다.

  • 1) 원문과 번역문의 엔티티(숫자, 고유명사, 단위) 대조. 원문에 "ISO 9001"이 있는데 번역문에 없으면 탐지됨
  • 2) 원문 대비 번역문 길이 비율 검사. 원문의 0.5배 미만이거나 2.0배 초과면 이상 징후로 판단
  • 3) 의미 벡터(Semantic Embedding) 유사도 계산. 코사인 유사도가 0.7 미만이면 hallucination 의심
def detect_hallucination(source, translation):
    # Entity check
    src_entities = extract_entities(source)
    tgt_entities = extract_entities(translation)
    missing = src_entities - tgt_entities

    # Length ratio check
    ratio = len(translation) / len(source)
    length_ok = 0.5 <= ratio <= 2.0

    # Semantic similarity
    sim = cosine_similarity(embed(source), embed(translation))

    if missing or not length_ok or sim < 0.7:
        return {"hallucination": True, "reason": {...}}
    return {"hallucination": False}

이 탐지 파이프라인 도입 후, hallucination이 포함된 번역이 그대로 서비스에 반영되는 비율이 크게 줄어들었다. 탐지된 데이터는 자동으로 재번역 큐에 등록된다.

4. Confidence Scoring과 Human-in-the-Loop

모든 AI 생성 결과물에는 confidence score가 부여된다. 이 점수는 BLEU, TER, hallucination 탐지 결과, 품질 예측 모델의 출력을 종합한 값이다. confidence score에 따라 후속 처리 방식이 달라진다.

  • 0.9 이상: 자동 승인. 사람의 검토 없이 서비스에 반영
  • 0.75~0.9: 조건부 승인. 자동 반영하되, 일일 샘플링 검토 대상에 포함
  • 0.65~0.75: 재번역 큐 등록. AI가 다른 모델/설정으로 재번역
  • 0.65 미만: 사람 검토 필수. Telegram으로 관리자에게 통보하고 수동 검토 요청

전체 데이터 중 0.65 미만으로 분류되어 사람이 직접 검토해야 하는 비율은 약 2~3% 수준이다. 이 방식은 대량의 데이터를 처리하면서도 품질 기준 이하의 결과가 서비스에 반영되는 것을 방지하는 균형점이다. AI가 대부분의 품질 관리를 수행하되, 최종 안전망은 사람이 담당한다.

5. 재번역 루프 (Re-Translation Loop) 구조

i18n.retranslate 이벤트를 수신하면 Translator-Agent는 재번역을 수행한다. 재번역 시에는 DeepSeek 대신 ChatGPT 모델을 단독으로 사용하며, 이전 번역 결과를 문맥으로 제공한다. 이를 "contextual reinforcement"라 명명했다. 

context = db.get_translation(pid, lang)
new = chatgpt.rewrite(context, mode="contextual")
db.save_translation(pid, lang, new, quality="REWRITE")

1차 번역과 2차 재번역의 BLEU 차이는 평균 +0.09, 즉 품질이 9% 향상되었다. 하루 평균 4,000건의 자동 재번역이 수행되며, 관리자는 이를 승인하지 않아도 된다. 품질 개선이 검증되면 "auto-approve" 플래그가 적용되어 시스템이 스스로 승인한다.

6. 품질 임계값 미달 시 데이터 재생산

품질 개선은 단순 재번역에 그치지 않고, 데이터 자체를 재생산하는 단계로 확장되었다. Translator-Agent는 BLEU 점수가 기준 이하일 때, 해당 데이터를 "reconstruct" 큐에 등록하여 의미적으로 새로운 문장을 생성한다. 이 과정은 단순 번역이 아니라 AI가 의미 단위로 다시 작성하는 수준이다. 

if score < 0.65:
    publish("i18n.reconstruct", {"id": pid, "lang": lang})

"reconstruct" 이벤트는 별도의 Cloud Function이 처리한다. AI는 원문과 번역문을 비교하여 의미 벡터 차이를 계산하고, 그 차이가 0.25 이상이면 완전히 새로운 표현으로 문장을 재작성한다. 재생산된 결과는 다시 품질 평가 파이프라인을 통과해야 하며, 두 번의 재생산 후에도 기준을 충족하지 못하면 사람에게 전달된다.

7. 피드백 루프와 모델 개선

품질 보정 시스템의 핵심 가치는 단순히 낮은 품질의 데이터를 걸러내는 것이 아니라, 시간이 지나면서 AI의 초기 생성 품질 자체를 향상시키는 것이다. 이를 위해 피드백 루프를 구축했다.

재번역이 발생한 원본-번역 쌍, 사람이 수정한 결과, hallucination이 탐지된 사례 등이 모두 학습 데이터로 축적된다. 이 데이터는 주간 단위로 분석되어 어떤 유형의 텍스트에서 품질이 떨어지는지, 어떤 언어 조합에서 오역이 빈번한지를 파악한다.

분석 결과는 Translator-Agent의 프롬프트 템플릿에 반영된다. 예를 들어 "태국어 기술 문서에서 계량 단위 번역 시 원문 단위를 그대로 유지할 것"이라는 규칙이 피드백 데이터 분석을 통해 추가되었다. 이 피드백 루프 적용 후, 재번역이 필요한 비율이 점진적으로 감소하는 추세를 보이고 있다.

8. 품질 점수 예측 모델 (Quality Predictor)

반복적으로 품질이 낮은 데이터 패턴을 탐지하기 위해, Translator-Agent 2.0에는 LightGBM 기반 품질 예측 모델이 내장되었다. 입력은 문장 길이, 기술용어 비율, 번역 일관성, 이전 BLEU 점수의 이동평균 등이다. 이 모델은 번역이 수행되기 전에 품질을 예측하고, 낮은 품질이 예상되면 ChatGPT 단독 번역 모드로 전환한다. 

if quality_predictor.predict(features) < 0.7:
    mode = "chatgpt"
else:
    mode = "deepseek+chatgpt"

품질 예측 정확도는 89.7% 수준으로 측정되었다. AI가 사전 예측으로 번역 모드를 조정함으로써 전체 재번역량이 34% 감소했다.

9. AI 검증 루프 및 자동 승인 구조

모든 번역과 재생산 데이터는 두 번의 검증 루프를 거친다. 1차는 Translator-Agent의 내부 품질 모델, 2차는 Classifier-Agent의 문맥 정합성 평가이다. 두 점수 모두 0.8 이상이면 자동 승인된다. 

if quality_score > 0.8 and context_score > 0.8:
    db.update_status(pid, lang, "APPROVED")
    publish("i18n.finalized", {"id": pid, "lang": lang})

승인 루프는 인간의 개입 없이 수행된다. Telegram 리포트에는 일일 승인, 재번역, 재생산 통계가 요약된다. 

*Translation Quality Report*
Total Translations: 47,113
Rewrites: 3,942 (8.3%)
Reconstructs: 1,174 (2.4%)
Auto-Approved: 92.6%
Avg BLEU: 0.87
Avg TER: 0.16
Hallucination Detected: 287 (0.6%)

10. 데이터 배포 및 글로벌 동기화

재생산된 데이터는 MQ를 통해 각 리전의 Redis와 MySQL에 자동 반영된다. AI Ops-Agent는 품질 등급에 따라 TTL을 다르게 설정하여 낮은 품질의 데이터는 짧게 캐시되도록 했다. 

if score >= 0.9:
    ttl = 86400  # 24h
elif score >= 0.8:
    ttl = 43200  # 12h
else:
    ttl = 10800  # 3h

이 방식으로 높은 품질의 데이터는 더 오래 유지되고, 낮은 품질은 빠르게 갱신된다. Redis 캐시의 품질별 분포는 "A등급(24h)" 68%, "B등급(12h)" 22%, "C등급(3h)" 10% 수준으로 안정화되었다.

11. 결과 및 현재 상태

Translator-Agent 2.0의 도입으로 번역 품질 관리 체계는 완전히 자동화되었다. AI는 데이터를 번역할 뿐 아니라, 품질을 판단하고 개선하는 자율적 루프를 운영한다. BLEU/TER 기반 점수화, hallucination 탐지, 재번역 큐, 재생산 파이프라인, 품질 예측 모델이 통합되어 대부분의 품질 관리가 자동으로 수행된다.

  • 평균 BLEU 0.87 / TER 0.16
  • 재번역 성공률 94%
  • 자동 승인 비율 92.6%
  • 재생산 데이터 1,174건 /일
  • Hallucination 탐지율 0.6%
  • 사람 검토 필요 비율 2.3%
  • MQ 처리량 2,800 msg/sec

다만 AI 품질 보정 시스템이 완벽하다고 말할 수는 없다. confidence score가 높더라도 문맥적으로 부적절한 번역이 통과되는 경우가 간혹 있으며, 이런 사례는 사용자 피드백을 통해 수집되어 다음 주기의 학습 데이터에 포함된다. AI가 품질을 유지하고 보정하는 자율형 구조이지만, 그 시스템 자체의 정확성을 검증하는 것은 여전히 사람의 몫이다.

관련 글

Labels:

Popular posts from this blog

11년의 무역 데이터가 AI를 만든다 , RAG 지식 베이스 구축 과정

AI를 제품에 넣겠다고 하면 대부분 두 가지 중 하나를 떠올린다. GPT를 fine-tuning하거나, RAG를 쓰거나. 우리는 RAG를 택했다. 이유가 있다. REINDEERS는 2015년 IMARKET Thailand 설립 이후 약 11년간 동남아시아에서 B2B 무역을 해왔다. 25,000건 이상의 거래, 4,300개 이상의 파트너, 4개국의 규제 데이터. 이 데이터가 우리의 경쟁력이다. 문제는 이 데이터를 AI가 활용할 수 있는 형태로 만드는 과정이 생각보다 훨씬 복잡했다는 거다. 이 글은 그 과정에 대한 기록이다. 한 가지를 먼저 밝히고 시작한다. 이 RAG 지식 베이스는 단순히 "챗봇이 무역 지식을 참조하는 데이터 창고"가 아니다. REINDEERS와 POP, DVRP는 지금 AI로 전환되는 구조 위에 올라서 있다. 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 수행한다. 이 Agent들 , 구매 Agent, 물류 Agent, 통관 Agent, 재무 Agent , 이 사람 대신 판단을 내릴 때 "왜 이렇게 결정했는가"를 반드시 설명할 수 있어야 한다. 그 설명의 출처가 바로 이 RAG 지식 베이스다. 11년의 무역 데이터는 Agent가 환각 없이 결정을 내릴 수 있는 유일한 근거다. RAG를 선택한 이유 먼저 RAG(Retrieval-Augmented Generation)가 뭔지를 간단히 정리하자. LLM에 질문을 던질 때, 질문만 보내는 게 아니라 관련 데이터를 함께 보내는 방식이다. "태국산 베어링 수입 단가가 얼마야?"라고 물으면, 우리 데이터베이스에서 관련 거래 이력을 찾아서 LLM에 컨텍스트로 넘긴다. LLM은 그 컨텍스트를 바탕으로 답을 생성한다. Fine-tuning을 선택하지 않은 이유는 명확하다. 무역 데이터는 계속 바뀐다. 베어링 단가는 분기마다 변동한다. 태국 FDA 규제는 수시로 개정된다. 선사 운임은 매...
Read more

B2B 견적의 AI Agent화 , 고객사·공급사·포워더가 AI로 견적을 주고받는 구조

B2B 거래에서 견적은 단순한 가격표가 아니다. 바이어의 구매 이력, 공급사의 재고 상황, 물류 비용, 인코텀즈, 납기일, 결제 조건 , 이 모든 변수가 얽힌 협상의 산물이다. 현재 이 과정은 이메일과 전화, 스프레드시트로 이루어진다. 바이어가 RFQ를 보내면 공급사가 검토하고, 포워더에게 물류 견적을 받아 합산하고, 다시 바이어에게 회신한다. 건당 수일이 걸리는 이 과정을 AI Agent가 대신할 수 있다면 어떨까. REINDEERS는 이 구조를 설계하고 있다. 먼저 이 글의 전제를 분명히 한다. REINDEERS·POP·DVRP는 지금 AI로 전환되는 구조 위에 올라서 있다. 조직도 안에서 직원을 등록할 때 '사람', 'AI Agent', '로봇' 중에서 선택할 수 있고, 사람은 전략과 방향을 결정하고, 실제 업무는 조직도 안에 등록된 AI Agent가 수행한다. 이 글의 Buyer Agent / Supplier Agent / Forwarder Agent는 외부 AI 도구가 아니라, 각 회사의 조직도 안에 '구매팀 담당자', '영업팀 담당자', '물류팀 담당자'로 실제 등록되는 AI 직원이다. 사람 직원과 동일한 권한 모델, 동일한 예산 한도, 동일한 감사 로그 위에서 일한다. B2B 견적의 AI Agent 간 통신 시퀀스 # Buyer Agent → Supplier Agent → Forwarder Agent 1 RFQ 발송 → RFQ 수신 2 물류 견적 요청 → 요청 수신 3 견적 수신 ← 상품 견적 발송 4 물류 견적 수신 ← 물류 견적 발송 ★ 비교표 생성 → 담당자 승인 5 PO 발행 → 주문 확정 6 부킹 요청 → 부킹 확정 왜 견적에 AI Agent인가 견적 업무가 느린 이유는 복잡해서가 아니다. 반복적인 정보 수집과 조합이 사람의 시간을 잡아먹기 때문이다. 공급사 담당자가 바이어의 과거 주문 이력을 ...
Read more

Reindeers Workflow: B2B 파트너 업무 효율과 자동화를 위한 워크플로우 플랫폼

B2B 국제 무역에서 하나의 거래가 완료되기까지 관여하는 시스템과 사람의 수는 예상보다 훨씬 많다. 견적 요청에서 시작해 공급사 선정, 발주, 포워딩 비딩, 통관 서류 준비, 출하, 배송, 정산까지 — 각 단계마다 서로 다른 담당자가 서로 다른 도구에서 수작업을 반복한다. 이 현장에서 반복적으로 발생하는 비효율은 분명하다. 바이어가 견적을 확정하면 공급사에게 이메일이나 메신저로 직접 통보해야 하고, 결제가 완료되면 수동으로 정산 시트에 옮기면서 1~3일이 소요된다. 출하 후에는 선적 정보를 기반으로 CI, PL, CO를 수동 생성하며 누락이 발생하고, 배송 완료 후 공급사/포워더 정산을 수작업으로 대조하면서 오차가 누적된다. ERP, 이메일, 스프레드시트, CRM에 같은 데이터를 반복 입력하는 것도 일상이다. 이 문제들의 공통점은 명확하다. "이벤트가 발생했을 때 후속 작업이 자동으로 실행되지 않는다" 는 것이다. 견적이 확정되었다는 '사실'은 시스템에 기록되지만, 그 사실이 다음 단계의 업무를 자동으로 트리거하지는 않는다. Reindeers Workflow는 이 문제를 해결하기 위해 만들어졌다. 단순히 "자동화 도구를 제공한다"가 아니라, REINDEERS 플랫폼에서 발생하는 실제 거래 이벤트를 기반으로 후속 업무가 자동 실행되는 구조를 만드는 것이다. REINDEERS 플랫폼과의 연결: 거래 이벤트가 워크플로우를 트리거한다 Reindeers Workflow의 가장 중요한 차별점은 범용 자동화 도구가 아니라 REINDEERS 본 플랫폼의 거래 이벤트에 직접 연결 된다는 것이다. REINDEERS에서 발생하는 핵심 거래 이벤트가 MQ(Message Queue)를 통해 워크플로우의 트리거가 된다. 거래 이벤트 트리거되는 워크플로우 실행 내용 quote.confirmed 공...
Read more