Skip to main content

LLM 시스템을 평가, 비교 및 최적화하는 방법

이 글에서는 대규모 언어 모델(LLM) 시스템을 평가하는 방법과 하이퍼파라미터를 최적화하는 방법에 대해 대화식으로 살펴보겠습니다.
Created on May 1|Last edited on May 30
ChatGPT(솔직히 말하자면 에이전트에 가깝습니다)와 GPT4 (순수한 LLM, 하지만 아무도 모르죠!)의 공개 이후 대규모 언어 모델(LLM)의 영역이 폭발적으로 늘어났습니다. 앞으로 더 많은 발전과 더불어 내부적으로 LLM을 사용하는 시스템(도구, 봇, 서비스 등)도 더욱 발전할 것입니다.
아직도 많은 예제는 장난감 같은 사례이거나 데모, 또는 개념 증명에 불과합니다. 바로 지금, 소수의 LLM 시스템만이 생산 단계에 있으며, 아마도 가장 큰 장애는 그러한 시스템에 대한 신뢰할 만한 평가일 것입니다.
의료 QA 봇의 간단한 예를 생각해보죠. 진단명(질의)을 입력하면, 시스템이 복용량과 함께 약품을 추천할 것입니다(응답). 이러한 시스템은 의료 데이터베이스에서 정보(컨텍스트)를 검색하고, 해당 컨텍스트와 쿼리(프롬프트)를 수집 분석한 다음, 최종적으로 LLM을 사용하여 응답을 만들어냅니다.
하지만 해당 응답이 정확한지는 어떻게 확인할 수 있을까요? 결국, 의료 분야에서 사용하는 경우, 이를 올바르게 만드는 것이 중요합니다. 허위 양성이나 음성의 결과가 생명에 치명적인 결과를 초래할 수 있습니다.
그러면 이와 같은 LLM 시스템을 어떻게 평가할 수 있을까요? 이 글에서는 다음에 대해 알아봅니다:
  • LLM 기반 시스템에 대한 개념으로서의 평가를 살펴봅니다. 간단한 예로 시작한 다음 여기에서 시스템 평가를 구축하고, QA 문서를 작성합니다.
  • 또한 더 조율이 잘된 LLM 기반 시스템을 찾기 위해 하이퍼파라미터 최적화(HPO)를 활용하는 방법을 자세히 알아볼 것입니다.
이 보고서가 마음에 들고 LLM 앱을 개발 중이시라면, 아래 버튼을 클릭하여 가입하실 수 있는 무료 과정도 있습니다.
무료 LLM 과정에 가입하기


이 글에서 자세히 다룰 내용은 다음과 같습니다:

목차



여기에서 코드를 시험해 보세요 \rightarrow

직관적 LLM 평가

LLM을 평가하는 것과 LLM기반 시스템을 평가하는 것에는 차이가 있습니다. 오늘날의 대규모 언어 모델은 다중 작업을 수행할 수 있습니다. 텍스트를 요약하고, 질문과 답변을 하며, 텍스트의 감정을 파악하고, 번역을 수행하는 등 많은 작업을 할 수 있습니다.
보통 사전학습 (일반적으로 거대 데이터 집합에 대한 것) LLM은 표준 척도를 사용하여 표준 벤치마크 즉, GLUE, SQuAD 2.0, SNLI 등에 대해 평가됩니다. 하지만 이러한 LLM은 우리에게 유용하지 않을 수도 있습니다. 다음은 그 이유입니다.
  • 특정 사용 사례를 위해 LLM을 “비공개” 데이터 집합에 맞게 미세 조정해야할 수도 있습니다. 이러한 경우, 평가는 보통 직관적입니다. 대부분 표준 척도를 사용하는 미세 조정 모델을 평가할 때 참값 데이터 집합을 이용합니다. 하지만, 미세 조정은 값비싸고 시간이 오래 걸린다는 점에서 우리가 고려해야 할 첫 번째가 아니어야 합니다. 위의 사례를 계속 살펴보자면, 특별한 LLM 아키텍트에는 이용할 수 없는 환자 데이터 또는 의료 연구를 바탕으로 의료 시스템을 미세 조정하게 될 수도 있습니다.
  • LLM은 강력하지만, 잘 계획된 사전/사후 엔지니어링이 있어야 합니다. 많은 경우에 충분히 성과가 좋은 LLM 기반 시스템을 빌드할 수 있습니다. Langchain, LlamaIndex 등과 같은 도구 덕분에 이러한 시스템을 빌드하는 것이 한층 쉬워졌습니다. 하지만, 올바른 구성 요소(추후 논의)를 찾고 시스템을 적절하게 평가하는 일은 여전히 까다롭습니다.
다음은 몇 가지 직관적인 평가 방법입니다. 그 중에서도 가장 직관적인 것으로 시작해보죠.

1. 아이볼링(Eyeballing)

LLM 기반 시스템을 빌드하기 시작할 때, 우리는 보통 시스템의 응답을 응시하는 것으로부터 평가를 시작합니다. 보통 몇 가지 입력을 하고 예상 응답을 받으며, 다양한 구성 요소, 프롬프트 템플릿 등을 시도함으로써 시스템을 튜닝하고 빌드합니다. 이렇게 함으로써 개념에 대한 좋은 증거가 생기지만, 시스템은 철저하게 평가해야 합니다.
이 워크플로를 지원하려면, W&B Prompts를 사용하도록 권장합니다. 실제로 Langchain 또는 LlamaIndex를 사용한다면, 프롬프트를 바로 사용할 수 있습니다. 또한 귀하의 체인/플러그인을 프롬프트와 함께 설치할 수도 있습니다.
다음에는 LlamaIndex를 사용하여 간단한 문서를 쿼리하는 사례가 있습니다. 워크플로에 아이볼링이 도입되는 경우, 이러한 도구를 통해 이면에서 어떤 일들이 일어나는 지 알 수 있습니다. 이 프롬프트 사례 주변을 자유롭게 클릭해 보십시오. 이것은 인터랙티브합니다:

Success
startTime
Timestamp
Input
Output
Chain
Error
Model ID
3
2
1
5
query
4346ms
synthesize
4138ms
llm
4115ms
retrieve
208ms
embedding
201ms
Click and drag to pan
query
4346ms
Result Set 1
Inputs
query_str
What did the author do growing up?
Outputs
response
The author grew up writing essays, learning Italian, exploring Florence, painting people, working with computers, attending RISD, living in a rent-stabilized apartment, building an online store builder, editing Lisp expressions, publishing essays online, writing essays, painting still life, working on spam filters, cooking for groups, and buying a building in Cambridge.
Metadata
Kind
AGENT
Start Time
Thu Jun 08 2023 11:47:52 GMT+0000 (Coordinated Universal Time)
End Time
Thu Jun 08 2023 11:47:56 GMT+0000 (Coordinated Universal Time)
Child Spans
2

2. 사람이 다는 주석, 또는 감독 평가

LLM 시스템을 평가하는 최고이자 가장 신뢰할 수 있는 방법은 LLM 기반 시스템의 각 구성 요소에 대해 평가 데이터 집합을 만드는 것입니다. 이러한 접근법의 가장 큰 단점은 그러한 데이터 집합을 만드는 데 드는 비용과 하나를 만드는 데 걸리는 시간입니다. LLM 기반 시스템에 따라서, 평가 데이터 집합의 설계가 까다로울 수 있습니다.
새로운 데이터 집합을 만드는 데 의문을 가지고 왜 표준 벤치마크를 사용하지 않는지 의아해 하실 수 있습니다. LLM 기반 시스템의 빌드에 대한 아이디어는 그것을 미세 조정하지 않고 비공개 데이터를 LLM에 가져오는 것입니다. 이상적으로는 시스템을 비공개 데이터 또는 '도메인'에서 평가하고자 할 것입니다.
간단한 LLM 기반 시스템인 계산기를 예로 들어보죠. 계산기는 BODMAS 규칙을 사용하여 주어진 수식을 풀 수 있습니다(재미있는 사실: 이는 또한 PEMDAS나 BEDMAS 규칙으로 알려져 있습니다. 출신 지역에 따라 부르는 명칭이 다릅니다).

계산기 또는 간단한 LLM 기반 시스템

계산기는 괄호, 기호 등이 있는 수학적 수식을 사용할 수 있습니다. 기본 LLM (예: GPT4)을 사용하여 계산하고 답변을 반환합니다. Langchain을 사용하면 몇 줄의 코드로 빌드할 수 있습니다.

감독 평가

놀랍게도, GPT4는 시스템에 대한 적절한 조율이 없는 경우 수식을 정확하게 풀 수 없음이 여러 차례 드러났습니다. 이는 곧 다음과 같은 질문을 던지게 합니다. 평가를 논하기 전에, 우리가 조율할 수 있는 다양한 것들은 무엇입니까?
다양한 LLM ( gpt-4, gpt-3.5-turbo, 등)으로 실험하고, 다양한 프롬프트로 실험하며, API에 제공된 인수(온도와 같은)를 약간 변형하는 등의 추가 시도를 할 수 있습니다. '추가'는 빌드하고자 하는 시스템에 따라 달라집니다.
또한 아이볼링 기법을 사용하여 무턱대고 튜닝을 시도해볼 수도 있습니다. 하지만, 이전에 언급한 바와 마찬가지로, 시스템을 생산으로 유도하는 데 필요한 확신을 주지는 않을 것입니다. 우리의 계산기 예에서, 수식을 평가하는 데 파이썬(Python) 함수를 사용했으며 이를 '사람이 주석을 단 평가 데이터 집합'이라고 부릅니다. (그렇습니다, 이것은 시뮬레이션된 데이터이지만, 그 목적은 관련 데이터를 수집함으로써 그러한 시스템을 평가하는 방법을 보여주기 위한 것입니다.)
아래의 W&B Table는 사람이 주석을 단 평가 데이터(우리의 경우 파이썬 함수를 사용하여 생성된)인 true_result를 보여주는 한편, pred_result는 LLM 계산기가 계산합니다. 또한 토큰의 수와 그 응답을 생성하는 데 드는 비용을 기록합니다.
Langchain을 사용하면 토큰 사용량과 비용을 추적할 수 있습니다. 하지만, 이는 현재 OpenAI API에 대해서만 실행됩니다.
💡

expression
true_result
pred_result
LLM Prompt Tokens
LLM Completion Tokens
LLM Total Tokens
LLM Total Cost (USD)
Parsing Prompt Tokens
Parsing Compeltion Tokens
Parsing Total Tokens
Parsing Total Cost (USD)
1
2
3
4
5
사용 사례와 이러한 평가 데이터 집합의 이용 가능성에 따라, 사용 사례에 대해 가장 타당한 척도만 선택할 수 있습니다. 이 예에서, 정확도는 충분히 좋습니다. 아래에서 106개의 예측 생성 비용과 함께 평가 데이터 집합을 기반으로 한 LLM 계산기의 정확도를 볼 수 있습니다.
물론, LLM 기반 계산기의 성능을 향상시킬 수 있습니다. (사실, 여기서 잠시 후에 그렇게 할 것입니다.)



하이퍼파라미터 최적화

평가 데이터 집합이 있고 변형할 다수의 구성 요소가 있다면 하이퍼파라미터 최적화를 설정하는 것이 당연합니다. W&B Sweeps를 사용하는 것이 상당히 직관적입니다. 0-1의 범위에서 3개의 다른 프롬프트 템플릿, 3개의 모델( text-davinci-003, gpt4, gpt-3.5-turbo) 그리고 온도를 사용할 것입니다.
참고: 온도는 우리 모델의 응답이 얼마나 '창의적'일지를 조절하는 파라미터입니다. 온도를 낮게 하면 무작위성이 낮아지고 덜 색다른 결과를 산출합니다. 온도를 높이면 더욱 다양한 콘텐츠를 생산할 뿐만 아니라 가능성을 높여 우리의 모델이 컨텍스트에서 약간 벗어나게 됩니다.
💡
우리가 시도할 다양한 프롬프트 템플릿은 다음과 같습니다:
  1. maths_prompt_template_1.txt
The following is the mathematical expression provided by the user.
{question}

Find the answer using the BODMAS rule in the {format_instructions}:
2. maths_prompt_template_2.txt
The following is the mathematical expression provided by the user.
{question}

Find the answer in the {format_instructions}:
3. maths_prompt_template_3.txt
You are an expert mathematician. You can solve a given mathematical expression using the BODMAS rule.
BODMAS stands for Bracket, Orders of Indices, Division, Multiplication, Addition and Subtraction. The computation should happen in that order.
The dorder is as follows:
B: Solve expressions inside brackets in this order -> small bracket followed by curly bracket and finally square bracket.
O: Solve the indices such as roots, powers, etc.
D: Divide the numbers which are given
M: Multiply the numbers next
A: Sum up the next numbers
S: Subtract the numbers left in the end

The following is the mathematical expression provided by the user.
{question}

Think about it step-by-step. Don't skip steps.

When ready with the answer return in the {format_instructions}:
보시는 바와 같이, maths_prompt_template_2.txt는 'BODMAS' 규칙에 대한 어떠한 언급도 없는 가장 단순한 프롬프트입니다. 우리는 maths_prompt_template_1.txt 템플릿에서 'BODMAS'를 언급합니다. 최종 프롬프트 템플릿인 maths_prompt_template_3.txt에서 상세한 지침을 제공합니다.
저는 random 전략을 사용하여 50번의 실행 시 최적화를 실행했습니다. 다음은 관찰의 일부입니다:

Run set
44


관찰

  1. 정확도 대역에는 세 가지가 있습니다: - 낮음 (10-40%), 중간 (60-70%), 그리고 높음 (88%+). 이 세 가지 대역은 비용과 함께 양의 상관관계가 있습니다. 더 많은 돈을 지출함으로써 더 높은 정확도가 달성됩니다.
  2. GPT4가 모두를 지배합니다. GPT4 모델이 가장 높은 정확도를 보여줍니다.


3. GPT4는 훌륭하지만, 정확하게 프롬프트를 해야 합니다. 프롬프트 템플릿 3은 ~90%의 정확도를 보여주지만, 프롬프트 템플릿 1은 60-70%의 정확도를 나타냅니다. 이는 시스템 성능이 20% 이상 개선된 것입니다. 우리의 예에서, LLM에 더 많은 지침을 줄 수록 더 좋은 결과가 나왔습니다.


4. 좋지 않은 모델을 사용하면 결과가 나빠집니다. 프롬프트 템플릿 text-davinci-003이 잘 수행되는지에 상관없이, 20% 미만의 정확도가 나옵니다. 심지어 gpt-3.5-turbo가 잘 수행되지 않을 경우 그렇습니다(40%미만의 정확도).


가장 높은 정확도는 가격에 따라 결정됩니다. 예상한 바와 같이, gpt4 는 더욱 상세하고 간결한 프롬프트 템플릿을 사용하여 최고의 성과를 보입니다. 그 결과는 단순한 LLM 기반 시스템에서는 예상한 바와 같지만, 다소 복잡한 시스템에 대해서는 그렇지 않을 수도 있습니다.
만약 평가 데이터 집합을 구축하는 데 시간과 돈을 쓸 수 있다면, 그러한 데이터 집합에 대해 평가된 LLM 기반 시스템을 배치할 때 가장 높은 확신을 주게 될 것입니다. 이는 LLM 기반 시스템을 평가하는 가장 방법론적으로 안정된 방법입니다.
💡

LLM 평가

여기에서 코드를 시험해 보세요 \rightarrow

LLM은 다재다능하며 흥미로운 특징을 보여줍니다. 특히 제공된 텍스트에서 정보를 추출하는 데 능숙하며, 더 나아지고 있습니다. 이러한 특징의 결과 LLM을 평가하는 데 LLM을 사용하는 방법으로 발전했습니다. 핵심 아이디어는 LLM을 이용하여 테스트 사례를 생성한 다음 그것에 대해 LLM 기반 시스템을 평가하는 것입니다.
우리의 LLM 기반 시스템은 이 섹션에서 검색 증강(Retrieval Augmented) QA 봇이 됩니다. 이러한 시스템에는 몇 가지 구성 요소 즉, 임베딩 모델, 검색 시스템, LLM이 지원하는 QA 체인이 있습니다. 데이터와의 LangChain 채팅 Deeplearning.ai 과정에서 이러한 시스템의 빌드 방법에 대해 더 자세히 알아보실 수 있습니다.
이 QA 봇은 '자기 감독 학습의 쿡북(The Cookbook of Self-Supervised Learning)' (arXiv:2304.12210)이라는 제목의 논문을 기반으로 질문에 답하도록 빌드되었습니다. 이러한 시스템의 평가를 시작해보죠. 먼저, 평가 데이터 집합이 필요하고 척도를 결정해야 합니다.

1. LLM을 사용하여 평가 데이터 집합 생성하기

QA 봇을 실제 평가하려면 평가 집합에 질문과 답변의 쌍이 필요합니다. 우리의 봇이 정보 검색(IR) 시스템을 이용하므로, 또한 그것에 대한 평가도 고려해야 합니다(나중에 자세히 다룸).
이전 섹션에서 설명한 바와 같이, 주석을 다는 사람을 고용하여 질문과 답변의 표준 쌍을 수작업으로 만들 수 있습니다. 이는 전체적으로 훌륭한 방법이지만, 비용이 들고 시간 소모적입니다. 결국, 의료 데이터에 대해 QA 봇을 위한 평가 집합을 구축하려면 훈련 받은 사람이 필요합니다.
수 많은 틈새 사용 사례의 경우, 즉 간단한 크라우드 소싱이 잘 이루어지지 않고, 전문가가 있어야 나아지는 경우라면, 올바른 인재를 찾기가 어렵고, 결국 이는 높은 비용으로 이어지며 개인 및 소기업에게는 실현 불가능한 일이 되어 버립니다. 이러한 데이터 집합을 만드는 한 가지 타당한 방법은 LLM을 활용하는 것입니다. 이러한 접근법에는 명백한 장점과 한계가 있습니다.
  • 확장 가능합니다. 요구에 따라 방대한 수의 테스트 사례를 만들 수 있습니다.
  • 유연합니다. 특별한 에지 사례에 대해 테스트 사례를 만들 수 있으며, 다수의 영역에 적용함으로써 타당성과 적용 가능성을 보장합니다.
  • 저렴하고 빠릅니다. LLM은 훨씬 더 낮은 가격으로 다수의 문서에서 정보를 신속하게 수집 분석할 수 있습니다.
한계의 경우, 위에서 가장 큰 내용을 다루었습니다. 전문 라벨러가 필요한 사용 사례는 가장 자주 원하는 사용 사례입니다(즉, 의�� 분야).

Langchain의 QAGenerationChain

Langchain은 QAGenerationChain이라고 불리는 유용한 체인을 보유하고 있습니다. 이 체인은 특정 문서에서 질문과 답변의 쌍을 추출할 수 있습니다. 관련 데이터 로더(Hamel의 훌륭한 작품, 여기에서 이용 가능)를 사용하여 문서를 로드할 수 있습니다. 이를 더 작은 덩어리로 나눈 다음, 체인을 사용하여 QA 쌍을 추출합니다.
저는 이 프롬프트를 사용하여 QAGenerationChain을 통해 QA 쌍을 만들었습니다. 60개의 쌍을 만들었으며, 이 중 45개는 gpt-3.5-turbo를 사용하여 만들었고, 나머지 15개는 Cohere의 command 모델을 사용하여 만들었습니다.
You are a smart assistant designed to come up with meaninful question and answer pair. The question should be to the point and the answer should be as detailed as possible.
Given a piece of text, you must come up with a question and answer pair that can be used to evaluate a QA bot. Do not make up stuff. Stick to the text to come up with the question and answer pair.
When coming up with this question/answer pair, you must respond in the following format:
```
{{
"question": "$YOUR_QUESTION_HERE",
"answer": "$THE_ANSWER_HERE"
}}
```

Everything between the ``` must be valid json.

Please come up with a question/answer pair, in the specified JSON format, for the following text:
----------------
{text}
아래에 생성된 QA 쌍을 확인하십시오. 두 모델 모두에서 생성된 QA 쌍을 훑어 보십시오. 생성 품질에서 차이를 찾을 수 있습니까?


질문과 답변의 어조를 변경하고, 세부 사항에 좀 더 많거나 적은 주의를 기울이고, 부정적인 답변을 만드는 등의 다양한 프롬프트로 실험해볼 수 있습니다. 이러한 접근법의 가장 좋은 부분은 이러한 접근법이 광범위한 사용 사례 집합에 대해 더욱 타당해짐으로써 LLM이 시간이 지남에 따라 개선된다는 것입니다.

2. 척도

이제 QA 쌍의 평가 집합을 보유하고 있으므로, 우리의 LLM 기반 QA 봇이 질문에 대한 예측을 생성하도록 할 수 있습니다. 그 다음 척도를 사용하여 예측된 것과 '사실'인 답변을 평가할 수 있습니다.

1. 척도로써의 LLM?

예측된 답변과 '사실'인 답변이 주어지면, 우리는 그야말로 LLM을 사용하여 예측이 사실인 답변과 얼마나 잘 비교되는지 알아볼 수 있습니다! 계속: LLM은 이제 텍스트의 의미를 잘 이해하므로 강력합니다. 두 개의 텍스트(사실과 예측된 답변)가 주어지면, LLM은 이론적으로 그 둘이 의미론적으로 동일한지를 파악할 수 있습니다. 만약 동일하면, 그 예측에 '정확' 라벨을 줄 수 있고, 그렇지 않으면, '부정확' 라벨을 줄 수 있습니다.
다행히도, Langchain에는 QAEvalChain이라는 체인이 있습니다. 이 체인은 예측된 답변과 함께 질문과 '참' 답변을 받아들이고 그에 대한 '정확' 및 '비정확' 라벨을 출력할 수 있습니다. LLM이 척도로 사용된 하나의 평가 작업으로 아래 W&B Table을 확인해보세요( llm_based_eval_acc).



2. 표준 척도

NLP 작업으로써, 질문-답변에는 몇 가지 주된 척도와 함께 풍부한 문헌이 있습니다. SQuAD를 포함하여 다양한 QA 벤치마킹 데이터 집합에 사용된 두 가지의 주된 척도는 다음과 같습니다:
  • 정확한 일치: 각 질문-답변 쌍에 대해, 만약 모델 예측의 토큰이 사실인 답변의 토큰과 정확하게 일치한다면, exact_match는 100이고, 그렇지 않다면, exact_match는 0입니다. 각 토큰 매칭이 확률론적 시스템에서 드물게 일어날거라고 생각할 수 있습니다. 이 척도는 우리의 사용 사례를 감안해야 합니다.
  • F1 스코어: 이것은 잘 알려진 척도로 시스템의 정밀도와 기억력을 동등하게 취급합니다. 정밀도는 예측에서 전체 토큰 수에 대한 공유된 토큰의 비율입니다. 기억력은 참값(ground truth)에서 전체 토큰 수에 대한 공유된 토큰의 비율입니다.
우리는 HuggingFace의 Evaluate 라이브러리를 사용하여 squad 척도를 로드하고 exact_matchf1을 계산할 수 있습니다. 위의 동일한 평가 작업에 대해, 아래�� 샘플 당 기준으로 exact_matchf1 스코어를 확인하십시오.



하이퍼파라미터 최적화

평가 집합이 있다고 할 때, W&B Sweeps를 사용하여 척도를 개선하게 될 하이퍼파라미터 최적화 검색 구성 요소를 신속하게 설정합니다. 이 경우: 평균 F1 스코어입니다. 저는 다음 스윕 구성을 사용했습니다:
method: random
name: random_qa_full_sweeps
parameters:
embedding:
values:
- SentenceTransformerEmbeddings
- OpenAIEmbeddings
- CohereEmbeddings
llm:
values:
- gpt-4
- gpt-3.5-turbo
- text-davinci-003
- command
- command-light
prompt_template_file:
values:
- data/qa/prompt_template_1.txt
- data/qa/prompt_template_2.txt
retriever:
values:
- Chroma
- TFIDFRetriever
- FAISS
program: qa_full_sweeps.py
보시다시피, 저는 몇 가지 임베딩 모델, 다양한 LLM (OpenAI의 GPT 계열 모델과 Cohere의 Command 계열 모델), 프롬프트 템플릿 및 몇 가지 리트리버로 실험을 하고 있습니다. 프롬프트 템플릿 2는 프롬프트 템플릿 1을 약간 수정한 것입니다. 주목해야 할 다른 것은 TFIDFRetriever가 임베딩 모델을 사용하지 않는다는 것입니다(당연한 것이지만요).

Run set
65


관찰

  1. OpenAI 모델이 Cohere 모델보다 더 나은 성능을 보여 줍니다. 상위 F1 스코어(50+)는 OpenAI 모델 계열에서 나옵니다.


2. TFIDFRetriever는 임베딩 기반의 Chroma와 FAISS에 비해 놀라울 정도로 잘 작동합니다. TFIDFRetriever는 어떠한 임베딩 모델도 사용하지 않으므로, 이 리트리버는 성능 저감없이도 비용을 줄일 수 있습니다.




3. gpt-3.5-turbo는 전체적으로 gpt4보다 더 나은 성능을 보여주는 것 같습니다. 이것은 평가 집합이 gpt-3.5-turbo를 사용하여 생성되었기 때문일까요? 이는 해당 평가 전략에 대한 추가 조사를 요구하지만 또한 gpt-4가 얼마나 강력한지를 보여주는 것이기도 합니다.
아래의 체크 상자를 클릭하여 해당 모델에 대한 실험을 선택하십시오. 결과적인 F1 스코어는 실험 전체에서의 평균값입니다.

gpt-3.5-turbo
6
gpt-4
10

4. gpt-4에 대한 F1 스코어가 낮은 까닭은 프롬프트 템플릿 2때문입니다. 이는 정확한 프롬프팅이 얼마나 중요할 수 있는지를 보여줍니다.



평가 전략에서 무엇을 개선할 수 있나요?

위의 관찰을 기준으로 할 때, 평가 전략을 개선할 수 있는 방법에 대해 생각해볼 수 있습니다.

검색 시스템을 별도로 평가하는 것은 어떻습니까?

정보 검색(IR)은 QA 파이프라인에서 중대한 단계입니다. 위에서 제안된 평가 전략은 파이프라인 전체를 평가합니다. 우리는 개별 시스템을 평가할 방법이 필요합니다.
문서 청크(chunk)를 사용하여 질문과 답변의 쌍을 생성하는 한편, 해당 청크(원래의 사실)는 그 쌍과 함께 저장되어야 합니다. IR 시스템은 평가 중 주어진 질문에 대해 상위 k 청크를 선택합니다. 원래 사실이 선택된 청크에 있는 경우 해당 리트리버에 대한 스코어가 결정됩니다. 또한 이 스코어는 선택된 청크의 원래 사실의 순위에 따라 달라집니다.
별도의 리포트에서 작업을 통해 이것을 보여드리겠습니다.

결론

LLM 기반 시스템의 평가는 여전히 개발 초기 단계에 있으며, 수 많은 연구와 도��� 개발이 진행 중입니다. LLM은 여기에 있고, 많은 문제문이 일부 역량에서 LLM을 활용하기 시작할 겁니다. 이 리포트가 LLM 기반 시스템의 평가에 대한 중요성을 일깨우게 되길 바랍니다. 또한 LLM 기반 시스템 평가에 대한 몇 가지 실용적인 방법을 보여주었기를 바랍니다.
LLM을 평가하는 LLM이 '점진적으로' 일반적인 프랙티스가 될 것이라고 생각하지만, 좀 더 진전이 이루어져야 합니다. 시스템을 평가하는 가장 체계적인 방법은 사람이 생성한 평가 집합을 사용하는 것입니다. 아마도 하이브리드 평가 전략을 보게 될 수도 있습니다. 먼저, LLM을 사용하여 다른 LLM을 평가하고, 일부 역량에 해당 시스템을 배치한 다음, 사람으로부터 실제 데이터를 수집하게 될 겁니다. 그 다음 더욱 실제에 가까운 테스트 사례로 평가 집합을 업데이트하게 됩니다.
이 게시물을 즐겁게 읽으셨길 바랍니다. 질문이나 제안이 있으시면, 아래 의견란에 적어 주시거나@ayushthakur0로 연락하여 주시기 바랍니다.

관련 자료


Iterate on AI agents and models faster. Try Weights & Biases today.
List<wb_trace_tree>
File<(table)>