<div id="readability-page-1" class="page"><div>
  
  
  <p><span>2023년 08월 27일 작성</span></p><h2 id="tldr">TL;DR</h2>

<p>코드<sup id="fnref:1" role="doc-noteref"><a href="#fn:1" rel="footnote">1</a></sup>는 작성 중. (스테이블 디퓨전처럼 공개 못할지도..)</p>

<h2 id="시작하며">시작하며</h2>

<p>여느 ML 프로젝트가 그렇듯, LLM 도 그럴듯한 데모 만들기는 쉽다. GPT4 와 같이 엄청 큰 모델을 예산제한없이 쓸 수 있다면 훨씬 쉬워진다.</p>

<p>하지만 프로덕션 레벨의 성능(정확도/커버리지 등) 을 확보하는것은 매우 어렵다.</p>

<p>최근 이 어려움의 한복판에 있는 것이 할루시네이션(hallucination)<sup id="fnref:2" role="doc-noteref"><a href="#fn:2" rel="footnote">2</a></sup> 이라고 부르는 <strong>특징</strong>이다. (그 다음이 한국어 모델의 부재로 인해 ChatGPT 가 강제되는 것)</p>

<p>개인적으로 할루시네이션은 문제가 아니며 특징이라고 생각하므로, 제거하는 것이 아니라 제어하는 방법을 찾아야 한다고 생각한다.</p>

<p>나도 최근 몇 개의 QA 프로토타입을 구현하면서 할루시네이션을 제어하는 방법을 공부하고 있다. 아직 완벽한 해결방법은 없지만 방법들이 계속 나오고 있으므로, 시간이 지나면 temperature 처럼 파라미터 수준으로 제어할 수 있을것으로 기대하고 있다.</p>

<p>본 글에서는 모델 튜닝없이 해볼 수 있는 방법 몇개를 공유해본다.</p>

<h2 id="할루시네이션이란">할루시네이션이란</h2>

<p>할루시네이션이 문제라서 해결하고 싶어서 들어온 사람이 독자이므로 할루시네이션이 뭔지는 넘어간다.
(그럼 그냥 섹션을 지워야 하나)</p>

<h2 id="할루시네이션-제어-방법들">할루시네이션 제어 방법들</h2>

<p>해당 분야는 이제 연구되고 있는 분야이므로 LLM 만큼이나 빠르게 새 방법들이 나오고 있다.</p>

<p>여기서는 잘 알려진 내용들만 정리해본다. (잘 안알려진건 내가 모르니깐)</p>

<h3 id="데이터-전처리">데이터 전처리</h3>

<p>다른 ML들 처럼 데이터 전처리가 매우 중요하다.</p>

<p>데이터 가공과정 (예, 요약) 에서 중요한 키워드 등이 빠져버리면 이후의 모든 과정이 의미가 없어지기 때문이다.</p>

<h3 id="rag">RAG</h3>

<p>원래 없는 데이터는 파인튜닝을 하는것이 정석이지만, <strong>현재는</strong> PEFT 를 써해도 파인튜닝 비용이 부담되는 것이 사실이므로 RAG 로 파인튜닝을 대체해서 쓰는 추세이다.</p>

<p>하지만 RAG 를 구현해봤다면 알겠지만 RAG 도 제대로 구현하는 것이 만만치 않다는 것을 알 것이다.</p>

<p>데이터 chunking 하는 방법, 임베딩 모델의 성능, 임베딩 검색방법 등 구현방법에 따라 여전히 잘못된 정보를 가져올 수 있다.</p>

<h3 id="re-rank">Re-rank</h3>

<p>RAG 로 연관된 문서를 k 개 가져와서 사용하게 되는데, k+1 번째 데이터에만 정답이 들어 있다면</p>

<p>(최근 연구들에 의하면 컨텍스트를 일정개수 이상 주는 것이 큰 의미 없다고 한다, 특히 처음과 끝의 컨텍스트에 정답이 배치될 수록 성능이 좋다.)
컨텍스트 길이와 생성속도 때문에 k 개를 크게 줄 수 없는 경우가 많다.</p>

<p>벡터 데이터베이스에서 2~3배수의 문서를 가져오고, 해당 문서를 NLI (natural language inference) 또는 rerank 를 위한 모델(주로 샴 네트워크로 학습된 모델)로 해당 주제에 대해 re-rank 한 뒤, 상위 k 개로 추려서 사용한다.</p>

<p>일단 센텐스 임베딩을 통해 연관이 있는 것은 추려냈으니, 다른 메트릭을 통해 문서의 연관도를 재검증해본다는 아이디어이다.</p>

<p>리랭크는 위의 두 방식을 많이 쓰는거 같지만, 논문들의 특성상 변수제어 및 단순화를 위해서 그런 것 같다.</p>

<p>따라서, 프로덕션에서는 위의 방법에 BM25 라던가 일반 검색엔진에 쓰는 다양한 방식을 접목해서 시도 해볼 수 있을 것이다.</p>

<h3 id="프롬프트-엔지니어링을-통한-검증-evaluation">프롬프트 엔지니어링을 통한 검증 (Evaluation)</h3>

<h3 id="검증-기준">검증 기준</h3>

<p>현재 모델이 생성한 대답을 사용해도 되는지 검증하는 기준은 크게 아래 2가지 인 것 같다.</p>

<ul>
  <li>신뢰도(faithfulness): 모델이 주어진 정보를 이용해서 답변을 생성했는지 여부</li>
  <li>사실성(factuality): 모델이 생성한 정보가 사실인지 여부</li>
</ul>

<p>먼저 신뢰도는 프롬프트 엔지니어링을 통해 모델이 자신의 결과에 대해, 주어진 문서들와 연관이 있는지를 스스로 판단하게 한다.</p>

<p>예를 들어, 벡테 데이터베이스에서 3개의 문서를 가져와서 추론했다면, 모델의 생성결과가 3개의 문서 모두와 관련이 있는지 각각 물어보고 (1개의 프롬프트에서) 모두 연관이 있으면 신뢰할 수 있다는 식이다.</p>

<p>할루시네이션의 정의를 생각해보면, 사실 여부는 LLM 이 판단할 수 없다. 따라서 외부데이터를 쿼리하는 과정이 반드시 필요하다.</p>

<p>이 데이터를 확보하고 사용하는 방법은 정말 여러가지인데, 검색엔진에 쿼리를 해서 결과개수를 확인하는 간단한 방법부터, 다양하고 복잡한 방법들이 있다.</p>

<p>검색을 위한 파라미터나 사용할 방법등은 ReAct 같은 방식으로 모델이 직접 만들어낼 수도 있지만, 여튼 사실성은 외부데이터를 통해 검증할 수 밖에 없다.</p>

<h3 id="검증-방법">검증 방법</h3>

<p>제대로 된 정보가 주어졌을때 질문에 대한 답을 추론(reasoning) 하는 능력이 중요하므로 결국 추론 능력이 좋은 모델을 사용하는 것이 중요하다.</p>

<p>13B 같이 상대적으로 작은 모델은 약간만 프롬프트가 복잡해져도 이상동작을 하기 때문에, 해당 동작을 제어하는데 시간이 많이 들어간다.</p>

<p>따라서 일단 큰 모델로 시작해서 모델을 작게 줄여나가는 방식이 개발 속도를 올릴 수 있다. 오픈소스 모델로 실험중이라면 together api 같은 서비스들이 큰 도움이 될 것이다.</p>

<p>여튼 추론 능력이 충분하다면, 먼저 프롬프트 작성시 Chain of thought 등을 사용하여 모델이 생각할 시간을 충분히 주고 결과를 생성하도록 한다.</p>

<p>이후 모델이 만든 대답을 few-shot example 을 주면서 스스로 검증할 수 있도록 유도한다.</p>

<p>검증 기준에서 설명한대로 검증은 신뢰도를 중심으로 검증하게 되고, 여력이 되면 사실성에 대한 검증도 하면 된다.</p>

<h3 id="selfcheckgpt">SelfCheckGPT</h3>

<p>최근에 나온 논문 하나만 간단히 소개하고 마무리 해본다.</p>

<p>프롬프트 기반의 검증을 기존 BLEU, ROUGE 와 같이 좀 더 정형화 시킨 SelfCheckGPT<sup id="fnref:3" role="doc-noteref"><a href="#fn:3" rel="footnote">3</a></sup> 라는 방식이다.</p>

<p>해당 논문에서 소개한 아이디어는 단순한데 효과적인 것 같다.</p>

<p>ICL (in context learning) 의 역할은 모델에서 정답 임베딩 위치를 가이드해주는 역할을 한다고 알려져 있다.</p>

<p>따라서 모델이 신뢰도가 있는 정보를 생성했다면 정답이 있는 영역을 잘 찾았다는 의미이므로, beam search 로 여러개의 답을 생성하더라도 일관된 내용을 말할 것이라는 가정을 할 수 있다.</p>

<p>이를 이용해, 여러개의 문장을 생성하고 모든 문장이 일관된 정보를 보여주는지 확인한다. 모델이 생성한 문장들을 일관된 문장과 아닌 문장의 비율을 F1 스코어처럼 계산하여 inconsistency 를 확인한다.</p>

<p>약간 더 디테일하게 소개하면 아래와 같은 과정으로 점수를 계산한다.</p>

<ol>
  <li>사용자의 질문에 대한 답을 beam search 로 n개 만든다.</li>
  <li>가장 높은 확률을 가진 문장을 이용하여, 질문/답변을 생성한다.</li>
  <li>나머지 문장들을 하나씩 이용하여 생성한 질문에 대한 답을 맞춘다.</li>
  <li>답을 맞추면 mach, 못맞추면 mismatch 로 카운팅한다.</li>
  <li><code>#mismatches / (#mismatches + #matches)</code> 를 점수로 사용한다.</li>
</ol>

<p>여기서는 QA 에 대해서만 소개했지만, 실제 논문에서는 n-gram, BERTScore, NLI 에서 SelfCheck 하는 방법들을 소개하고 있으므로 다른 워크로드를 처리하고 있다면 살펴보면 좋을 것 같다.</p>

<h2 id="마치며">마치며</h2>

<p>나는 머신러닝 엔지니어도 아니고 일때문에 빠르게 공부하고 사용해 본 내용만 적었기 때문에 모든 기법을 소개하지는 못했다.</p>

<p>현재도 방법들이 계속 나오고 있으며, 워크로드와 데이터별로 다양한 방법들을 적용해야 하므로 당분간은 한두가지 방법으로 통일되기는 어렵지 않을까 예상한다. (스테이블 디퓨전도 FID 가 제일 좋은 방법은 아닌거 같지만 딱히 다른 평가방법이 없는거보면…)</p>

<hr>



</div></div>

Haandol

TL;DR
코드1는 작성 중. (스테이블 디퓨전처럼 공개 못할지도..)
시작하며
여느 ML 프로젝트가 그렇듯, LLM 도 그럴듯한 데모 만들기는 쉽다. GPT4 와 같이 엄청 큰 모델을 예산제한없이 쓸 수 있다면 훨씬 쉬워진다.
하지만 프로덕션 레벨의 성능(정확도/커버리지 등) 을 확보하는것은 매우 어렵다.
최근 이 어려움의 한복판에 있는 것이 할루시네이션(hallucination)2 이라고 부르는 특징이다. (그 다음이 한국어 모델의 부재로 인해 ChatGPT 가 강제되는 것)
개인적으로 할루시네이션은 문제가 아니며 특징이라고 생각하므로, 제거하는 것이 아니라 제어하는 방법을 찾아야 한다고 생각한다.
나도 최근 몇 개의 QA 프로토타입을 구현하면서 할루시네이션을 제어하는 방법을 공부하고 있다. 아직 완벽한 해결방법은 없지만 방법들이 계속 나오고 있으므로, 시간이 지나면 temperature 처럼 파라미터 수준으로 제어할 수 있을것으로 기대하고 있다.
본 글에서는 모델 튜닝없이 해볼 수 있는 방법 몇개를 공유해본다.
할루시네이션이란
할루시네이션이 문제라서 해결하고 싶어서 들어온 사람이 독자이므로 할루시네이션이 뭔지는 넘어간다.
(그럼 그냥 섹션을 지워야 하나)
할루시네이션 제어 방법들
해당 분야는 이제 연구되고 있는 분야이므로 LLM 만큼이나 빠르게 새 방법들이 나오고 있다.
여기서는 잘 알려진 내용들만 정리해본다. (잘 안알려진건 내가 모르니깐)
데이터 전처리
다른 ML들 처럼 데이터 전처리가 매우 중요하다.
데이터 가공과정 (예, 요약) 에서 중요한 키워드 등이 빠져버리면 이후의 모든 과정이 의미가 없어지기 때문이다.
RAG
원래 없는 데이터는 파인튜닝을 하는것이 정석이지만, 현재는 PEFT 를 써해도 파인튜닝 비용이 부담되는 것이 사실이므로 RAG 로 파인튜닝을 대체해서 쓰는 추세이다.
하지만 RAG 를 구현해봤다면 알겠지만 RAG 도 제대로 구현하는 것이 만만치 않다는 것을 알 것이다.
데이터 chunking 하는 방법, 임베딩 모델의 성능, 임베딩 검색방법 등 구현방법에 따라 여전히 잘못된 정보를 가져올 수 있다.
Re-rank
RAG 로 연관된 문서를 k 개 가져와서 사용하게 되는데, k+1 번째 데이터에만 정답이 들어 있다면
(최근 연구들에 의하면 컨텍스트를 일정개수 이상 주는 것이 큰 의미 없다고 한다, 특히 처음과 끝의 컨텍스트에 정답이 배치될 수록 성능이 좋다.)
컨텍스트 길이와 생성속도 때문에 k 개를 크게 줄 수 없는 경우가 많다.
벡터 데이터베이스에서 2~3배수의 문서를 가져오고, 해당 문서를 NLI (natural language inference) 또는 rerank 를 위한 모델(주로 샴 네트워크로 학습된 모델)로 해당 주제에 대해 re-rank 한 뒤, 상위 k 개로 추려서 사용한다.
일단 센텐스 임베딩을 통해 연관이 있는 것은 추려냈으니, 다른 메트릭을 통해 문서의 연관도를 재검증해본다는 아이디어이다.
리랭크는 위의 두 방식을 많이 쓰는거 같지만, 논문들의 특성상 변수제어 및 단순화를 위해서 그런 것 같다.
따라서, 프로덕션에서는 위의 방법에 BM25 라던가 일반 검색엔진에 쓰는 다양한 방식을 접목해서 시도 해볼 수 있을 것이다.
프롬프트 엔지니어링을 통한 검증 (Evaluation)
검증 기준
현재 모델이 생성한 대답을 사용해도 되는지 검증하는 기준은 크게 아래 2가지 인 것 같다.
신뢰도(faithfulness): 모델이 주어진 정보를 이용해서 답변을 생성했는지 여부
사실성(factuality): 모델이 생성한 정보가 사실인지 여부
먼저 신뢰도는 프롬프트 엔지니어링을 통해 모델이 자신의 결과에 대해, 주어진 문서들와 연관이 있는지를 스스로 판단하게 한다.
예를 들어, 벡테 데이터베이스에서 3개의 문서를 가져와서 추론했다면, 모델의 생성결과가 3개의 문서 모두와 관련이 있는지 각각 물어보고 (1개의 프롬프트에서) 모두 연관이 있으면 신뢰할 수 있다는 식이다.
할루시네이션의 정의를 생각해보면, 사실 여부는 LLM 이 판단할 수 없다. 따라서 외부데이터를 쿼리하는 과정이 반드시 필요하다.
이 데이터를 확보하고 사용하는 방법은 정말 여러가지인데, 검색엔진에 쿼리를 해서 결과개수를 확인하는 간단한 방법부터, 다양하고 복잡한 방법들이 있다.
검색을 위한 파라미터나 사용할 방법등은 ReAct 같은 방식으로 모델이 직접 만들어낼 수도 있지만, 여튼 사실성은 외부데이터를 통해 검증할 수 밖에 없다.
검증 방법
제대로 된 정보가 주어졌을때 질문에 대한 답을 추론(reasoning) 하는 능력이 중요하므로 결국 추론 능력이 좋은 모델을 사용하는 것이 중요하다.
13B 같이 상대적으로 작은 모델은 약간만 프롬프트가 복잡해져도 이상동작을 하기 때문에, 해당 동작을 제어하는데 시간이 많이 들어간다.
따라서 일단 큰 모델로 시작해서 모델을 작게 줄여나가는 방식이 개발 속도를 올릴 수 있다. 오픈소스 모델로 실험중이라면 together api 같은 서비스들이 큰 도움이 될 것이다.
여튼 추론 능력이 충분하다면, 먼저 프롬프트 작성시 Chain of thought 등을 사용하여 모델이 생각할 시간을 충분히 주고 결과를 생성하도록 한다.
이후 모델이 만든 대답을 few-shot example 을 주면서 스스로 검증할 수 있도록 유도한다.
검증 기준에서 설명한대로 검증은 신뢰도를 중심으로 검증하게 되고, 여력이 되면 사실성에 대한 검증도 하면 된다.
SelfCheckGPT
최근에 나온 논문 하나만 간단히 소개하고 마무리 해본다.
프롬프트 기반의 검증을 기존 BLEU, ROUGE 와 같이 좀 더 정형화 시킨 SelfCheckGPT3 라는 방식이다.
해당 논문에서 소개한 아이디어는 단순한데 효과적인 것 같다.
ICL (in context learning) 의 역할은 모델에서 정답 임베딩 위치를 가이드해주는 역할을 한다고 알려져 있다.
따라서 모델이 신뢰도가 있는 정보를 생성했다면 정답이 있는 영역을 잘 찾았다는 의미이므로, beam search 로 여러개의 답을 생성하더라도 일관된 내용을 말할 것이라는 가정을 할 수 있다.
이를 이용해, 여러개의 문장을 생성하고 모든 문장이 일관된 정보를 보여주는지 확인한다. 모델이 생성한 문장들을 일관된 문장과 아닌 문장의 비율을 F1 스코어처럼 계산하여 inconsistency 를 확인한다.
약간 더 디테일하게 소개하면 아래와 같은 과정으로 점수를 계산한다.
사용자의 질문에 대한 답을 beam search 로 n개 만든다.
가장 높은 확률을 가진 문장을 이용하여, 질문/답변을 생성한다.
나머지 문장들을 하나씩 이용하여 생성한 질문에 대한 답을 맞춘다.
답을 맞추면 mach, 못맞추면 mismatch 로 카운팅한다.
#mismatches / (#mismatches + #matches) 를 점수로 사용한다.
여기서는 QA 에 대해서만 소개했지만, 실제 논문에서는 n-gram, BERTScore, NLI 에서 SelfCheck 하는 방법들을 소개하고 있으므로 다른 워크로드를 처리하고 있다면 살펴보면 좋을 것 같다.
마치며
나는 머신러닝 엔지니어도 아니고 일때문에 빠르게 공부하고 사용해 본 내용만 적었기 때문에 모든 기법을 소개하지는 못했다.
현재도 방법들이 계속 나오고 있으며, 워크로드와 데이터별로 다양한 방법들을 적용해야 하므로 당분간은 한두가지 방법으로 통일되기는 어렵지 않을까 예상한다. (스테이블 디퓨전도 FID 가 제일 좋은 방법은 아닌거 같지만 딱히 다른 평가방법이 없는거보면…)
github ↩
Gentle introduction to hallucination in LLMs ↩
SelfCheckGPT: Zero-Resource Black-Box Hallucination Detection for Generative Large Language Models ↩

개발자를 위한 LLM 할루시네이션 제어방법들

댓글