이번 포스팅에서는 LLM Application과 LLM Application Tool에 대해 작성해보려 한다.

Chat GPT의 탄생과 함께 GPT를 활용한 스타트업이 우후죽순으로 나타났다. 창작을 하는 GPT Service가 등장하고 사람들은 언제고 자신의 업무가 AI로 대체될 것이라는 걱정과 내 일을 대신해 줄 수 있다는 기대감으로 GPT를 바라봤다.

그리고 지금, 이러한 기대는 여전히 '기대'로만 남아있다. 모두가 그 가능성은 무궁무진함을 인정하지만, 아직까지 명확한 활용방안을 찾지 못한 상황인 것 같다. LLM을 활용한 스타트업 중, 여기가 성공했다! 라는 이야기를 아직 듣지 못한 것 같다. (미리미리 엔비디아랑 마소를 주워담..)

이러한 시장 상황에서 우리 회사는 아주 잘 하고 있다고 생각한다. 개인적으로 우리 회사처럼 LLM을 헤비하게 사용하고 있는 회사는 아주 드물 것으로 생각한다. LLM의 특징을 잘 이해하고 활용하고 있으며, 그 방법도 훌륭하다고 생각한다.

아직 고개를 들지 않았지만, LLM Application을 잘 만들고 있다고 생각하는 회사들은 이렇게 생각할 것이다. 수 많은 시도 끝에 누적한 프롬프팅 방법론과 컨텐츠를 만드는 논리가 곧 그들의 자산이고 차별성일 것이다.

이미 알려진 프롬프팅 엔지니어링 방법론이 있다. Chain of Thought 라든가 few-shot 이라든가. 아주 효율적인 방법이다. 잘 써야 효율적이다.

Chain of Thought의 경우, 짧을 수록 잘 이해한다. 그리고 정말 중요한 것은 반복해서 명령한다. 예를 들어, 시장 보고서를 만드는 프롬프트가 있다. 이런 성격의 생성물은 가격과 같은 숫자가 아주 중요하다. 값이 바뀌면 아주 골아파지는데, 가격과 관련한 할루시네이션을 방지하기 위해 다음과 같이 PROMT를 줄 수 있다.

I want to write Market Research Report. Check the below RULE and correct my report.

RULE
1. This is Market Research Report.
2. Do not change the price in the report.

...

5. Never change the price in the report.

이런식으로 중요한 명령은 반복해서 줄 수 있다. 그리고 각 명령은 짧고 명료할 수록 좋다.

한편, few-shot의 중요성은 몇 번을 강조해도 아쉽지 않다. '좋은' 예시는 '좋은' 결과를 만들기 위한 필수 요소라고 볼 수 있다. (매번 그런 건 아니다. 가끔은 zero-shot도 괜찮은 결과를 만든다.)

Chain of Thought이든 few-shot이든 여러 프롬프팅 방법론에 대해서 완벽하게 이렇게 해라!는 없다. 아니 그게 뭔소리야? 라고 할 수 있으나, 어쩔 수 없다. 이게 코딩과 프롬프팅의 차이점이라고 할 수 있지 않을까 한다. 프롬프트에 따라 Rule을 적게 줬을 때 더 좋은 결과를 보이기도 하고, 어떤 경우에는 Rule을 많이 줬을 때 좋은 결과를 보이기도 한다. 그렇다면 여기서 잠깐, 적용하고 싶은 룰은 10가지인데, 이걸 어떻게하면 적게 줄 수 있을까? 여러개의 룰을 하나로 합치는 방법도 있고, 프롬프트 자체를 나누는 방법도 있다. 프롬프트를 나눈다는 것은, 같은 목적의 프롬프트 둘로 쪼갠다. 1~5번 명령은 a 프롬프트에서, 6~7번 명령은 b 프롬프트에서 처리하도록 한다. 그리고 a 프롬프트와 b 프롬프트를 연달아 처리하도록 한다.

또다른 팁은 프롬프트를 영어로 주면 당연히 더 좋다. 그리고 문법을 조금만 틀리면 결과도 틀려먹는다. (프롬프트 결과가 이상하다면, 문법상 문장을 잘못 쓴 것이 아닌가 확인해보자.)

LLM을 활용해 Contents를 생성하는 Application을 만들다 보면, 다음과 같은 문제를 만나게 된다.

1. 프롬프트는 엄청 바뀌는데, 이걸 매번 개발자에게 부탁하기 어렵다.

2. 파이프라인(프롬프트와 프롬프트의 견결)이 점점 길어지면서 전체 구조가 궁금한데, 이 또한 코드에 적혀있으니 개발자와 커뮤니케이션하는 시간이 소요된다.

3. 어느정도는 프롬프트를 작성하겠으나, Contents의 퀄리티에 대한 욕심이 생기면서 domain 지식이 부족함을 느낀다.

4. 결론적으로 개발자, 프롬프트 엔지니어(?), 도메인 전문가. 이 세가지 영역에 대해 잘 아는 사람들의 조합으로 일을 진행하게 된다. 그런데 이들이 커뮤니케이션을 최소화하며 각자 잘 하는 영역에만 집중해서 일하고 싶은데,,,, 그럴 만한 적당한 시스템이 없다.

그래서 우리는 LLM Ops 툴을 자체적으로 만들어서 사용하고 있다. LLM Ops툴을 만들기 위해서 만든게 아니라, LLM을 활용한 Application을 빠르게, 쉽게 구축하기 위해 만든 Ops툴이다. 실제로 LLM Ops툴을 사용하며, 생산성이 엄청나게 올라갔다.

개인적으로 거대한 기능을 아침에 만들자고 결정하고 기획을 시작해서 퇴근 전에 배포한 경험이 있는데, LLM Ops 툴이 없었다면 3일은 걸렸을 여정이었다. 우리 툴의 특징은 다음과 같다.

1. 개발자와 도메인 전문가가 전체 로직을 기획한다.

2. 개발자가 툴을 활용해서 전체 로직(파이프라인)을 구축한다.

3. 도메인 전문가와 프롬프트 엔지니어가 프롬프트의 내용을 채운다.

4. 완성!

프롬프트의 변경에 따라 개발자가 붙을 필요가 없고, 전체 로직에 대해서는 도메인 전문가와 프롬프트 엔지니어도 한 눈에 파악할 수 있다. 그리고 전체 로직의 실행 결과와 단계별 결과도 쉽게 확인할 수 있다. 이 외에도 LLM application을 만들며 생산성에 도움이 되는 디테일한 부분들이 많이 있다. (우리의 LLM Ops 툴에 대해 궁금하다면 댓글의 링크를 확인해주세요!)

프롬프팅에 대해서는 구체적으로 할 말이 너무나도 많지만,,, 어디까지 공개해도 될지 모르겠어서 맛보기만 공유한다.

PS. Service의 탄생부터 PO를 맡아보신 분 중 커피챗 하실 분을 찾습니다. Product를 만들어나가며 드는 고민 등을 공유(와 상담)하고자 합니다.