어떻게 하면 LLM이 내가 원하는 역할을 잘 수행할까?

이번 프로젝트에서 STT→LLM(에이전트)→TTS 구조의 AI진행자를 설계하고, 관련하여 개발하는데에 있어서 해당 LLM이 ‘진행자스러움’이 부족함을 뼈저리게 깨닳았다.

어떻게 해야 이 한계를 극복하고, LLM이 더 Role에 집중할 수 있도록 만들 수 있을까?

1. 프롬프트 엔지니어링(여유로운 전체적인 구조 설계)

프롬프트 엔지니어링은 LLM의 추론 과정을 설계한다. 이 부분은 LLM이 작동함에 있어 큰 영향을 끼친다.

현재 우리 프로젝트의 프롬프트 엔지니어링은 기본적으로 다음과 같이 진행된다,.

SYSTEM_PROMPT = """
AI의 역할을 설명.
AI가 지켜야할 내용을 설명:

1. 진행 스타일:
	- 관련 스타일 을 설명
	- 지켜야할 내용을 설명
	
2. 대화 연결 로직:
	- AI가 대화 어떻게 답해야할지 로직을 설명
	- "예시"와 같이 이야기하세요 등.

3. 개입 타이밍:
	- ~말 이후 발화하세요.
	- ~상황에서 이야기하세요

"""

그러나 위와 같은 프롬프트 엔지니어링에선 한계가 명확했다.

1. 진행자스럽지 못한 발화: AI는 단순 LLM처럼 길고 장황하게 설명할 뿐이며, 전혀 진행하지 못했다.
2. 개입 타이밍의 의미: 사실상 LLM은 대화를 받고, 받은 내용에 대해 바로 결과를 출력하므로 의미 없는 부분이 되었다.
3. 너무 긴 발화: 내용이 너무 길고, 호응만 요구하는 경우에도 호응하지 못했다.
4. 질문이 들어가야할 타이밍에 빠르게 음성이 나가지 못했다.

위와 같은 한계점에서 바뀌어야 할 것은.

1. 개입 타이밍은 시스템 적으로 제어하고, TTS로의 전환까지 완료된 내용을 태그와 함께 저장하고, 에이전트로 적절한 타이밍에 출력한다.
2. 답이 필요 없는 부분이나, 사람이 대화를 이어나가야 하는 부분에선 호응하도록 프롬프트를 조정한다.
3. AI의 질문이나 답이 필요한 부분에서 짧고, 지루하지 않도록 길이를 조정하도록 프롬프트를 설계한다.
4. 위와 같은 조정이 잘 적용되도록 하는 로직이 추가적으로 필요하다.

여기서, 1~3번은 프롬프트, 알고리즘 구조의 수정으로 할 수 있는데 반해, 4번에서 내가 해야할 내용이 명확했다.

프롬프트 상에서의 제어

1. Chain-of-Thought 강제 및 구조화
   • 답변 출력 전에 생각하는 단계를 추가적으로 집어넣는 방식을 넣는다.

   4. 자기 비판:
   - 답변을 출력하기 전에 다음 단계로 생각해 보시오.:
    1) 사용자의 의도 분석, 2) 관련 지식 검색 전략 수립, 3) 제약 검토, 4) 최종 답변 구성

2. 가상 인터페이스 설계
   • 명확한 JSON구조의 답변을 요구하여 LLM이 스스로 답변을 평가하도록 의무화 한다.

   # 출력 규칙
   모든 답변은 반드시 다음 JSON 형식을 따라야 한다.
   {
     "persona_alignment": "작성한 답변이 해당 역할에 얼마나 부합하는지 점수(0-10)",
     "reasoning": "왜 이 답변이 최선인지에 대한 논리",
     "final_answer": "사용자에게 전달할 실제 답변"
   }

3. 프롬프트 구조적 레이아웃 설계
   • 정보의 우선순위를 명확히 배분하는 구조적 레이아웃을 사용한다.

   System: 에이전트의 존재 이유
   Context: 현재 필요한 데이터
   Intruction: 구체적 수행 명령
   Constraints: 절대로 해선 안 될 행동이나 반드시 포함할 말투와 어조.

4. few-shot
   • 프롬프트에 예시를 주는 방식을 사용한다.

   사용자가 질문을 했을때: (나쁜 예시)"이렇게하지마" - (좋은 예시)"이렇게 해"
   사용자가 말을 하고 있을때: (나쁜 예시)"이렇게 호응하지마" - (좋은 예시)"이렇게 호응해봐"

2. 하네스 엔지니어링(딱딱하지만 안정성)

랭그래프 등을 이용하여 실행 인프라를 직접 설계함으로써 신뢰성과 성능을 극대화 하도록 유도한다.

1. 실행 루프: 모델이 답변할 뿐 아니라, 루프를 통해 알아서 판단하도록 한다.
2. 도구 레지스트리: 에이전트가 사용할 수 있는 도구를 명확하게 전달한다.
3. 컨텍스트 관리자: 에이전트의 기억력을 관리한다. (불필요한 정보 삭제, 핵심 정보만 요약)
4. 상태 저장소: 에이전트가 긴 작업을 할 때 현재 상태를 저장해 오류 발생 시 복구하도록 유도
5. 라이프 사이클 훅: 작업 완료, 오류, 피드백 등의 이벤트가 일어날 때 시스템이 개입함
6. 평가 인터페이스: 에이전트의 출력을 규칙에 따라 실시간으로 검증하는 장치

위와 같은 6개의 하네스 구성요소를 통해 안정성을 높인다.

그러나 프롬프트엔지니어링에 비해 유연상이 줄어들 가능성이 있다.

• 또한 구조를 강제로 포매팅하는 방식으로 하네스엔지니어링을 하면, 필요할 때 원하는 내용이 나올 수 있을 것이다.

3. LoRA적용(어투와 대화 내용)

LLM이 프롬프트 엔지니어링에 적응을 하지 못하거나, 자연스러운 진행을 하지 못했을 때 LLM에 아예 진행방법을 보여주어 좋은 진행 모델에 대해 설명하도록 해 보는 방법도 있다.

그렇다고 전체 LLM모델을 재학습하거나, 전체를 Fine-tuning하지 않고, 작은 가중치 층을 덧붙이는 방법으로 특정 말투와 논리 체계를 학습하는 방식을 채용하는 것이다.

실제로 위와 같은 방식은 효과가 있는데,

1. 진행자들 특유의 구어체와 언어의 소화 LLM이 말을 할 때, 어딘가 어색한 말투와 상황에 맞지 않는 말투가 어색할 수 있다. 이런 부분을 일부 학습시켜 가중치를 반영해준다.
2. 분위기 메이킹할 만한 내용 단순 딱딱한 정보 뿐아니라 가벼운 잡담, 기술토크 등 팟캐스트의 분위기를 살려 답한다.

데이터셋

LoRA학습을 위해서 데이터셋을 구성해야한다. 이를 위해서 팟캐스트의 대본을 정제해서 학습시킬 필요가 있는데.

[게스트의 답변 혹은 질문] → [진행자의 반응과 답변 그리고 추가 질문 등] 과 같은 Pair를 이루는 데이터를 모아야한다.

이를 위해 모아야할 데이터는

• 공감/리액션: 게스트 의견에 동의하거나 놀라움을 표하는 리액션 데이터
• 논리적 요약: 긴 이야기를 짧고 명확하게 정리하는 내용
• 아이스브레이킹/분위기 전환: 분위기를 전환하고, 다음 내용으로 넘기는 내용
• 질의 응답: 단순한 질문을 답하는 내용

등을 모아서 구축해야한다.

그러나 이미 있는 데이터 중엔 그런 데이터가 부족해 보인다. 예를 들어

AI-Hub 주요 영역별 회의 음성인식 데이터

• 위 데이터셋에는 토론자와 사회자의 대화 내용이 잘 담겨있고, 구어체, 등의 데이터가 다양한 카테고리로 연결되어있다.
• 음성 데이터도 포함되어 STT 파인튜닝시에도 활용할 수 있어보인다.

AI-Hub 인터뷰 진행 멀티턴 데이터

• 위 데이터셋에는 인터뷰를 진행하는 사회자의 질문, 답변자의 질문이 담겨있다.
• 그러나 사회자의 호응은 좀 부족하고, 단지 인터뷰 특유의 질문이 많은 데이터.

그러나 실제 우리가 원하는 팟캐스트 관련 LLM 데이터는 부족했따.

따라서 STT혹은 수동으로 팟캐스트 대화 내용을 따 학습 데이터를 구축하는 방법이 필요할 듯 보인다.

4. 멀티 에이전트 협업

기본적으로 현재 하나의 에이전트가 음성을 받고, 해당 음성에 대해 처리하고, 출력결과를 말해주는 방식을 채택하고 있는데, 추가적으로 감독을 하는 AI를 생성한다.

• 출력된 내용을 검사하고, 매겨진 점수가 너무 낮으면 다시 출력하고, 적당하면 출력 한다 또한, 더 개선하도록 개선사항을 직접 말해주는 Actor-Critic구조를 사용한다.

위와 같이 두개의 에이전트를 사용할거면, 확실히 시간이 오래들기 때문에, 구조를 설계하는데 있어서 더 집중이 필요해보인다.