작업을 완료하기 위해 LLM(대형 언어 모델)을 여러 번 호출해야 하는 생성 AI 애플리케이션을 구축할 때 일반적인 문제는 LLM에 대한 반복 쿼리가 비용이 많이 들고 예측할 수 없다는 것입니다. GPT-3.5/4와 같은 대형 모델은 추론을 훈련하고 실행하는 데 엄청나게 리소스 집약적입니다. 이는 API 요금뿐만 아니라 간헐적인 서비스 중단에도 반영됩니다. ChatGPT는 원래 연구 미리 보기로 출시되었으며 프로덕션 애플리케이션에 사용할 수 없습니다. 그러나 광범위한 응용 프로그램 전반에 걸쳐 LLM의 유용성은 부인할 수 없으므로 LLM에 대한 관심이 폭발적으로 증가했습니다.
ChatGPT가 시작된 이래로 사용자는 GPT를 사용할 때 개인 정보 보호가 부족하고 가동 시간 또는 추론 설정을 제어할 수 없는 문제를 해결하는 방법을 찾고 있었습니다. 이로 인해 Meta의 Llama 2 와 같은 무료 공개 모델이 인기를 얻었고 나중에 소비자 하드웨어에서 실행할 수 있는 Llama의 양자화되고 매개변수가 낮은 버전이 만들어졌습니다. 이러한 공개 모델은 훨씬 적은 컴퓨팅 성능으로 GPT와 동일한 기능을 제공할 수 있지만 매개변수와 자세한 출력은 더 적습니다.
애플리케이션이 지나치게 큰 컨텍스트를 처리하거나 자세한 출력을 생성하는 데 반드시 의존하지 않는 경우 제어하는 인스턴스에서 자체 추론을 호스팅하는 것이 더 비용 효율적인 옵션이 될 수 있습니다. 그리고 RAG( 검색 증강 생성 )를 실제로 적용할 경우 비용 차이가 훨씬 더 커질 수 있습니다.
상용 하드웨어에서 정확한 RAG를 수행하기 위해 벡터 저장, 어휘 검색 및 프롬프트 엔지니어링을 결합하는 간단한 방법을 보여 드리겠습니다. 이 방법을 사용하면 대량 정보의 복잡성을 줄이고 생성적 AI 애플리케이션을 대규모로 더욱 정확하고 효율적이며 비용 효율적으로 실행할 수 있습니다. 특정 정보 저장소에 RAG를 사용하면 환각을 제거하고 타사 API에 대한 비용을 지불하지 않고도 모든 소스 자료에서 효과적이고 지식이 풍부한 에이전트를 생성할 수 있는 기능을 얻을 수 있습니다.
시작하려면 벡터와 텍스트 데이터를 저장하기 위한 DataStax Enterprise 7 인스턴스 또는 DataStax Astra DB 뿐만 아니라 응답을 생성하고 벡터로 데이터를 인코딩하기 위한 LLM 및 문장 변환기 모델이 필요합니다. 데이터 또는 사용자 프롬프트의 복잡성에 따라 Solr 검색을 수행하여 더 넓은 범위의 데이터와 일치시킬 수 있는 DataStax Enterprise 6.8 데이터베이스와 결합하는 것을 고려할 수도 있습니다. 이것이 제가 이 예에서 사용한 것입니다. DataStax는 단일 데이터베이스로 이러한 모든 작업을 가능하게 하기 위해 지속적으로 개선 작업을 진행하고 있지만 지금은 두 개의 데이터베이스를 사용합니다.
환각 해결
어떤 LLM을 선택하든 그들은 모두 여전히 환각 에 시달리고 있습니다. 현재로서는 RAG라고도 알려진 LLM에 대한 프롬프트 컨텍스트에 진실된 정보를 제공하여 이러한 제한을 해결해야 합니다. 정보를 찾아 프롬프트에 맞게 변환하는 방법은 데이터 모델에 따라 완전히 다르지만 벡터 데이터베이스를 사용하면 더 효율적인 방법으로 더 관련 있는 정보를 찾을 수 있습니다.
예를 들어 Warhammer 40,000 게임 방법과 같이 탐구하고 싶은 주제에 대한 전자책 컬렉션이 있다고 가정해 보겠습니다. 일반적인 상황에서는 지원 문헌을 읽고 전문가 수준에 도달할 만큼 충분한 게임 플레이 경험을 쌓는 데 수년이 걸릴 것입니다.
"Adepta Sororitas의 Morvenn Vahl에 대해 무엇을 말해주실 수 있나요?"와 같은 타겟 질문입니다. 베테랑 플레이어나 워해머 매장 직원이 가장 잘 대답할 것입니다. ChatGPT는 게임에 대한 많은 질문에 답할 수 있지만 안타깝게도 이 특정 캐릭터를 다루는 교육 데이터는 없습니다.
이를 Nvidia RTX A4000 그래픽 카드가 있는 소비자 워크스테이션에서 호스팅되는 Llama 2 13B 매개변수 LLM과 비교해 보세요. 마찬가지로 모델은 워해머 세계에 대한 기본 지식을 보여줄 수 있지만 튜닝으로 인해 모델은 캐릭터가 발견되지 않는 것에 신경 쓰지 않고 대신 최선의 환각을 제공합니다.
신규 이민자와 베테랑 모두가 Warhammer 40,000을 플레이하는 데 도움이 될 수 있는 챗봇을 구축하려는 경우 이러한 결과는 허용되지 않습니다. 효과적인 게임 가이드가 되려면 챗봇이 게임 규칙, 각 유닛의 규칙, 일부 지식, 일부 전략 및 해설을 알아야 합니다. 운 좋게도 10판 규칙에 대한 모든 정보는 Games Workshop 및 팬 웹사이트에서 무료로 제공되며, 챗봇 앱에서 해당 정보를 검색할 수 있도록 설정하기만 하면 됩니다.
RAG를 사용하여 Morvenn Vahl의 몇 가지 소스를 비교하고 사용자 프롬프트에 따라 관련 답변을 고안하도록 요청받는 동일한 13B Llama 모델과 이를 비교해 보세요. 이번에는 챗봇이 검색 데이터베이스와 Warhammer 40,000 10판 플레이 방법에 대한 모든 공개 정보가 담긴 벡터 데이터베이스에 접근할 수 있게 되었습니다.
얼마나 큰 차이인가! 이 틈새 캐릭터에 대한 적절한 정보를 찾을 뿐만 아니라 10판 규칙에 따라 게임을 플레이하는 방법의 맥락에 맞춰 출력을 유지합니다.
이 모든 것에서 가장 어려운 부분은 LLM에 제공할 관련 페이지를 찾기 위해 효과적인 검색을 수행하는 것입니다. 이 경우 벡터 데이터베이스가 특히 유용할 수 있습니다.
벡터 적용
이 예에서는 벡터를 비교하고 어휘 검색을 수행할 수 있어야 하는 챗봇 애플리케이션의 데이터베이스 요구 사항을 충족하기 위해 Docker 인스턴스에서 실행되는 DSE 7 및 DSE 6.8을 사용합니다. DSE 7 및 Astra DB에는 벡터를 저장하고 벡터 검색을 수행하는 기능은 물론 텍스트 일치를 기준으로 필터링하는 기능이 도입되었습니다. 이 예에서는 수십 권의 책만 검색하면 되므로 Docker에서 DSE 인스턴스를 실행하면 대부분의 소비자 하드웨어에 충분합니다.
데이터베이스에서 벡터를 사용하면 특정 쿼리와 유사한 문서를 찾는 데 도움이 되거나 다른 검색에서 검색된 결과를 비교하는 데 사용할 수 있습니다. 이는 어휘 검색의 한계를 극복하고 데이터 모델의 효율성을 향상시키는 데 도움이 될 수 있습니다.
예를 들어, 전자책 PDF와 같은 콘텐츠는 miniLM 과 같은 문장 변환기로 인코딩하면 이점을 얻을 수 있으며, 벡터는 쿼리와 특정 소스 간의 유사성 비교를 실행하는 데 사용될 수 있습니다. 이 경우 문장 변환기 모델을 사용하여 전자책의 페이지 텍스트 임베딩을 생성하고 이를 통해 사용자의 프롬프트와 비교하여 결과가 쿼리와 관련이 있는지 파악할 수 있습니다. 관련 페이지에는 사용자의 검색어와 유사한 용어의 인스턴스가 하나 이상 포함되어 있어야 하며 모델의 관점에서 더 나은 유사성 점수를 얻어야 합니다.
즉, 벡터는 기존 어휘 검색 모델에 대한 보충 자료로 가장 잘 적용됩니다. 벡터로만 검색하면 예기치 않게 관련 없는 문서를 검색하여 적용되지 않는 컨텍스트로 제공하게 될 수 있습니다.
이 예에서는 "Adepta Sororitas의 Morvenn Vahl에 대해 무엇을 말해주실 수 있나요?"라는 질문이 있습니다. LLM에 의해 간단한 검색어 세트로 변환될 수 있습니다.
Morvenn, Vahl, Adepta, Sororitas
관련 문서를 찾는 첫 번째 단계는 이러한 기본 용어가 포함된 문서를 검색하는 것입니다. 이는 먼저 데이터베이스에서 텍스트 일치를 필터링하여 해당 쿼리와 일치하는 페이지 텍스트의 키워드를 찾는 방식으로 수행할 수 있습니다. LLM을 사용하여 키워드를 생성하는 이유는 관련이 있지만 원래 프롬프트의 텍스트에는 없는 더 많은 키워드를 추가하려고 시도하기 때문에 더 넓은 범위의 가능한 키워드를 검색할 수 있도록 제공하기 위한 것입니다. 그러나 LLM은 정리해야 할 특수 문자와 이상한 시퀀스를 생성할 수도 있으므로 주의하세요.
적어도 하나의 결과가 있으면 사용자의 쿼리를 벡터화하고 이를 어휘 검색의 벡터와 비교하여 각 결과의 관련성에 대한 점수를 생성할 수 있습니다. 이를 통해 검색 결과의 쿼리 정확성을 확인하고 결과를 최종적으로 LLM에 제출할 때 관련 없는 결과를 거부하기 위한 임계값을 설정할 수 있습니다.
이 경우 첫 번째 단계에서는 Morvenn Vahl의 인덱스 카드나 게임 플레이 메커니즘을 구체적으로 보여주는 페이지와 일치해야 합니다. 왜냐하면 이러한 페이지는 게임에서 캐릭터의 유닛이 어떻게 플레이되는지 설명하기 때문입니다. 페이지가 애플리케이션에 의해 결정된 사용자 쿼리에 대한 특정 관련성 임계값을 충족하면 페이지가 요약되어 결과 목록에 배치됩니다.
마지막으로, 검색 결과는 목록으로 편집되어 LLM으로 피드백될 수 있으며, 여기서 LLM은 원래 쿼리에 응답하기 위해 가장 관련성이 높은 컨텍스트를 사용하도록 요청받습니다. 다음은 흐름을 시각화한 것입니다.
보시다시피 이 흐름에 대해 LLM이 매우 자주 호출됩니다. LLM은 사용자 프롬프트를 키워드로 변환하고, 적용 가능한 결과를 요약하고, 쿼리에 가장 적합한 컨텍스트를 선택하는 일을 담당합니다. 확인할 각 소스에는 또 다른 LLM 호출이 추가되는데, 이는 GPT에 쿼리할 때 비용이 상당히 많이 들 수 있습니다. 그러나 필요한 정보가 이미 있고 이를 요약하거나 변환하려는 경우에는 그렇게 큰 모델을 사용할 필요가 없을 수도 있습니다. 실제로 더 작은 모델로 전환하면 여러 가지 이점을 얻을 수 있습니다.
더 작은 LLM을 사용하면 각 쿼리의 계산 비용을 줄일 수 있으므로 시간이 지남에 따라 상당한 비용 절감 효과를 얻을 수 있습니다. 또한 이를 통해 사용자의 응답 시간이 빨라지고 전반적인 경험이 향상될 수 있습니다. 모두 동일한 GPU 인스턴스에서 호스팅되는 소규모 LLM 및 소규모 데이터베이스를 사용하여 RAG가 수행되는 이 예에서는 15개의 소스를 검색하고 관련성을 분석하고 최종 답변을 제공하는 데 약 30초가 걸립니다. 프롬프트(소스)가 짧을수록 출력이 더 빨리 반환될 수 있습니다.
또한 이 방법을 사용하면 보안과 확장성이 향상됩니다. 신속한 엔지니어링과 LLM에 대한 호출 파이프라인을 통해 데이터에 액세스하는 방법과 사용자가 응답에서 무엇을 얻게 될지 완벽하게 제어 할 수 있습니다. 리소스 사용량 측면에서 예시 13B 매개변수 모델은 8GB가 조금 넘는 VRAM만 소비하며 여전히 관련 답변을 제공합니다. 필요에 따라 이는 사용자 워크스테이션 및 모바일 장치와 같은 수많은 다른 플랫폼에서도 RAG를 실행할 수 있는 가능성을 보여줍니다.
출력 제어
RAG가 원하는 것을 정확히 수행하도록 하려면 신속한 엔지니어링이 핵심입니다. 챗봇이 데이터와 생각해야 하는 컨텍스트를 해석하는 방법을 제어할 수 있습니다. 이 예에서 우리는 챗봇이 우리가 특별히 워해머 정보를 찾고 있다는 것을 알고 있는지 확인하고 싶으므로 먼저 사용자 쿼리에 대한 지원 컨텍스트를 제공하도록 챗봇에게 요청할 수 있습니다.
쿼리: “<사용자 쿼리>”
검색 엔진에 대한 최소한의 쉼표로 구분된 Warhammer 40K 키워드 목록을 제공하세요. 쿼리로만 응답하세요. 이모티콘이나 특수문자를 사용하지 마세요.
답변:
워해머 40,000에는 관련 없는 다른 대중 문화에 나타날 수 있는 용어와 이름이 가득하므로 첫 번째 쿼리에서 RAG의 맥락을 설정하는 것이 중요합니다. 이 컨텍스트는 워해머 게임 규칙의 여러 버전을 다루거나 이를 공식 지식 서적과 결합해야 하는 경우와 같이 애플리케이션이 여러 컨텍스트를 다루는 경우 선택하거나 수정할 수 있는 것이어야 합니다.
이 실험에서는 사용자의 쿼리가 항상 인용문으로 캡슐화됩니다. 이는 LLM이 직접 응답하려는 쿼리와 직접 응답해서는 안 되는 별도의 프롬프트 엔지니어링 지침을 구별하는 데 도움이 됩니다. 프롬프트의 질문/답변 부분은 특정 상황에 맞게 조정될 수 있지만, 대부분 LLM에게 직접 응답해야 할 것과 응답하지 말아야 할 것과 응답하는 방법을 알려주기만 하면 됩니다.
이 경우 시리즈가 상당히 인기가 있고 일반 정보가 무료로 제공되므로 LLM이 게임 세계에 대한 일반적인 지식을 갖고 있다고 가정하는 것이 안전합니다. 이 첫 번째 쿼리의 출력은 애플리케이션에 치트 시트를 작성할 필요 없이 어휘 검색에 사용할 몇 가지 키워드를 생성하는 데 도움이 됩니다.
그런 다음 어휘 및 벡터 비교를 백그라운드에서 수행할 수 있으며 LLM의 검토를 위해 결과 목록이 컴파일됩니다. 사용자의 원래 프롬프트는 첫 번째 단계에서 추론을 통해 직접적으로 답변되지 않기 때문에 LLM은 검색에서 찾은 내용만 변환하고 가드레일이나 지식 기반 외부의 쿼리에 대한 답변을 쉽게 중지할 수 있습니다.
검색에서 관련 결과가 있는 경우:
쿼리: “<사용자 쿼리>”
이러한 검색 결과를 검토하고 이를 사용하여 쿼리에 답하세요.
결과 1
결과 2
등.
답변:
검색에서 관련 결과가 없는 경우:
쿼리: “<사용자 쿼리>”
검색했지만 해당 쿼리에 대한 답변을 찾을 수 없었다고 정중하게 알려주세요. 대신 귀하가 알고 있는 한도 내에서 답변해 주십시오.
답변:
보안을 강화하기 위해 요청을 처리할 수 없는 경우 요청을 완전히 거부하거나 리디렉션할 수 있습니다.
쿼리: “<사용자 쿼리>”
검색했지만 검색어에 대한 답변을 찾을 수 없었다고 정중하게 알려주세요. 대신 고객 지원팀에 연락하여 도움을 요청하도록 안내해 주세요.
답변:
자세한 내용을 요청하여 출력을 더 길게 만들 수도 있습니다. 컨텍스트 창에 소스 자료를 맞출 수 있는 한 LLM이 이를 변환할 수 있습니다.
쿼리: “<사용자 쿼리>”
이러한 검색 결과를 검토하고 이를 사용하여 쿼리에 답하세요. 최대한 자세하게 작성하고 출처를 인용하세요.
결과 1
결과 2
등.
답변:
제한사항
LLM에는 제한된 컨텍스트 창이 있으며 예외적으로 큰 텍스트 페이지를 처리하지 못합니다. LLM이 데이터를 더 쉽게 관리 하고 처리할 수 있도록 행 크기에 제한을 두는 것이 좋습니다. 예를 들어, 페이지를 약 1,000자 단위로 자르는 것이 잘 작동하는 것으로 보이며 프롬프트에 4~5개 이상의 자세한 답변을 입력하지 않도록 노력하세요.
LLM은 컨텍스트 창에 들어갈 수 있는 것 외에는 대화에 대한 기억이 없습니다. 대화 데이터의 영구 저장소를 구축하는 것은 가능하지만 LLM이 지나치게 큰 대화나 자세한 컨텍스트를 프롬프트에 맞추는 것은 불가능합니다. 변환할 수 있는 것에는 상한선이 있습니다. 이는 무슨 일이 있어도 특정 시점에 LLM이 특정 세부 사항을 컨텍스트로 제공하더라도 "잊는" 것처럼 보인다는 것을 알게 될 것임을 의미합니다. 이는 도구의 본질적인 한계일 뿐입니다. 짧은 대화에만 의존하고 환각을 최소화하기 위해 한 번에 소량의 텍스트를 변환하는 데 집중하는 것이 가장 좋습니다.
LLM의 무작위성은 문제가 될 수 있습니다. 데이터 세트에 가장 적합한 프롬프트를 결정하고 사용 사례에 가장 적합한 모델을 찾으려면 테스트 및 조정이 필요합니다. 13B 매개변수 모델을 사용한 테스트에서는 특히 프롬프트 길이가 길어질수록 첫 번째 프롬프트에서 어떤 검색 키워드가 생성되는지 예측할 수 없는 경우가 많았습니다. 최상의 결과를 얻으려면 더 짧은 프롬프트를 사용하세요.
결론
요약하자면, 벡터와 어휘 검색 모델을 결합하여 RAG를 활용하면 관련 결과를 보다 효과적으로 찾고 정렬할 수 있으며 환각에 덜 취약한 에이전트 출력을 생성할 수 있습니다. 검색 가능한 컨텍스트가 작을수록 응답이 더 정확하고 정확해집니다. LLM 호출의 사용자 정의 파이프라인을 구성하면 원하는 수준의 정확성과 가드레일에 맞게 응답을 조정하는 데 훨씬 더 많은 유연성이 제공됩니다.
제한된 컨텍스트 창 내에서 지나치게 많은 양의 데이터를 처리할 수는 없지만 제한된 지식 기반에서 효과적인 보조자를 생성하고 이전보다 동일하거나 더 적은 하드웨어에서 더 많은 동시 에이전트를 실행할 수 있는 기능을 제공합니다. 이는 테이블탑 게임과 같은 애플리케이션을 위한 가상 비서에 대한 더 많은 가능성을 열어줄 수 있으며 심지어 정부, 법률 및 회계 회사, 과학 연구, 에너지 등에서 사용하는 더 복잡한 주제를 다룰 수도 있습니다.
구축을 시작할 준비가 되었다면 Astra DB를 무료로 사용해 볼 수 있습니다. 지금 바로 데이터베이스를 생성하고 RAG 소스 로드를 시작하세요. 클라우드나 데이터베이스 운영 경험이 필요하지 않습니다.
작성자: Mario Charnell-Delgado, DataStax
여기에도 게시되었습니다.
