https://slashpage.com/haebom/dk58wg2en8xrvmnqevxz

Prompt vs Fine-tuning vs RAG - 해봄의 잡동사니

최근 다양한 분들이 인공지능에 관심을 가지면서 평소 IT업계에 별 관심이 없던 분들도 이에대해 다양한 문의를 주시고 계십니다. 실제로 요청에 의해 도움을 몇번 드리기도 하면서 기술적으로 어려운 부분 보다는 지금 우리 서비스 혹은 도메인에 맞는 방법을 찾는 시기 같습니다. 모델의 발전은 계속해서 일어날 것이고 칩셋, 전력량 등에 대한 문제도 결국 시간이 해결...

slashpage.com

프롬프트 엔지니어링(디자인, 기법... 뭐든)

- 가장 기본적인 방법으로, 모델에게 원하는 정보를 얻기 위해 적절한 지시사항을 주는 것과 같습니다.

- 누구나 쉽게 사용할 수 있지만, 모델이 학습한 내용에 크게 의존하므로 최신 정보나 구체적인 내용을 얻는 데는 한계가 있습니다.

파인튜닝(Fine-tuning)

- 기존 언어 모델에 새로운 정보를 학습시켜 업데이트하는 것으로, 시간과 비용이 많이 들지만 특정 주제에 대해 전문성을 갖출 수 있습니다.

- 사용자가 원하는 대로 모델을 커스터마이징할 수 있고, 정확도가 높아지는 장점이 있습니다. 하지만 기술적 이해도가 필요하고 많은 데이터가 필요합니다.

RAG(Retrieval Augmented Generation)

- 언어 모델과 지식 베이스를 결합한 방식으로, 질문에 답할 때 관련 정보를 먼저 수집한 뒤 이를 바탕으로 답변을 생성합니다.

- 최신 정보가 필요하거나 다양한 주제를 다룰 때 유용하며, 프롬프트 엔지니어링과 파인튜닝의 중간 정도의 난이도와 비용이 듭니다.

- RAG의 성능은 벡터 데이터베이스의 영향을 많이 받는데, MyScale이라는 SQL 기반의 벡터 DB를 활용하면 비용 절감과 성능 향상의 이점이 있습니다.

가끔 파인튜닝과 RAG를 사용하면 할루시네이션(즉, 모델이 사실이 아닌 정보를 생성하는 현상)이나 멀티턴 대화의 어려움이 곧 잘 해결될 것이라 기대하는 분들이 있지만 이는 약간 틀립니다. 실제로 위 방법을 적용한다고 LLM이 가지는 고유한 문제점이 해결되진 않기 때문이죠.

- 할루시네이션: 파인튜닝 과정에서 모델은 제공된 학습 데이터에 매우 의존하게 됩니다. 학습 데이터가 오류를 포함하고 있거나, 충분히 다양하지 않은 경우 모델이 잘못된 정보를 학습하여, 이를 진실로 인식하고 출력할 수 있습니다. RAG의 경우, 외부 정보 소스에서 검색된 데이터의 질과 관련성에 따라 출력의 정확성이 달라질 수 있으며, 이는 때로 할루시네이션을 유발할 수 있습니다.

- 멀티턴 대화: 멀티턴 대화는 이전 대화의 맥락을 이해하고 이에 적절히 반응하는 능력을 필요로 합니다. 파인튜닝된 모델이나 RAG를 사용할 경우, 대화의 맥락을 모델이 충분히 이해하고 반영하기 위해서는 추가적인 최적화가 필요합니다. 특히, 모델이 각 대화 턴의 연관성을 정확히 파악하지 못하면 대화의 자연스러움이 떨어질 수 있습니다.

오히려 이런 경우를 바로 해결하고 싶으면 Prompt 기법들을 가져다 쓰는게 효용성이 더 높습니다. 이유는 간단한데 들인 비용에 비해 효과가 월등하기 때문입니다. 이는 모델이 좋아질 수록 더더욱 유용해질 것 입니다. 나중엔 의도하면서 말하지 않아도 앵간하면 다 처리해주는 모델들이 나올거구요.

RAG의 경우, 외부 지식 베이스에서 retrieval된 정보가 부정확하거나 불완전할 수 있습니다. 이는 모델이 잘못된 정보를 바탕으로 할루시네이션을 일으키는 원인이 될 수 있죠. 또한 대화의 맥락을 고려하지 않고 단순히 retrieval된 정보에 의존하게 되면, 멀티턴 대화에서 일관성 있는 응답을 하기 어려워집니다.

파인튜닝의 경우, 학습 데이터의 품질과 양에 크게 영향을 받습니다. 데이터가 부족하거나 편향되어 있다면, 모델은 overfitting되어 일반화 성능이 떨어질 수 있습니다. 이는 할루시네이션이나 부적절한 응답으로 이어질 수 있죠. 또한 파인튜닝된 모델은 학습 데이터에 없었던 새로운 주제나 맥락에 대해서는 대처하기 어려울 수 있습니다.

이런 점을 고려했을 때, 가성비 면에서는 프롬프트 엔지니어링이 가장 유리할 수 있습니다. 프롬프트 엔지니어링은 기존 모델의 지식을 최대한 활용하면서도, 사용자가 원하는 방향으로 모델을 유도할 수 있기 때문이죠. 또한 구현이 쉽고 비용이 적게 들어, 다양한 상황에서 빠르게 적용해볼 수 있습니다.

하지만 프로젝트의 요구사항에 따라 RAG나 파인튜닝이 더 적합한 경우도 있을 것입니다. 예를 들어 특정 도메인에 특화된 응답이 필요하다면 파인튜닝이, 실시간으로 최신 정보를 반영해야 한다면 RAG가 더 나은 선택일 수 있습니다.

결국 어떤 방식이 가장 좋을지는 프로젝트의 목적, 데이터의 특성, 가용 자원 등을 종합적으로 고려해 결정해야 할 것 같습니다. 필요에 따라 여러 방식을 함께 사용하는 것도 좋은 전략이 될 수 있겠죠. 프롬프트 엔지니어링으로 기본적인 성능을 확보하고, 파인튜닝이나 RAG를 부분적으로 적용해 보완하는 식으로요.

간단하게 비교하면 다음과 같이 비교할 순 있겠습니다.

하지만 위에서도 말했듯이 이 모든게 점점 쉬워질 것입니다. 실제로 최근 국내외 기업들이 이것들이 모두 가능한 서비스를 하나 둘 내놓고 있습니다. 

파인튜닝이나 RAG도 UI로 누구나 할 수 있는 시대가 성큼 성큼 다가오고 있는 것도 사실이라 어떤 방법이 무조건 좋다라는 접근법 혹은 이런 방법을 적용하면 이 문제가 모두 해결된다는 은탄환을 기대하시는 분들에겐 아쉬운 이야기이지만... 현재로선 이정도 알고 접근하시면 좀 더 지금 상황에서 필요한게 무엇인지를 생각할 수 있을 것 같습니다.