#위클리 페이퍼12

1. LLM이 생성한 텍스트에서 할루시네이션(Hallucination)이란 무엇이고, 왜 문제가 되나요? 여러 LLM 서비스들은 할루시네이션 문제를 어떻게 극복하려고 시도 중일까요?

구글링 등을 통해 자유롭게 리서치해보세요. 

1) 할루시네이션(Hallucination)이란?

• LLM이 출력한 텍스트 중 사실이 아니거나 근거가 없는 내용, 또는 모델 내부에서 만들어낸 잘못된 정보가 진실인 것처럼 표현된는 현상.
  • 즉, 실제 데이터/사실과 일치하지 않지만 모델이 자신 있게 주장하는 문장들을 뜻한다.
• 유형
  • 외부 근거 불일치(Extrinsic): 모델이 외부 지식을 잘못 인용하거나 존재하지 않는 사실을 창작함
    • 예: 존재하지 않는 논문·통계·인용문을 만들어냄
  • 내부 논리 오류(Intrinsic): 모델 내부 추론에서 모순 또는 비논리적 결론 발생
    • 예: 전후 문맥에서 모순되는 주장 생성

 

2) 왜 문제가 될까?

• 신뢰성 저하: 사용자는 모델 출력을 사실로 받아들이기 쉬워 잘못된 정보 확산 위험이 커짐. 특히 의료·법률·재무 등 민감 도메인에서는 피해가 심각함.
• 의사결정 위험: 자동화된 보고서·요약·추천에 잘못된 근거가 포함되면 잘못된 비즈니스/정책 결정으로 이어질 수 있음.
• 법적·윤리적 문제: 허위 정보로 인한 명예훼손, 규제 위반, 책임 소재 불명확성 문제가 발생할 수 있음.
• 사용자 경험 악화: 반복적 오류는 서비스 신뢰도와 사용자 유지율을 저하시킴.
• 검증 비용 증가: 모든 출력을 사람이 검증해야 하는 부담이 커져 실무 적용 비용이 높아짐.

 

3) 할루시네이션의 주요 원인

• 데이터 한계와 편향: 학습 데이터의 오류, 부정확한 문서, 편향된 표현이 모델로 전이됨.
• 일반화 및 추론 성향: 모델이 훈련 분포 밖 입력에 대해 그럴듯한 추정(추측)을 생성하려는 경향을 가짐.
• 확률적 생성 특성: 온도 등 생성 파라미터에 따라 더 창의적이지만 부정확한 텍스트가 생성될 수 있음.
• 컨텍스트 불충분·모호성: 입력 프롬프트가 애매하거나 불완전하면 모델이 보충하는 과정에서 오류를 만들기 쉬움.
• 외부 지식 미연동: 최신 정보나 도메인 지식이 모델 파라미터에 없을 경우, 잘못된 확신을 섞어 답변함.
• 디코딩과정의 제약: 탐욕적/빔 디코딩 과정이 특정 오류를 증폭시키거나, 제약적 디코딩으로 불완전한 근거를 만들어냄.

 

4) 여러 LLM 서비스들이 시도하는 주요 해결책

1. Retrieval-Augmented Generation (RAG)
   • 외부 지식베이스(검색, 문서 DB)를 모델 입력에 결합해 근거 기반 응답을 생성한다. 결과에 출처(문서·문단)를 함께 제공해 검증 가능성을 높인다.
2. 툴 기반 접근(믹스: 검색기, 계산기, 데이터베이스, 브라우저)
   • 모델이 직접 검색·계산·API 호출을 통해 사실을 확인하고, 도출 결과를 바탕으로 응답한다. 툴 사용 로그를 근거로 제시해 신뢰성 향상한다.
3. 출처 표기·인용(Citation)
   • 생성 시 근거 문헌(링크, 문서 ID, 인용문)을 함께 제공하도록 유도해 사용자가 근거를 추적할 수 있게 한다.
4. 사실성 검증·후검증(Post-hoc Verification)
   • 생성된 문장에 대해 별도의 검증 모델이나 체커(FACT-checker)를 돌려 오류를 감지·수정하거나 신뢰도 점수를 부여한다.
5. 보정·불확실성 추정(Calibration & Uncertainty)
   • 출력에 신뢰도(uncertainty)를 삽입하거나, 확률/점수 기반으로 사용자가 검토해야 할 부분을 표시한다.
6. 안전한 디코딩·제약(Constrained Decoding)
   • 사전 정의된 사실 기반 지식, 금지 토픽, 또는 포맷 규칙을 적용해 비근거적 생성 가능성을 줄인다.
7. Instruction Tuning / RLHF (사람의 피드백)
   • 인간 평가자의 피드백을 통해 '정확하고 검증 가능한 응답'을 선호하도록 모델을 미세조정한다.
8. Retrieval + Reranking
   • 검색된 후보 근거를 랭커(혹은 판별자)로 우선순위 정리해 신뢰도 높은 근거만 모델에 제공한다.
9. 증강 학습 데이터(합성 반예시 포함)
   • 모델이 틀리기 쉬운 패턴을 학습하도록 조작된 데이터(negative examples, counterfactuals)를 넣어 할루시네이션 저항성을 높인다.
10. 사용자 인터페이스·워크플로 개선
    
    • “모르겠다”, “확인 필요” 같은 불확실성 답변을 기본으로 제공하거나, 출처 확인 버튼을 넣어 사람 검증 루프를 쉽게 만든다.
11. 전문 도메인 파인튜닝 + 체인오브증거(Chain-of-Thought + Retrieval)
    
    • 도메인 전문 문헌으로 파인튜닝하고, 근거 연결 과정을 명시적으로 생성하도록 유도해 신뢰도를 높인다.

 

 

2. 모델 크기를 키우는 것만으로는 성능이 일정 시점 이후 둔화되는 이유는 무엇일까요? 

• 데이터 한계(Data-limited regime)
  • 모델 파라미터가 증가해도 학습에 쓰이는 데이터 양과 다양성이 부족하면 과적합 또는 일반화 한계에 도달한다.
  • 대형 모델은 더 많은 패턴을 학습할 수 있지만, 데이터가 부족하면 유의미한 추가 정보를 얻기 어렵다.
• 샘플 효율성(데이터 대비 파라미터 효율) 한계
  • 파라미터가 늘어날수록 동일한 데이터에서 각 파라미터가 학습하는 신호의 강도가 약해질 수 있어 효율성이 떨어진다.
  • 결과적으로 성능 개선의 한계효용(diminishing marginal returns)이 발생한다.
• 최적화 난제(Optimization difficulty)
  • 매우 큰 모델은 학습 시 기울기 소실·폭주, 불안정한 학습 궤적, 배치 정규화/LayerNorm 통계 적응 문제 등이 생겨 수렴이 느려지거나 최적점에 도달하지 못할 수 있다.
  • 학습률·배치사이즈·정규화·초기화 같은 하이퍼파라미터 민감도가 커진다.
• 계산·메모리 제약과 하드웨어 병목
  • 큰 모델은 배치 사이즈를 줄이게 만들어 통계 추정이 불안정해지고, 분산 학습에서 통신 오버헤드가 성능 병목을 초래한다.
  • 결과적으로 실제로 활용 가능한 학습 스텝 수(또는 에포크 수)가 제한된다.
• 목표(데이터·태스크)와 모델 스케일 불일치
  • 단순한 태스크나 이미 포화된 벤치마크에서는 모델 용량을 늘려도 표현력이 더 이상 기여하지 못한다.
  • 태스크 복잡도와 모델 용량이 맞지 않으면 확장 효과가 적다.
• 평가·지표 포화
  • 벤치마크 상에서 이미 상향 여지가 적을 때(예: 인간 수준에 근접하거나 데이터 노이즈 수준에 도달) mAP/Accuracy/ROUGE 등 지표가 포화되어 더 큰 모델로도 개선이 미미하다.
• 효율적 파라미터 사용의 한계
  • 단순히 파라미터 수를 늘리는 방식은 파라미터가 실제로 유용한 표현을 학습하는지와는 별개다. 구조적 비효율(예: 중복 표현, 최적화되지 않은 아키텍처)은 추가 파라미터를 낭비할 수 있다.
• 분포 불일치/도메인 갭
  • 모델이 학습한 데이터 분포와 실제 테스트 분포가 다르면, 더 큰 모델도 일반화 성능 향상으로 이어지지 않는다.

 

3. PEFT가 필요한 이유는 무엇이며, 어떤 상황에서 특히 효과적인가요?

1) PEFT(파라미터 효율적 파인튜닝)가 필요한 이유

• 전체 파라미터 업데이트 비용 절감
  • 대형 사전학습 모델을 통째로 파인튜닝하면 GPU 메모리·연산 비용이 매우 커진다. PEFT는 일부 저용량 파라미터만 학습하도록 하여 메모리와 시간 비용을 크게 줄인다.
• 저장·배포 효율성 확보
  • 모델별로 전체 가중치를 저장하는 대신, 작은 어댑터(LoRA 행렬, 어댑터 모듈, 프롬프트 벡터)만 저장하면 여러 도메인/태스크별 모델 버전을 가볍게 유지할 수 있다.
• 데이터·샘플 효율성 향상
  • 소량 데이터 환경에서도 과적합 없이 빠르게 도메인 적응이 가능하다. 전체 파라미터를 건드릴 때보다 적은 데이터로도 안정적 성능 개선이 가능하다.
• 빠른 실험과 반복
  • 학습 시간이 짧아 하이퍼파라미터 탐색·A/B 실험을 빠르게 진행할 수 있다. 생산성 관점에서 실험 주기가 단축된다.
• 안전성·회복성
  • 기본 모델은 고정해두고 작은 모듈만 교체하므로, 잘못된 파인튜닝으로 인한 원모델 파괴 위험이 적다. 롤백과 관리가 용이하다.
• 자원 제약 환경에서 실무 적용 가능
  • 엣지/온프레미스/제한된 클라우드 예산 환경에서도 대형 모델의 도메인 적용이 현실적으로 가능하다.

 

 

2) PEFT가 특히 효과적인 상황

• 연산·메모리 제약이 있는 환경
  • GPU 메모리가 제한적이거나, 비용 절감이 필요할 때 PEFT가 유리하다. 배포 시 작은 업데이트 파일만 배포하면 되므로 운영 비용이 낮아진다.
• 데이터가 적은 도메인 적응(저자원 도메인)
  • 전문 분야 텍스트(의료, 법률, 기업 내부 문서 등)나 소규모 코퍼스만 있는 경우, 전체 파인튜닝보다 PEFT가 과적합을 방지하면서 효과적이다.
• 다수 태스크/다중 도메인 관리
  • 하나의 베이스 모델을 두고 여러 태스크별 어댑터를 만들어 관리할 때 유리하다. 태스크별 작은 모듈만 교체해 다양한 요구를 빠르게 지원할 수 있다.
• 반복적·빈번한 파인튜닝 필요 시
  • 개인화·사용자별 모델·A/B 실험 등 자주 파인튜닝해야 하는 워크플로에서는 전체 업데이트보다 PEFT가 비용·시간 측면에서 효율적이다.
• 모델 배포·업데이트 빈도가 높을 때
  • 엣지 디바이스나 빈번한 버전 배포가 요구되는 서비스에서 소규모 패치(어댑터)만 전송하면 되어 네트워크·스토리지 부담이 작아진다.
• 규제·프라이버시 민감 환경
  • 원모델을 변경하지 않고 도메인 데이터로 작은 모듈만 학습하면, 민감 데이터의 로컬 학습 후 모듈만 공유하는 워크플로로 프라이버시·규제 요구를 맞출 수 있다.

 

3) 대표 PEFT 기법과 특성

• LoRA (Low-Rank Adaptation)
  • 핵심: 일부 가중치 행렬을 저랭크 행렬의 합으로 근사해 업데이트한다.
  • 장점: 메모리·저장 효율 우수, Transformer의 쿼리/키/값 등 핵심 모듈에 적용해 좋은 성능을 보임.
  • 권장 상황: 대형 트랜스포머 파인튜닝, 제한된 GPU에서 빠른 실험 필요 시.
• Adapters (Houlsby-style 등)
  • 핵심: 각 층에 작은 MLP 블록을 삽입해 그 블록만 학습한다.
  • 장점: 모듈화가 쉬워 태스크별 어댑터 조합·교체 유리.
  • 권장 상황: 다수 태스크를 관리하거나 모듈 재사용이 필요한 경우.
• Prompt Tuning / Prefix Tuning
  • 핵심: 입력에 붙이는 소규모 벡터(또는 프롬프트 토큰)를 학습한다.
  • 장점: 매우 작은 파라미터 업데이트, 자연어 프롬프트보다 더 효율적.
  • 권장 상황: 생성 모델에서 간단히 행동을 조정할 때, 저장 공간 극단적 제한이 있을 때.
• BitFit
  • 핵심: 편향(bias) 파라미터만 학습한다.
  • 장점: 극히 적은 파라미터로도 일정 성능 향상 가능.
  • 권장 상황: 초경량 적응·빠른 실험용.
• LoRA + QLoRA (양자화 병행)
  • 핵심: 양자화(4/8비트)로 모델 메모리 줄이고 LoRA로 파인튜닝해 대형 모델을 단일 GPU에서 다룸.
  • 장점: 아주 큰 모델도 저비용으로 도메인 적응 가능.
  • 권장 상황: 자원 제약이 심한 실무 환경에서 대형 LLM 활용 시.