일본산업뉴스요약

Nikkei X-TECH_2024.3.7

생성 AI 활용 (3)
생성 AI 활용의 비장의 카드 'RAG'
사내 정보를 기반으로 회답할 수 있지만, 비용에는 요주의

생성 AI(인공지능)를 업무에 활용할 때 유저 기업이 어려움에 직면하기 쉬운 포인트를 지적하는 이번 특집. 제3회는 ‘RAG를 능숙하게 사용하는 것은 어렵다’, ‘대규모언어모델(LLM)을 선택하는 것은 어렵다’, ‘생성 AI를 사용해 최신 시스템을 개발하는 것은 어렵다’등 3가지를 소개한다.

포인트 7: RAG를 능숙하게 사용하는 것은 어렵다

LLM을 업무에서 활용할 때의 ‘비장의 카드’로 기대되고 있는 기술이 RAG(Retrieval Augmented Generation, 검색확장생성)이다. RAG는 LLM이 답변을 생성할 때 유저의 프롬프트(지시문)에 대응하는 외부의 지식정보를 참조하는 기술이다. 하지만 이러한 RAG를 능숙하게 사용하는 것은 어렵다. 이것이 7번째 포인트이다.

LLM은 사전에 학습한 지식을 바탕으로 텍스트를 출력하는 특성상 사전에 학습한 지식에 없는 내용을 질문 받을 경우, 답변하지 못하거나, 엉터리 답변을 출력하기도 한다. 이른바, 할루시네이션(환각)의 문제이다.

-- LLM이 '참고서'를 보면서 답변 --
RAG는 LLM에 대해 사전에 학습한 지식뿐만이 아니라, 외부의 지식 정보도 참조해서 텍스트를 생성하도록 한다. 엑사위저즈의 자회사 엑사엔터프라이즈AI의 AI전략그룹을 이끄는 하세가와(長谷川) 그룹리더는 "LLM이 참고서를 보면서 답변하는 이미지"라고 RAG를 설명한다. 참조할 정보 선택에 검색 기술을 사용하기 때문에 ‘검색확장생성’이라고 불린다.

RAG의 장점은 용도에 맞는 데이터를 추가 학습시키는 파인 튜닝과 달리 기계학습 모델의 파라미터를 그대로 사용하기 때문에 구현 장벽이 낮다는 점이다. 또한 외부지식을 참조하는 RAG의 구조를 활용하면, 최신 정보나 기업의 내부 정보에 근거한 답변을 LLM가 생성할 수 있다. LLM을 사내 업무에 활용하는 데 있어 RAG는 비장의 카드가 될 수 있는 것이다.

하지만 사내 정보에 기반한 텍스트를 생성하는데 반드시 RAG나 검색 시스템이 필요한 것은 아니다. 예를 들면, 프롬프트에 모든 사내 문서를 삽입하는 방식으로도 사내 정보에 근거한 텍스트는 생성할 수 있다.

하지만 최근의 LLM에 있어서 프롬프트의 길이를 나타내는 '컨텍스트 윈도우(Context window)'가 커졌다고 해도 모든 사내 문서를 프롬프트에 삽입하기는 어렵다. 현재 가장 컨텍스트 윈도우가 긴 LLM은 구글이 올 2월에 발표한 ‘Gemini 1.5 Pro’로, 100만 토큰(한정된 개발자에게만 제공)이다. 오픈AI의 최신 모델 ‘GPT-4 Turbo’의 컨텍스트 윈도우는 12만 8,000토큰이다.

사내 문서 사이즈가 기가바이트(GB)급일 경우, 질문에 어울리는 내용을 특정하는 검색 구조가 필수이다. 뿐만 아니라, LLM의 이용 요금은 소비한 토큰의 양에 비례하기 때문에 요금을 절약하기 위해서도 내용을 특정하는 구조가 필요하다.

-- ‘인력 RAG’로 효과 검증 --
노무라종합연구소(NRI)의 DX기반사업본부 IT기반기술전략실의 사기모리(鷺森) 엑스퍼트 리서처는 “RAG는 간단한 구현부터 시작해야 한다”라고 지적한다. 유저의 질문에 대응하는 외부 지식을 검색하는 시스템을 구현하는 것은 쉽지 않기 때문이다. 프롬프트에 보충해야 할 문서를 사람이 선택하는 '인력 RAG'와 같은 대처로 효과를 볼 수 있는지 검증한 뒤 RAG의 본격 도입을 생각해야 한다는 것이 사기모리 엑스퍼트 리서처의 지적이다.

RAG에 있어서 외부지식에 대한 검색에는 단어(키워드)가 포함되어 있는 문서를 찾는 기존의 ‘키워드 검색’보다 ‘벡터 검색’이 적합하다고 알려져 있다. 벡터 검색에서 텍스트는 고차원 벡터로 처리되며, 벡터의 코사인 유사도에 근거해 질문에 적합한 텍스트를 찾는다. 텍스트의 벡터화(엠베딩)에도 엠베딩 모델이라고 불리는 LLM을 사용하는 것이 최근 트렌드이다.

임베딩 모델을 사용한 벡터 검색은 새로운 기술이기 때문에 RAG 시스템을 구축할 때에는 다양한 점을 고려할 필요가 있다. 특히 중요한 것은 ‘청크 사이즈’라고 엑소엔터프라이즈AI의 하세가와 그룹리더는 지적한다.

청크 사이즈란 검색 대상 문서를 분할할 때의 크기를 말한다. 긴 문서를 그대로 벡터화하면 검색이 어렵고, 반대로 청크를 너무 작게 하면 그 문서 안의 ‘문맥(컨텍스트)’을 알 수 없게 된다. “청크의 길이가 검색 정밀도에 상당한 영향을 미치기 때문에 신중한 검토가 필요하다”(하세가와 그룹리더)라고 한다.

-- 텍스트 이외의 사내 문서는 어떻게 처리하나? --
사내 정보는 텍스트나 워드, PDF 파일뿐만 아니라 엑셀이나 파워포인트의 파일로도 축적되어 있다. 텍스트 이외의 파일에 대해서는 임베딩 모델이나 벡터 검색 엔진이 대응하지 않는 경우도 있기 때문에 주의가 필요하다.

엑사위저즈는 법인용으로 제공하는 ‘exaBase 생성 AI powerd by GPT-4’를 통해 RAG 시스템을 제공하고 있다. 엑사위저즈는 RAG로 사용하는 엠베딩 모델과 검색 엔진에 대한 상세한 내용은 공개하지 않고 있지만, 파일 형식의 PDF와 텍스트, CSV 형식의 텍스트에 대응하고 있으며, 올 3월말까지 엑셀과 워드 파일에도 대응할 예정이라고 한다.

RAG의 이용에 있어서는 코스트 측면에서의 주의가 필요하다. exaBase 생성 AI powerd by GPT-4에서는 GPT-4를 사용하는 경우에 통상적으로는 입출력 1,000자당 10엔을 과금하고 있지만, RAG를 사용하는 경우에는 질문 1회당 70~80엔을 과금하고 있다. RAG에서는 프롬프트에 외부 지식을 삽입하기 때문에 그만큼 프롬프트가 길어진다.

포인트 8: LLM을 선택하는 것은 어렵다

8번 째 포인트는 ‘LLM을 선택하는 것은 어렵다’이다. 유저 기업에 있어서 LLM에 대한 선택지가 증가하고 있기 때문이다. 클라우드에서 이용할 수 있는 LLM으로는 오픈AI의 GPT-3.5나 GPT-4, 구글의 Gemini, 아마존웹서비스(AWS)의 Amazon Titan 등이 있으며, 오픈 소스의 사전 학습이 완료된 모델로는 메타의 ‘Llama 2’와 중국 알리바바 클라우드의 ‘Qwen’등이 메이저이다.

시스템 인테그레이터 등을 취재하는 과정에서 ‘”GPT-4 이외는 그렇게 기대할 수 있는 것은 없다”라는 의견도 들을 수 있었다. 반면, rinna의 송 사업개발부 매니저는 “대형 LLM뿐만 아니라 소형 LLM도 염두에 두어야 한다”라고 주장한다.

“파라미터의 수가 클수록 여러 가지를 할 수 있다는 고정 관념이 있다. 그러나 파라미터 수에만 집착할 필요는 없다”(송 매니저). rinna가 직접 검증해본 결과, 140억 파라미터의 모델이라도 700억 파라미터의 모델에 필적하는 성능을 발휘할 수 있었다고 한다.

중요한 것은 알고리즘이다. 학습 데이터나 파라미터가 많기 때문에 좋은 품질의 모델인 것은 아니다. “작은 파라미터 속에서도 얼마나 현명하게 아웃풋을 낼 수 있을지 여부가 중요하다”라고 송 매니저는 지적한다.

포인트 9: 생성 AI를 사용하여 최신 시스템을 개발하는 것은 어렵다

9번째 포인트는 ‘생성 AI를 사용해 최신 시스템을 개발하는 것은 어렵다’이다. LLM에 의한 코드 생성은 매우 유효한 한편, 약점이 있다. 그것은 “최신 소프트웨어 라이브러리에 관한 지식이 별로 없다는 점이다”라고 NRI의 미래창발센터 생활DX·데이터연구실의 다무라(田村) 데이터 사이언티스트는 지적한다.

예를 들면, GPT-4는 파이썬(Python) 프로그램으로 데이터 분석을 하는 라이브러리 ‘pandas’에 대한 질문에는 대부분 올바른 대답을 한다. 이에 비해 비교적 새로운 라이브러리로 pandas보다 고속의 ‘polars’에 관한 대답에서는 할루시네이션이 일어난다고 한다.

또한 pandas의 파생으로 지리 공간 정보를 처리하는 라이브러리인 'GeoPandas'에 관한 질문에 대해 준비되지 않은 함수를 포함한 답변을 출력한 적이 있었다고 한다. 현재의 GPT-4는 올 4월까지의 데이터를 기반으로 텍스트를 생성한다. 소프트웨어 라이브러리는 자주 갱신되기 때문에 GPT-4가 학습한 정보가 오래된 경우가 있어 그러한 상황이 발생하는 것이다.

NRI의 사기모리 엑스퍼트 리서처는 “GPT-4는 80% 정도 올바른 코드를 생성해 준다. GPT-4가 없는 코딩은 더 이상 생각할 수 없다”라고 언급하면서도 “과신하는 것은 위험하다”라고 지적한다.

시스템 인테그레이터가 사내에서 코딩 규약 등을 정비하고 있을 경우, 그것과 동떨어진 코드가 생성된다는 점에도 주의가 필요하다. 이 문제에 관해서는 이미 AWS의 코드 생성 AI인 'Amazon Code Whisperer'가 유저의 기존 코드에 기반해 새로운 코드를 제안하는 시스템을 구현하고 있다.

깃허브가 올 2월에 일반 제공을 시작한 'GitHub Copilot Enterprise'도 유저 기업의 조직 별 코드를 이해한 후에 코드를 생성하는 기능을 구현했다. 이러한 최신 시스템을 사용하면서 코드 생성 AI에 의한 개발 효율 개선을 목표로 해야 할 것이다.

 -- 끝 --

Copyright © 2020 [Nikkei XTECH] / Nikkei Business Publications, Inc. All rights reserved.