Agent 실험 2 - 졌잘싸 with Agent Test

프롬프트Agent 를 어떻게 발전시킬 수 있을까?

Agent의 품질을 확보하려면, 현재 Agent 품질이 어느정도 보장되는지 먼저 확인해야한다고 생각했다. LangStudio 의 DataSet을 이용하면, Agent 를 쉽게 평가할 수 있다.

 

 

LangStudio 의 DataSet?
DataSet 의 구성은 입력과 출력으로 이루어져있다. 각각 TDD 의 given 과 then 이라고 생각하면 된다.  LangStudio 에 DataSet 을 등록해놓은 후, Prompt 버전이 변경될 때마다 테스트를 돌리면 된다. 테스트 결과를 수집하고, 품질 메트릭으로 평가를 자동화할 수도 있고, 이전 실행이나 버전과 비교할 수 있다. 

내가 이전 포스팅해서 진행했던 프롬프트 수정 → 평가 → 수정 → 평가의 과정이 덜 수고로워진다는거다. 다음 키워드가 전부 가능하다. 

* Unit Test

* Regression Test
* Evaluation Report

세상에 이렇게 좋은 툴이 있다니. 이걸 이용해 내가 만든 북 레터 생성 에이전트를 테스트해보기로 했다. 

Agent 를 어떻게 평가할 수 있을까? 

에이전트의 평가는 까다롭고, 애매하다. 결과가 매번 동일하지 않기 때문이다. 평가를 자동화할 수 있는 것이 있고, 자동화할 수 없는 것이 있다고 생각했다.

우선 다양한 에이전트 검증 방식들이다. 

1. Exact Match
   출력이 기대한 정답과 완전히 동일한 경우에만 정답으로 인정하는 방식
   ex) 
   - 기대값: "감성"
   - 모델 출력: "감성" → ✅
   - 모델 출력: "감성적인" → ❌

2. Human Evaluation(Human eval)
   사람이 직접 모델의 응답을 보고 자연스러움, 적절성, 유용성 등을 평가
   ex) 
   - “이 편지가 감성적인가요?”
   - “이 책 소개는 설득력 있나요?”

3. Rubric Scoring
   평가자 또는 시스템이 미리 정한 평가 항목별 체크리스트/점수표를 기준으로 채점
   LangSmith 는 채점 기준(Rubric) 을 지정하여 run_on_dataset() 평가 가능
   ex) 
   - 톤 일관성: 1~5점
   - 책 연결 자연스러움: 1~5점
   - 감정 몰입도: 1~5점

4. Embedding Similarity(임베딩 유사도) 
   모델 출력과 기대 응답을 벡터로 변환하여 유사도(cosine similarity 등) 측정
   표현이 같아도 의미가 같으면 높은 점수가 도출된다.
   ex) 
   * 기대 응답 : "지친 당신에게 위로가 되었으면 합니다"
   * 실제 응답 : "오늘 하루를 토닥여줄 책이 될 거에요" → 높은 유사도 점수


5. 평가자 채점(manual rating / human rubric)
   사람이 루브릭을 기준으로 점수화 Human Eval 과 Rubric 의 결합
    ex) 
   * 구조 완성도 : 4/5
   * 책-주제 일치도 : 3/5 → 높은 점수



이렇다고 한다면 내가 자동화 가능한 항목은 Exact Match 이다.
북레터 프롬프트 노드 중, detect_category 는 사용자가 입력한 키워드를 내가 제시한 항목 내에서 카테고리화한 부분이다. 

나올 수 있는 답변이 총 9개로 한정적이기 때문에, output 에 대한 검증도 100% 진행할 수 있다.

 

추가로 Embedding Similarity 도 자동화 평가 항목으로 추가할 수 있다. 북레터의 실제 결과와 기대값 사이의 유사도를 계산해볼 수 있었다. 

 

결과는 예상과 달랐다. category 정도는 내가 제시한 목록 내에서 뽑을 줄 알았다. 반면, 유사도는 제법 좋은 수치가 나왔다. 이것도 의외였다. 내 에이전트 특성상 자동화할 수 있는 항목은 생각보다 많지 않았다. 

수동 평가를 진행하려면 커스텀하게 evaluator 를 만들어야했다. 북 레터 에이전트의 경우 톤, 흐름, 감성 등은 Rubric 기반의 Human Eval로 평가하는 혼합 방식이 가장 이상적이라고 생각했다. 

수동 평가 항목 예: 인삿말 시작 여부, 『 책 제목 수, 문체 등

 

난잡하지만, 몇 개의 평가 기준을 넣어보았다. 이제 LangSmith evaluator로 사용하기 위한 포맷으로 정제하고 이전 자동 평가 루프에 끼워넣으면 된다. 

다양한 기준에 대한 평가를 한꺼번에 확인해볼 수 있다. 개별 프로젝트 상황에 따라 evaluate_letter() 함수처럼 직접 작성한 평가 로직이 들어갈 수 있다는 점을 확인했다. 

사실 string match 나 유사도 평가는 langSmith 에서도 자동 평가해주는 방법이 있다고 하지만, 나같은 경우 잘 동작하지 않아서 로직을 직접 구현한거다. 

일단 가장 적은 평가를 받은 category 개선을 위해 프롬프트를 수정하고 동일한 dataSet 으로 다시 테스트했다. 

정확도는 높아지지않았다. 이후로도 수 없이 프롬프트를 수정해보았지만, 수치는 여전했다.

LLM 응답은 다양성(variability)이 핵심인 시스템이다. 프롬프트 결과는 생성형이며, 열린 답변(open-ended)이 많기 때문에, 내가 프롬프트로 제한을 건다고해도 결과 값은 기대한 값과 100% 일치할 수 없다. 프롬프트 수행의 결과를 Exact Match 로 측정하는 것은 큰 의미가 없는 일 일지도 모른다. 내가 만든 로직이라면 if 문이라도 넣지.. 모델에게 내 심정을 주입시키고 싶었다. 방법은 fine-tuning 이었다.

지금까지 진행한 평가에서 우수한 애들을 먼저 선별하는 작업을 진행했다. category 가 매칭되고 유사도가 높은 케이스만 추리는 로직의 일부다. 이 과정을 라벨링 이라고 한다. 라벨링은 튜닝의 전제 조건이다.

지금까지 프로세스를 다시 짚어보았다.

1. 결과 판단 기준 정하기 (Evaluator)
2. 결과가 좋은 data set 골라내기 (Labeling)

그 다음은 좋은 결과로 다시 모델과 커뮤니케이션 하는거다. 바로 fine-tuning 이다. 

3. fine-tuning

먼저, 위 로직을 통해 선별된 케이스들만 따로 파일로 추출할 해두어야한다. 반드시 prompt, completion 필드가 존재해야한다.

우수 케이스가 판별되어 파일로 떨구어지면, 다음 명령어를 통해 튜닝을 준비할 수 있다. 해당 파일이 튜닝을 진행할 조건을 갖추었는지 판단해주는 명령어다. 

openai tools fine_tunes.prepare_data -f book_letter_fine_tuning_dataset.jsonl

통과한다면 아래 log 를 확인할 수 있다.

 

 

 

이제 튜닝하면된다! 현재 튜닝은 gpt-3.5 버전대만 허용하고 있다고한다. 

 

openai api fine_tuning.jobs.create -t book_letter_fine_tuning_dataset_prepared.jsonl -m gpt-3.5-turbo-1106

튜닝에 실패했다. 알고보니 GPT-3.5-turbo fine-tune 케이스의 경우 별도의 beta 접근권 + 사전 등록이 필요하고 일부 계정만 허용하고 있다고 한다. 

튜닝을 하더라도 문제가 하나있다. 나는 다음과 같은 과정을 거치려고 했다. 

Run → 평가 → 라벨링 → 튜닝 → 다시 Run

 

근데 이럴려면 막대한 양의 테스트 케이스가 필요하다. 질 좋은 expected output 도 필수다. 여기에는 사람이 개입해야한다. 나 혼자 이 막대한 데이터를 만들어낼 수 있을까?

 

동일한 키워드로 chatGPT 와 내 에이전트를 비교해보았다. 

이럴 거 같으면 그냥 chatGPT 를 쓰지. chatGPT 가 생성하는 콘텐츠의 질은 어떻게 이렇게 높은걸까? OpenAI, Anthropic, Google 이 만든 AI 서비스들은 결국 실제 사람이 모델을 평가한다고 한다. 직접 만들어보니 dataSet의 input 도, 기대하는 output 값도 잘못 세팅하면 에이전트 평가 자체가 무의미해질 수 있었다. 다행히도(?) 아직 인간의 개입은 필수인 것으로 보인다. ChatGPT 와 내 에이전트의 퀄리티 차이는 리소스 뿐만이 아니다. AI 서비스들은 이미 엄청난 양의 데이터를 소유하고 있다. 데이터로 더욱 정교한 모델을 학습시키고, 그 모델은 더 좋은 출력을 만들어낸다. 그리고 이 출력은 다시 '데이터'로 수집된다. 이렇게 고리를 한 바퀴 돌릴 때마다, 그들의 데이터 자산은 더 정교하고 더 가치 있게 진화한다. 부익부 빈익빈이다. 

 

좋은 데이터 → 좋은 모델 → 더 좋은 데이터 → 더 정교한 모델

 

이 고리는 간단하면서도 잔인하다.  이 사이클은 자원을 가진 자에게 유리하게 설계되어 있다.  데이터를 수집할 수 있는 플랫폼, 평가할 수 있는 인력, 실험을 반복할 수 있는 자본.  이 모든 것이 갖춰졌을 때, AI는 진짜 나이스한 결과를 낼 수 있다.

근데.. 나는...? 우리는?  프롬프트를 조금씩 바꾸고, 손으로 하나씩 라벨링하고, 결과를 눈으로 확인한다. 너무나 느리고, 너무나 작다. 하지만 분명한 것은 이 조그만 실험도 분명히 학습이 된다는 거다. 부익부 빈익빈은 피할 수 없지만 작은 실험과 관찰, 명확한 평가 기준을 쌓는 것은 여전히 우리의 몫이다. 이게 우리가 에이전트를 '키운다'고 부를 수 있는 이유이지않을까? 아이러니하게도, AI 데이터는 성실한 반복에 반응한다.

 

 

사실 핵심(내 사업구상)은 이거다. AI가 필요로 하는 것을 내가 제공할 수 있다는 것.

 

AI가 성장하기 위해 필요한 건 데이터다. 내가 입력하는 프롬프트, 내가 남긴 평가, 내가 만든 라벨링… 이 모든 것이 AI에게는 먹이가 된다. AI는 그 데이터를 기반으로 더 똑똑해지고, 더 정교한 콘텐츠를 만들어낸다. 그 과정에 기여한 나의 지분율은 몇 퍼센트일까? 0.000000001%일지라도, 분명 내 손길이 닿아 있다면 그 가치를 돌려받을 수 있다면 어떨까?

 

유튜브는 누구나 동영상 콘텐츠를 만들 수 있고, 그 콘텐츠에 붙은 광고 수익을 창작자에게 되돌려주는 구조를 만들었다. 수많은 창작자들이 몰려들고, 플랫폼은 성장했고, 콘텐츠는 폭발적으로 쌓였다. AI에게 데이터를 제공한 사람에게 기여도 기반의 보상 모델을 설계할 수 있다면, 데이터 전쟁의 승자는 단순히 크롤링을 잘하는 쪽이 아니라 더 많은 사람들의 자발적인 참여를 이끌어낸 플랫폼이 될 것이다. 더 좋은 질문을 하려고 사람도 노력할거고 그럼 더 좋은 답변이 나올거다. 현문현답은 AI 도 마찬가지니까. 이게 어쩌면, AI 시대의 유일한 ‘크리에이터 이코노미’일지도 모른다. AI 가 내 일자리를 빼앗아가지 못할 것이라는 희망회로 끝.