Q4 Inc.가 Amazon Bedrock, RAG 및 SQLDatabaseChain을 사용하여 Q&A 챗봇 구축의 수치 및 구조적 데이터 세트 문제를 해결한 방법

이 게시물은 Q4 Inc.의 Stanislav Yeshchenko와 공동으로 작성되었습니다.

기업에서는 Q&A 챗봇 구축에 대한 주류 접근 방식으로 RAG(검색 증강 생성)를 선택하고 있습니다. 우리는 사용 가능한 다양한 데이터 세트의 특성으로 인해 발생하는 새로운 문제를 계속해서 확인하고 있습니다. 이러한 데이터 세트는 숫자 데이터와 텍스트 데이터가 혼합되어 있는 경우가 많으며 때로는 구조화, 비구조화 또는 반구조화되어 있습니다.

주식회사 큐4 AWS를 기반으로 구축된 많은 AI 사용 사례 중 하나에서 이러한 과제 중 일부를 해결해야 했습니다. 이 게시물에서는 Q4가 구현한 Q&A 봇 사용 사례, 숫자 및 구조화된 데이터 세트가 제시한 과제, Q4에서 SQL 사용이 실행 가능한 솔루션이 될 수 있다는 결론을 내린 방법에 대해 논의합니다. 마지막으로 Q4팀이 어떻게 활용했는지 자세히 살펴보겠습니다. 아마존 기반암 SQL 생성을 통해 RAG 기반 솔루션을 구현하는 SQLDatabaseChain.

사용 사례 개요

토론토에 본사를 두고 뉴욕과 런던에 사무소를 두고 있는 Q4 Inc.는 발행자, 투자자 및 판매자가 서로 효율적으로 연결하고 소통하고 참여하는 방식을 변화시키는 선도적인 자본 시장 액세스 플랫폼입니다. Q4 플랫폼은 IR 웹사이트 제품, 가상 이벤트 솔루션, 참여 분석, 투자자 관계 고객 관계 관리(CRM), 주주 및 시장 분석, 감시 및 ESG 도구를 통해 자본 시장 전반의 상호 작용을 촉진합니다.

오늘날 빠르게 변화하는 데이터 중심 금융 환경에서 IRO(Investor Relations Officer)는 회사와 주주, 분석가 및 투자자 간의 의사소통을 촉진하는 데 중요한 역할을 합니다. IRO는 일상 업무의 일환으로 CRM, 소유권 기록, 주식 시장 데이터를 포함한 다양한 데이터 세트를 분석합니다. 이 데이터의 집계는 재무 보고서를 생성하고, 투자자 관계 목표를 설정하고, 기존 및 잠재적 투자자와의 커뮤니케이션을 관리하는 데 사용됩니다.

효율적이고 동적인 데이터 검색에 대한 증가하는 수요를 충족하기 위해 4분기는 IRO가 필요한 정보에 사용자 친화적인 형식으로 액세스할 수 있는 직관적이고 간단한 방법을 제공하는 챗봇 Q&A 도구를 만드는 것을 목표로 했습니다.

최종 목표는 최고 수준의 보안 및 데이터 개인 정보 보호를 유지하면서 독점 고객별 4분기 데이터와 함께 공개적으로 사용 가능한 데이터를 원활하게 통합하는 챗봇을 만드는 것이었습니다. 성능 측면에서는 최종 사용자에게 긍정적인 경험을 보장하기 위해 쿼리 응답 시간을 초 단위로 유지하는 것이 목표였습니다.

금융 시장은 높은 이해관계가 개입된 규제 산업입니다. 부정확하거나 오래된 정보를 제공하면 기타 가능한 데이터 개인 정보 보호 위험 외에도 투자자와 주주의 신뢰에 영향을 미칠 수 있습니다. 업계와 요구 사항을 이해하는 Q4는 솔루션을 시장에 출시하기 전에 평가할 때 데이터 개인 정보 보호 및 응답 정확성을 기본 원칙으로 설정합니다.

개념 증명을 위해 Q4는 재무 소유권 데이터 세트를 사용하기로 결정했습니다. 데이터 세트는 소유한 자산 수를 나타내는 시계열 데이터 포인트로 구성됩니다. 투자기관, 개인, 공기업 간 거래내역 그리고 더 많은 요소.

Q4는 우리가 논의한 기능적, 비기능적 요구 사항을 모두 충족할 수 있기를 원했기 때문에 프로젝트도 상업적으로 실행 가능한 상태를 유지해야 했습니다. 이는 접근 방식, 아키텍처, 기술 선택, 솔루션별 요소를 결정하는 과정 전반에서 존중되었습니다.

실험과 도전

인간의 언어 질문을 이해하고 정확한 답변을 생성하려면 Q4가 LLM(대형 언어 모델)을 사용해야 한다는 것이 처음부터 분명했습니다.

다음은 확인된 과제 및 교훈과 함께 팀이 수행한 몇 가지 실험입니다.

사전 교육 – Q4는 자체 데이터 세트를 사용하여 LLM을 사전 교육할 때 발생하는 복잡성과 과제를 이해했습니다. 이 접근 방식은 데이터 전처리, 훈련, 평가 등의 중요하지 않은 단계를 통해 리소스 집약적이라는 사실이 금방 명백해졌습니다. 관련된 노력에 더해 비용도 엄청날 것입니다. 시계열 데이터 세트의 특성을 고려할 때 Q4는 새로운 데이터가 들어올 때 지속적으로 증분 사전 학습을 수행해야 한다는 점을 깨달았습니다. 이를 위해서는 데이터 과학, 기계 학습 및 도메인에 대한 전문 지식을 갖춘 전담 학제간 팀이 필요했을 것입니다. 지식.
미세 조정 – 여러 레이블이 지정된 예제를 사용하여 사전 훈련된 기초 모델(FM)을 미세 조정합니다. 이 접근 방식은 초기에는 어느 정도 성공을 거두었지만 많은 경우 모델 환각은 어려움을 겪었습니다. 모델은 미묘한 상황별 단서를 이해하는 데 어려움을 겪었고 잘못된 결과를 반환했습니다.
의미 검색 기능이 있는 RAG – 의미론적 검색을 사용하는 기존 RAG는 SQL 생성으로 이동하기 전 마지막 단계였습니다. 팀에서는 검색, 의미 검색, 임베딩을 사용하여 컨텍스트를 추출하는 실험을 했습니다. 임베딩 실험에서는 데이터세트를 임베딩으로 변환하여 벡터 데이터베이스에 저장한 후 질문의 임베딩과 일치시켜 맥락을 추출했습니다. 그런 다음 세 가지 실험 중 하나에서 검색된 컨텍스트를 사용하여 LLM에 대한 입력으로 원래 프롬프트를 보강했습니다. 이 접근 방식은 데이터가 단어, 문장, 단락이 포함된 자연어로 구성된 텍스트 기반 콘텐츠에 적합했습니다. 주로 숫자, 금융 거래, 주식 시세, 날짜로 구성된 금융 데이터인 Q4 데이터 세트의 특성을 고려할 때 세 가지 경우 모두 결과가 차선이었습니다. 임베딩을 사용하는 경우에도 숫자에서 생성된 임베딩은 유사성 순위에 어려움을 겪었고, 많은 경우 잘못된 정보를 검색하게 되었습니다.

Q4의 결론: SQL 생성이 앞으로 나아갈 길입니다

기존 RAG 방법론을 사용할 때 직면한 과제를 고려하여 팀에서는 SQL 생성을 고려하기 시작했습니다. 아이디어는 LLM을 사용하여 먼저 자연어로 LLM에 제시된 사용자 질문에서 SQL 문을 생성하는 것이었습니다. 그런 다음 생성된 쿼리는 데이터베이스에 대해 실행되어 관련 컨텍스트를 가져옵니다. 컨텍스트는 최종적으로 요약 단계에 대한 입력 프롬프트를 보강하는 데 사용됩니다.

Q4의 가설은 검색 단계, 특히 숫자 데이터 세트에 대해 더 높은 재현율을 얻으려면 먼저 사용자 질문에서 SQL을 생성해야 한다는 것이었습니다. 이는 정확성을 높일 뿐만 아니라 주어진 질문에 대한 비즈니스 도메인 내 컨텍스트를 유지하는 것으로 믿어졌습니다. 쿼리 생성과 정확한 SQL 생성을 위해 Q4는 LLM이 데이터 세트 구조를 완전히 컨텍스트 인식하도록 해야 했습니다. 이는 데이터베이스 스키마, 몇 가지 샘플 데이터 행, 이해하기 쉽지 않은 필드에 대한 사람이 읽을 수 있는 필드 설명을 포함해야 하는 프롬프트를 의미했습니다.

초기 테스트에 따르면 이 방법은 훌륭한 결과를 보여주었습니다. 필요한 모든 정보를 갖춘 LLM은 올바른 SQL을 생성한 다음 데이터베이스에 대해 실행하여 올바른 컨텍스트를 검색할 수 있었습니다. 아이디어를 실험한 후 Q4는 SQL 생성이 자체 특정 데이터 세트에 대한 컨텍스트 추출 문제를 해결하기 위한 방법이라고 결정했습니다.

전반적인 솔루션 접근 방식을 설명하는 것부터 시작하여 이를 구성 요소로 나눈 다음 각 부분을 하나로 묶어 보겠습니다.

솔루션 개요

LLM은 다양한 소스에서 얻은 대량의 데이터를 사용하여 사전 훈련된 수십억 개의 매개변수를 갖춘 대규모 모델입니다. 학습 데이터세트의 폭이 넓기 때문에 LLM은 다양한 분야에 대한 일반 지식을 보유하고 있어야 합니다. LLM은 모델마다 다른 추론 능력으로도 유명합니다. 이러한 일반적인 동작은 추가 도메인별 사전 학습 데이터를 사용하여 기초 모델을 추가로 최적화하거나 레이블이 지정된 데이터를 사용하여 미세 조정함으로써 특정 도메인 또는 산업에 최적화될 수 있습니다. 올바른 컨텍스트, 메타데이터 및 지침이 제공되면 잘 선택된 범용 LLM은 올바른 도메인별 컨텍스트에 액세스할 수 있는 한 우수한 품질의 SQL을 생성할 수 있습니다.

Q4의 사용 사례에서는 고객 질문을 SQL로 변환하는 것부터 시작합니다. 우리는 사용자 질문, 데이터베이스 스키마, 일부 샘플 데이터베이스 행 및 자세한 지침을 LLM에 대한 프롬프트로 결합하여 SQL을 생성함으로써 이를 수행합니다. SQL이 확보된 후 필요하다고 판단되면 유효성 검사 단계를 실행할 수 있습니다. SQL 품질에 만족하면 데이터베이스에 대해 쿼리를 실행하여 다음 단계에 필요한 관련 컨텍스트를 검색합니다. 이제 관련 컨텍스트가 있으므로 사용자의 원래 질문, 검색된 컨텍스트 및 일련의 지침을 다시 LLM으로 보내 최종 요약 응답을 생성할 수 있습니다. 마지막 단계의 목표는 LLM이 결과를 요약하고 사용자에게 전달할 수 있는 상황에 맞는 정확한 답변을 제공하는 것입니다.

프로세스의 모든 단계에서 사용되는 LLM의 선택은 정확성, 비용 및 성능에 큰 영향을 미칩니다. 동일한 사용 사례(다양한 작업에 대한 여러 LLM 여행) 내에서 또는 다양한 사용 사례에서 LLM 간에 전환할 수 있는 유연성을 제공하는 플랫폼 또는 기술을 선택하면 출력 품질, 대기 시간 및 비용을 최적화하는 데 도움이 될 수 있습니다. . 이 게시물의 뒷부분에서 LLM 선택에 대해 설명합니다.

솔루션 빌딩 블록

이제 높은 수준의 접근 방식을 강조했으므로 솔루션 구성 요소부터 시작하여 세부 사항을 살펴보겠습니다.

아마존 기반암

Amazon Bedrock은 AI21 Labs, Anthropic, Cohere, Meta, Stability AI 및 Amazon을 포함한 주요 기업의 고성능 FM을 선택할 수 있는 완전관리형 서비스입니다. Amazon Bedrock은 또한 생성적 AI 애플리케이션을 구축하고, 개발 프로세스를 단순화하고, 개인 정보 보호 및 보안을 유지하는 데 필요한 광범위한 도구 세트를 제공합니다. 또한 Amazon Bedrock을 사용하면 다양한 FM 옵션 중에서 선택할 수 있으며, 자체 데이터를 사용하여 비공개적으로 모델을 추가로 세부 조정하여 모델의 응답을 사용 사례 요구 사항에 맞출 수 있습니다. Amazon Bedrock은 단일 API를 통해 사용 가능한 모델에 대한 액세스 확장을 관리하기 위한 기본 인프라가 없는 완전한 서버리스입니다. 마지막으로 Amazon Bedrock은 HIPAA 자격 및 GDPR 규정 준수를 포함한 여러 보안 및 개인 정보 보호 요구 사항을 지원합니다.

Q4의 솔루션에서는 Amazon Bedrock을 서버리스, API 기반, 다중 기반 모델 빌딩 블록으로 사용합니다. 동일한 사용 사례 내에서 LLM을 여러 번 방문할 예정이므로 작업 유형에 따라 SQL 생성, 검증 또는 요약 등 특정 작업에 가장 적합한 모델을 선택할 수 있습니다.

랭체인

랭체인 FM, 데이터 소스 및 도구 간의 작업을 통합하고 조정하는 데 사용할 수 있는 사전 구축된 모듈(I/O, 검색, 체인 및 에이전트) 세트가 포함된 오픈 소스 통합 및 조정 프레임워크입니다. 이 프레임워크는 처음부터 코드를 작성할 필요 없이 원하는 출력을 생성하기 위해 여러 단계를 조율해야 하는 생성적 AI 애플리케이션 구축을 용이하게 합니다. LangChain은 Amazon Bedrock을 다중 기반 모델 API로 지원합니다.

Q4의 사용 사례와 관련하여 우리는 데이터 소스 및 LLM 연결을 포함하여 워크플로에서 작업을 조정하고 조정하기 위해 LangChain을 사용합니다. 이 접근 방식은 기존 LangChain 모듈을 사용할 수 있기 때문에 코드를 단순화했습니다.

SQLDatabaseChain

SQLDatabaseChain langchain_experimental에서 가져올 수 있는 LangChain 체인입니다. SLDatabaseChain은 효과적인 텍스트-SQL 변환 및 구현을 사용하여 SQL 쿼리를 간단하게 생성, 구현 및 실행합니다.

사용 사례에서는 SQL 생성에 SQLDatabaseChain을 사용하여 데이터베이스와 LLM 간의 상호 작용을 단순화하고 조정합니다.

데이터 세트

우리의 구조화된 데이터 세트는 SQL을 지원하는 한 SQL 데이터베이스, 데이터 레이크 또는 데이터 웨어하우스에 상주할 수 있습니다. 우리 솔루션에서는 SQL을 지원하는 모든 데이터 세트 유형을 사용할 수 있습니다. 이는 솔루션에서 추상화되어야 하며 어떤 방식으로든 솔루션을 변경해서는 안 됩니다.

구현 세부 사항

이제 솔루션 접근 방식, 솔루션 구성 요소, 기술 선택 및 도구를 살펴보았으므로 각 부분을 하나로 모을 수 있습니다. 다음 다이어그램은 엔드투엔드 솔루션을 강조합니다.

엔드투엔드 솔루션 아키텍처

구현 세부정보와 프로세스 흐름을 살펴보겠습니다.

SQL 쿼리 생성

코딩을 단순화하기 위해 기존 프레임워크를 사용합니다. 우리는 LangChain을 오케스트레이션 프레임워크로 사용합니다. 자연어로 사용자 질문을 받는 입력 단계부터 시작합니다.

첫 번째 단계에서는 이 입력을 받아 컨텍스트 추출을 위해 데이터베이스에 대해 실행할 수 있는 동등한 SQL을 생성합니다. SQL을 생성하기 위해 우리는 원하는 LLM에 액세스하기 위해 Amazon Bedrock을 사용하는 SQLDatabaseChain을 사용합니다. Amazon Bedrock에서는 단일 API를 사용하여 여러 기본 LLM에 액세스하고 각 LLM 여행에 적합한 LLM을 선택할 수 있습니다. 먼저 데이터베이스에 대한 연결을 설정하고 사용하려는 테이블의 일부 샘플 행과 함께 필요한 테이블 스키마를 검색합니다.

테스트에서 불필요한 오버헤드를 너무 많이 추가하지 않고도 모델에 충분한 정보를 제공하는 데 테이블 데이터 행이 2~5개면 충분하다는 사실을 발견했습니다. 세 개의 행은 너무 많은 입력으로 모델을 압도하지 않으면서 컨텍스트를 제공하기에 충분했습니다. 우리의 사용 사례에서는 Anthropic으로 시작했습니다. 클로드 V2. 이 모델은 올바른 맥락과 지침이 제공될 때 고급 추론과 명료한 맥락 반응으로 잘 알려져 있습니다. 지침의 일부로 LLM에 대한 보다 명확한 세부 정보를 포함할 수 있습니다. 예를 들어, 해당 열을 설명할 수 있습니다. Comp_NAME 회사 이름을 의미합니다. 이제 사용자 질문을 있는 그대로 결합하여 프롬프트를 구성할 수 있습니다. 데이터베이스 스키마, 사용하려는 테이블의 세 가지 샘플 행, 주석이나 추가 없이 깨끗한 SQL 형식으로 필요한 SQL을 생성하기 위한 지침 세트를 결합합니다.

결합된 모든 입력 요소는 모델 입력 프롬프트로 간주됩니다. 모델이 선호하는 구문에 맞춰 잘 설계된 입력 프롬프트는 출력의 품질과 성능 모두에 큰 영향을 미칩니다. 특정 작업에 사용할 모델을 선택하는 것도 중요합니다. 이는 출력 품질에 영향을 미칠 뿐만 아니라 비용 및 성능에도 영향을 미치기 때문입니다.

이 게시물의 뒷부분에서 모델 선택과 프롬프트 엔지니어링 및 최적화에 대해 논의하지만, 쿼리 생성 단계에서 Claude Instant가 특히 사용자 질문이 정교하지 않고 잘 표현된 경우에 비슷한 결과를 생성할 수 있다는 점에 주목할 가치가 있습니다. 그러나 Claude V2는 더 복잡하고 간접적인 사용자 입력으로도 더 나은 결과를 얻었습니다. 우리는 어떤 경우에는 클로드 인스턴트 더 나은 대기 시간과 가격대에서 충분한 정확도를 제공할 수 있으므로 쿼리 생성에 대한 사례는 Claude V2에 더 적합했습니다.

SQL 쿼리 확인

다음 단계는 LLM이 올바른 쿼리 구문을 성공적으로 생성했는지, 제공된 데이터베이스 스키마와 예제 행을 고려하여 쿼리가 상황에 맞는지 확인하는 것입니다. 이 확인 단계에서는 SQLDatabaseChain 내의 기본 쿼리 유효성 검사로 되돌리거나 유효성 검사 지침과 함께 생성된 쿼리를 포함하여 LLM으로 두 번째 여행을 실행할 수 있습니다.

검증 단계에 LLM을 사용하는 경우 이전과 동일한 LLM(Claude V2)을 사용하거나 Claude Instant와 같이 더 간단한 작업을 위해 더 작고 성능이 더 뛰어난 LLM을 사용할 수 있습니다. 우리는 Amazon Bedrock을 사용하고 있기 때문에 조정이 매우 간단할 것입니다. 동일한 API를 사용하여 변경 사항을 처리하는 API 호출에서 모델 이름을 변경할 수 있습니다. 대부분의 경우 LLM이 작을수록 비용과 대기 시간 측면에서 더 나은 효율성을 제공할 수 있으므로 원하는 정확도를 얻는 한 이를 고려해야 합니다. 우리의 경우 테스트를 통해 생성된 쿼리가 일관되게 정확하고 올바른 구문을 사용하는 것으로 입증되었습니다. 이를 알고 우리는 이 검증 단계를 건너뛰고 대기 시간과 비용을 절약할 수 있었습니다.

SQL 쿼리 실행

이제 확인된 SQL 쿼리가 있으므로 데이터베이스에 대해 SQL 쿼리를 실행하고 관련 컨텍스트를 검색할 수 있습니다. 이는 간단한 단계여야 합니다.

생성된 컨텍스트를 가져와 초기 사용자 질문 및 일부 지침과 함께 선택한 LLM에 제공하고 모델에 컨텍스트적이고 명확한 요약을 생성하도록 요청합니다. 그런 다음 생성된 요약을 초기 질문에 대한 답변으로 사용자에게 제시합니다. 모두 데이터 세트에서 추출된 컨텍스트와 일치합니다.

요약 단계와 관련된 LLM의 경우 Titan Text Express 또는 Claude Instant를 사용할 수 있습니다. 둘 다 요약 작업에 대한 좋은 옵션을 제시합니다.

애플리케이션 통합

Q&A 챗봇 기능은 Q4의 AI 서비스 중 하나입니다. 모듈성과 확장성을 보장하기 위해 Q4는 API를 통해 Q4 애플리케이션에 액세스할 수 있는 마이크로서비스로 AI 서비스를 구축합니다. 이 API 기반 접근 방식을 통해 Q4 플랫폼 생태계와 원활하게 통합되고 AI 서비스 기능을 전체 플랫폼 애플리케이션 제품군에 쉽게 노출할 수 있습니다.

AI 서비스의 주요 목적은 자연어를 입력으로 사용하여 공개 또는 독점 데이터 소스에서 데이터를 검색할 수 있는 간단한 기능을 제공하는 것입니다. 또한 AI 서비스는 데이터 개인 정보 보호 및 보안과 같은 기능적 및 비기능적 요구 사항이 충족되도록 추가 추상화 계층을 제공합니다. 다음 다이어그램은 통합 개념을 보여줍니다.

애플리케이션 통합 이미지

구현 과제

앞서 논의한 구조화된 수치 데이터 세트의 특성으로 인해 발생하는 문제 외에도 4분기에는 해결해야 할 여러 가지 구현 문제에 직면했습니다.

LLM 선택 및 성과

작업에 적합한 LLM을 선택하는 것은 출력 품질과 성능(왕복 대기 시간)에 직접적인 영향을 미치기 때문에 매우 중요합니다. LLM 선택 과정에 영향을 미치는 몇 가지 요소는 다음과 같습니다.

LLM 유형 – FM의 설계 방식과 모델이 사전 훈련된 초기 데이터에 따라 LLM이 잘할 수 있는 작업 유형과 그 성능이 결정됩니다. 예를 들어, 텍스트 LLM은 텍스트 생성 및 요약에 적합한 반면, 텍스트-이미지 또는 이미지-텍스트 모델은 이미지 분석 및 생성 작업에 더 적합합니다.
LLM 크기 – FM 크기는 특정 모델이 가지고 있는 모델 매개변수의 수로 측정되며, 일반적으로 현대 LLM의 경우 수십억 단위입니다. 일반적으로 모델이 클수록 초기 학습이나 이후 미세 조정 비용이 더 많이 듭니다. 반면에 일반적으로 동일한 모델 아키텍처의 경우 모델이 클수록 해당 작업 유형을 수행하는 데 더 똑똑할 것으로 기대합니다.
LLM 성과 – 일반적으로 동일한 컴퓨팅 및 I/O 매개변수(프롬프트 및 출력 크기)를 사용한다고 가정할 때 모델이 클수록 출력을 생성하는 데 더 많은 시간이 걸립니다. 또한 동일한 모델 크기의 경우 프롬프트 최적화 정도, I/O 토큰 크기, 프롬프트의 명확성과 구문에 따라 성능이 크게 영향을 받습니다. 최적화된 I/O 토큰 크기와 함께 잘 설계된 프롬프트는 모델 응답 시간을 향상시킬 수 있습니다.

따라서 작업을 최적화할 때 다음 모범 사례를 고려하십시오.

현재 작업에 적합한 모델을 선택하세요
원하는 정확도를 생성할 수 있는 가장 작은 모델 크기를 선택하세요.
프롬프트 구조를 최적화하고 모델이 이해하기 쉬운 방식으로 지침을 최대한 구체적으로 작성하세요.
원하는 정확도 수준을 달성하는 데 충분한 지침과 컨텍스트를 제공할 수 있는 가장 작은 입력 프롬프트를 사용하세요.
출력 크기를 의미 있는 가장 작은 크기로 제한하고 출력 요구 사항을 충족하십시오.

모델 선택 및 성능 최적화 요소를 고려하여 SQL 생성 사용 사례를 최적화하기 위해 노력했습니다. 몇 가지 테스트를 거친 후 올바른 컨텍스트와 지침이 있는 경우 Claude Instant는 동일한 프롬프트 데이터를 사용하여 훨씬 더 나은 성능과 가격으로 Claude V2와 비슷한 품질의 SQL을 생성할 수 있다는 사실을 알아냈습니다. 이는 사용자 입력이 본질적으로 더 직접적이고 단순할 때 적용됩니다. 보다 정교한 입력을 위해서는 원하는 정확도를 생성하기 위해 Claude V2가 필요했습니다.

요약 작업에 동일한 논리를 적용하면 Claude Instant 또는 Titan Text Express를 사용하면 Claude V2와 같은 더 큰 모델을 사용하는 경우보다 훨씬 더 나은 성능 지점에서 필요한 정확도를 얻을 수 있다는 결론을 내릴 수 있습니다. Titan Text Expressed는 앞서 논의한 것처럼 더 나은 가격 대비 성능도 제공했습니다.

오케스트레이션 챌린지

우리는 사용자 질문에 대한 의미 있는 출력 응답을 얻으려면 조정해야 할 것이 많다는 것을 깨달았습니다. 솔루션 개요에 표시된 것처럼 프로세스에는 여러 데이터베이스 여행과 여러 LLM 여행이 얽혀 있었습니다. 처음부터 새로 구축하려면 기본 코드를 준비하는 것만으로도 획일적인 무거운 작업에 상당한 투자를 해야 했을 것입니다. 우리는 LangChain을 오케스트레이션 프레임워크로 사용하고, 오픈 소스 커뮤니티의 힘을 활용하고, 바퀴를 재발명하지 않고 기존 모듈을 재사용하는 방향으로 빠르게 전환했습니다.

SQL 과제

또한 우리는 SQL 생성이 의미 검색이나 임베딩 사용과 같은 컨텍스트 추출 메커니즘만큼 간단하지 않다는 것을 깨달았습니다. 먼저 LLM에 대한 프롬프트에 포함할 데이터베이스 스키마와 몇 가지 샘플 행을 가져와야 합니다. 데이터베이스와 LLM 모두와 상호 작용해야 하는 SQL 유효성 검사 단계도 있습니다. SQLDatabaseChain은 확실한 도구 선택이었습니다. LangChain의 일부이기 때문에 적응하기가 쉬웠고 이제 체인을 통해 SQL 생성 및 검증을 관리할 수 있어 수행해야 하는 작업량이 최소화됩니다.

성능 문제

Claude V2를 사용하고 적절한 프롬프트 엔지니어링(다음 섹션에서 논의) 후 고품질 SQL을 생성할 수 있었습니다. 생성된 SQL의 품질을 고려하여 검증 단계가 실제로 얼마나 많은 가치를 추가하는지 살펴보기 시작했습니다. 결과를 추가로 분석한 결과, 생성된 SQL의 품질은 SQL 검증 단계 추가에 따른 비용/이점을 불리하게 만드는 방식으로 일관되게 정확하다는 것이 분명해졌습니다. 결국 우리는 출력 품질에 부정적인 영향을 주지 않고 SQL 검증 단계를 제거하고 SQL 검증 왕복 시간을 줄였습니다.

요약 단계에서 보다 비용 및 성능 효율적인 LLM을 최적화하는 것 외에도 Titan Text Express를 사용하여 더 나은 성능과 비용 효율성을 얻을 수 있었습니다.

추가적인 성능 최적화에는 효율적인 프롬프트 엔지니어링 기술을 사용하여 쿼리 생성 프로세스를 미세 조정하는 작업이 포함되었습니다. 풍부한 토큰을 제공하는 대신, 모델이 이해하도록 훈련된 올바른 구문과 최소이면서도 최적의 명령 세트로 최소한의 입력 토큰을 제공하는 데 중점을 두었습니다. 이에 대해서는 다음 섹션에서 자세히 논의합니다. 이는 여기뿐만 아니라 다른 사용 사례에도 적용할 수 있는 중요한 주제입니다.

신속한 엔지니어링 및 최적화

올바른 프롬프트 엔지니어링 기술을 사용하는 경우 Amazon Bedrock의 Claude를 다양한 비즈니스 사용 사례에 맞게 조정할 수 있습니다. Claude는 인간/보조 형식을 활용한 대화 도우미 역할을 주로 수행합니다. Claude는 보조 역할에 대한 텍스트를 작성하도록 교육을 받았습니다. 원하는 지침과 프롬프트 완료가 주어지면 여러 기술을 사용하여 Claude에 대한 프롬프트를 최적화할 수 있습니다.

유효한 완료를 제공하는 적절한 형식의 프롬프트 템플릿으로 시작한 다음, 실제 데이터를 대표하는 다양한 입력 세트를 사용하여 실험하면서 응답을 더욱 최적화할 수 있습니다. 프롬프트 템플릿을 개발하는 동안 많은 입력을 얻는 것이 좋습니다. 프롬프트 개발 데이터와 테스트 데이터의 별도 세트를 사용할 수도 있습니다.

Claude 반응을 최적화하는 또 다른 방법은 규칙, 지침 및 내용을 추가하여 실험하고 반복하는 것입니다. 유용한 최적화. 이러한 최적화를 통해 클로드에게 환각을 방지하기 위해 "모르겠어요"라고 언급하라고 지시하고, 단계별로 생각하고, 프롬프트 체인을 사용하고, 응답을 생성할 때 "생각"할 공간을 제공하는 등 다양한 유형의 완료를 볼 수 있습니다. , 이해도와 정확성을 다시 확인합니다.

쿼리 생성 작업을 사용하여 프롬프트를 최적화하는 데 사용한 몇 가지 기술에 대해 논의해 보겠습니다. 쿼리 생성 노력에 도움이 된 몇 가지 핵심 요소는 다음과 같습니다.

적절한 인간/보조 구문 사용
XML 태그 활용(Claude는 XML 태그를 존중하고 이해합니다)
환각을 방지하기 위해 모델에 대한 명확한 지침 추가

다음 일반 예에서는 인간/보조 구문을 사용하고 XML 태그를 적용하고 명령을 추가하여 출력을 SQL로 제한하고 관련 SQL을 생성할 수 없는 경우 "죄송합니다. 도와드릴 수 없습니다"라고 모델에 지시하는 방법을 보여줍니다. . XML 태그는 지침, 추가 힌트, 데이터베이스 스키마, 추가 테이블 설명 및 예제 행을 구성하는 데 사용되었습니다.

"""Human: You are a SQL expert.
You are tasked to generate a SQL statement from the instruction provided. <instructions>
Understanding the input question, referencing the database schema, and reviewing
example rows, generate a SQL statement that represents the question.
</instructions> <database_schema> "here you can include your table schemas
</database_schema> <table_description> "Comp-Nam" stands for Company Name "Own-Hist" stand for Ownership history
</table_description> <example_rows> "here you can insert 2-5 sample database rows"
</example_rows> <question>
{input}
</question> <additional_hints>
In your response provide only SQL with no additional comments.
The SQL has to follow the proper database schema.
If the question is unrelated to the database or if you are
unable to generate relevant SQL,
say "sorry, I am unable to help".
Do not make up an answer
Do not answer with anything other than SQL
</additional_hints> Assistant: """

최종 작업 솔루션

개념 증명 중에 확인된 모든 과제를 해결한 후 모든 솔루션 요구 사항을 충족했습니다. Q4는 LLM에서 생성된 SQL의 품질에 만족했습니다. 이는 데이터를 필터링하기 위해 WHERE 절만 필요한 간단한 작업과 GROUP BY 및 수학 함수를 사용한 컨텍스트 기반 집계가 필요한 더 복잡한 작업의 경우에도 마찬가지입니다. 전체 솔루션의 엔드투엔드 대기 시간은 해당 사용 사례에 허용되는 것으로 정의된 한 자릿수 초 이내였습니다. 이는 모든 단계에서 최적의 LLM 선택, 적절한 프롬프트 엔지니어링, SQL 검증 단계 제거, 요약 단계에 효율적인 LLM(Titan Text Express 또는 Claude Instant) 사용 덕분이었습니다.

Amazon Bedrock을 완전 관리형 서비스로 사용하고 동일한 API를 통해 LLM 제품군에 액세스할 수 있는 기능을 사용하면 API 호출에서 모델 이름을 변경하여 LLM 간 실험과 원활한 전환이 가능해졌습니다. 이러한 수준의 유연성을 통해 Q4는 쿼리 생성, 확인 또는 요약 등 작업의 특성을 기반으로 각 LLM 호출에 대해 가장 성능이 좋은 LLM을 선택할 수 있었습니다.

결론

모든 사용 사례에 맞는 하나의 솔루션은 없습니다. RAG 접근 방식에서 출력 품질은 올바른 컨텍스트 제공에 크게 좌우됩니다. 올바른 컨텍스트를 추출하는 것이 중요하며 모든 데이터 세트는 고유한 특성으로 다릅니다.

이 게시물에서 우리는 숫자 및 구조화된 데이터 세트의 경우 SQL을 사용하여 증강에 사용되는 컨텍스트를 추출하면 더 유리한 결과를 얻을 수 있음을 보여주었습니다. 우리는 또한 LangChain과 같은 프레임워크가 코딩 노력을 최소화할 수 있음을 입증했습니다. 또한 가장 최적의 정확성, 성능 및 비용을 달성하기 위해 동일한 사용 사례 내에서 LLM 간에 전환할 수 있어야 한다는 필요성에 대해서도 논의했습니다. 마지막으로, 서버리스이며 내부적으로 다양한 LLM을 갖춘 Amazon Bedrock이 최소한의 노력으로 안전하고 성능이 뛰어나며 비용 최적화된 애플리케이션을 구축하는 데 필요한 유연성을 어떻게 제공하는지 강조했습니다.

비즈니스에 가치가 있는 사용 사례를 식별하여 생성적 AI 지원 애플리케이션을 구축하기 위한 여정을 시작하세요. 4분기 팀이 배운 것처럼 SQL 생성은 데이터 저장소와 통합되는 스마트 애플리케이션 구축에 있어 획기적인 변화가 되어 수익 잠재력을 실현할 수 있습니다.

저자 소개

테이머 솔리만 AWS의 수석 솔루션 아키텍트입니다. 그는 ISV(독립 소프트웨어 공급업체) 고객이 AWS에서 혁신, 구축 및 확장할 수 있도록 돕습니다. 그는 컨설팅, 교육 및 전문 서비스 분야에서 XNUMX년 이상의 업계 경험을 보유하고 있습니다. 그는 XNUMX개의 특허를 보유한 다중 특허 발명가이며 통신, 네트워킹, 애플리케이션 통합, AI/ML 및 클라우드 배포를 포함한 여러 기술 영역에 걸쳐 경험을 쌓았습니다. 그는 AWS 네트워킹을 전문으로 하며 기계 학습, AI 및 생성 AI에 대한 깊은 열정을 가지고 있습니다.

마니 카누 자 기술 리더이자 생성적 AI 전문가이고, Applied Machine Learning and High Performance Computing on AWS라는 책의 저자이며, 여성 제조업 교육 재단 이사회의 이사이기도 합니다. 그녀는 컴퓨터 비전, 자연어 처리, 생성 AI 등 다양한 영역에서 머신러닝(ML) 프로젝트를 이끌고 있습니다. 그녀는 고객이 대규모 기계 학습 모델을 대규모로 구축, 교육 및 배포할 수 있도록 지원합니다. 그녀는 re:Invent, Women in Manufacturing West, YouTube 웹 세미나, GHC 23 등의 내부 및 외부 컨퍼런스에서 연설합니다. 여가 시간에는 해변을 따라 장거리 달리기를 즐깁니다.

스타니슬라프 예셴코 Q4 Inc.의 소프트웨어 설계자입니다. 그는 소프트웨어 개발 및 시스템 아키텍처 분야에서 4년 이상의 업계 경험을 보유하고 있습니다. 기술 리드 및 수석 풀 스택 개발자와 같은 그의 다양한 배경 지식은 QXNUMX 플랫폼의 혁신을 발전시키는 데 기여합니다. Stanislav는 현장에서 기술 혁신을 주도하고 전략적 솔루션을 형성하는 데 전념하고 있습니다.

SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
PlatoData.Network 수직 생성 Ai. 자신에게 권한을 부여하십시오. 여기에서 액세스하십시오.
PlatoAiStream. 웹3 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
플라톤ESG. 탄소, 클린테크, 에너지, 환경, 태양광, 폐기물 관리. 여기에서 액세스하십시오.
PlatoHealth. 생명 공학 및 임상 시험 인텔리전스. 여기에서 액세스하십시오.
출처: https://aws.amazon.com/blogs/machine-learning/how-q4-inc-used-amazon-bedrock-rag-and-sqldatabasechain-to-address-numerical-and-structured-dataset-challenges-building-their-qa-chatbot/

생성 데이터 인텔리전스

Q4 Inc.가 Amazon Bedrock, RAG 및 SQLDatabaseChain을 사용하여 Q&A 챗봇 구축의 숫자 및 구조화된 데이터 세트 문제를 해결한 방법 | 아마존 웹 서비스