대화형 AI는 생성 AI의 급속한 발전, 특히 인간 피드백을 통한 강화 학습 및 지시 미세 조정과 같은 훈련 기술을 통해 도입된 대규모 언어 모델(LLM)의 성능 향상 덕분에 최근 몇 년 동안 큰 발전을 이루었습니다. 올바르게 메시지가 표시되면 이러한 모델은 작업별 교육 데이터 없이 일관된 대화를 전달할 수 있습니다. 그러나 답변을 생성하기 위해 사전 교육 중에 노출된 공개 데이터에 의존하기 때문에 기업별 질문에 잘 일반화할 수 없습니다. 이러한 데이터에는 현대 비즈니스에서 사용할 수 있는 내부 문서에 포함된 전문 ​​지식이 부족한 경우가 많습니다. 이는 일반적으로 제약 연구, 재무 조사, 고객 지원과 같은 영역에서 정확한 답변을 얻는 데 필요합니다.

전문적인 기업 지식을 바탕으로 토론할 수 있는 AI 도우미를 만들려면 이러한 강력하지만 일반적인 LLM을 문서의 내부 지식 기반에 연결해야 합니다. 내부 데이터 소스에서 검색된 정보로 LLM 생성 컨텍스트를 강화하는 이 방법을 RAG(검색 증강 생성)라고 하며 다음과 같이 도메인별로 더욱 신뢰할 수 있는 보조자를 생성합니다. 지식 집약적 NLP 작업을위한 검색 증강 생성. RAG의 인기를 뒷받침하는 또 다른 원동력은 구현의 용이성과 다음에서 제공하는 것과 같은 성숙한 벡터 검색 솔루션의 존재입니다. 아마존 켄드라 (참조 Amazon Kendra, 검색 API 출시) and 아마존 오픈서치 서비스 (참조 Amazon OpenSearch Service의 k-Nearest Neighbor(k-NN) 검색).

그러나 의미론적 검색을 사용하는 인기 있는 RAG 디자인 패턴은 문서에서 가능한 모든 유형의 질문에 답할 수 없습니다. 이는 여러 문서에 대한 분석적 추론이 필요한 질문의 경우 특히 그렇습니다. 예를 들어, 당신이 투자회사의 내년 전략을 계획하고 있다고 가정해보자. 한 가지 필수 단계는 후보 회사의 재무 결과와 잠재적 위험을 분석하고 비교하는 것입니다. 이 작업에는 분석적 추론 질문에 답하는 것이 포함됩니다. 예를 들어, "지난 5년 동안 가장 높은 수익을 올린 상위 2개 회사를 제시하고 주요 위험을 식별하십시오"라는 질문에는 여러 단계의 추론이 필요하며, 그 중 일부는 의미론적 검색 검색을 사용할 수 있는 반면 다른 일부는 분석 기능이 필요합니다.

이 게시물에서는 분석 및 다단계 추론 질문에 답할 수 있는 지능형 문서 도우미를 설계하는 방법을 세 부분으로 보여줍니다. 1부에서는 RAG 디자인 패턴과 분석 질문에 대한 제한 사항을 검토합니다. 그런 다음 이러한 제한을 극복하는 보다 다양한 아키텍처를 소개합니다. 2부에서는 분석적 질문 답변의 핵심 요소인 구조화된 데이터를 준비하는 데 사용되는 엔터티 추출 파이프라인에 대해 더 자세히 알아볼 수 있도록 도와줍니다. 3부에서는 사용 방법을 안내합니다. 아마존 기반암 LLM은 해당 데이터를 쿼리하고 분석 기능으로 RAG를 향상시키는 LLM 에이전트를 구축하여 여러 문서에 걸쳐 복잡한 도메인별 질문에 답할 수 있는 지능형 문서 도우미를 구축할 수 있도록 합니다.

1부: RAG 제한 사항 및 솔루션 개요

이 섹션에서는 RAG 디자인 패턴을 검토하고 분석 질문에 대한 제한 사항에 대해 논의합니다. 또한 이러한 한계를 극복하는 보다 다양한 아키텍처를 제시합니다.

RAG 개요

RAG 솔루션은 다음에서 영감을 받았습니다. 표현 학습 및 시맨틱 검색 2010년부터 순위 문제(예: 추천, 검색) 및 자연어 처리(NLP) 작업에 점진적으로 채택된 아이디어입니다.

오늘날 널리 사용되는 접근 방식은 세 가지 단계로 구성됩니다.

1. 오프라인 일괄 처리 작업은 입력 지식 베이스에서 문서를 수집하고, 이를 청크로 분할하고, 각 청크에 대한 임베딩을 생성하여 다음과 같은 사전 훈련된 임베딩 모델을 사용하여 해당 의미를 나타냅니다. 아마존 타이탄 임베딩 모델을 사용한 다음 이러한 임베딩을 입력으로 사용하여 의미 체계 검색 인덱스를 생성합니다.
   
2. 실시간으로 새로운 질문에 답할 때 입력된 질문은 임베딩으로 변환되는데, 이는 코사인 유사도와 같은 유사성 메트릭 및 근사 최근접 이웃 알고리즘을 사용하여 가장 유사한 문서 덩어리를 검색하고 추출하는 데 사용됩니다. 메타데이터 필터링을 통해 검색 정밀도를 향상할 수도 있습니다.
   
3. 프롬프트는 2단계에서 추출된 관련 문서 덩어리로 구성된 컨텍스트와 입력 질문 자체를 시스템 메시지와 연결하여 구성됩니다. 그런 다음 이 프롬프트는 LLM 모델에 제시되어 컨텍스트에서 질문에 대한 최종 답변을 생성합니다.
   

입력 문서 덩어리와 입력 질문의 정확한 의미론적 표현을 생성할 수 있는 올바른 기본 임베딩 모델과 효율적인 의미론적 검색 모듈을 통해 이 솔루션은 문서 데이터베이스에서 기존 정보를 검색해야 하는 질문에 답할 수 있습니다. 예를 들어, 서비스나 제품이 있는 경우 FAQ 섹션이나 문서를 색인화하여 시작하고 특정 제품에 맞는 초기 대화형 AI를 가질 수 있습니다.

의미 검색 기반 RAG의 한계

RAG는 ​​최신 도메인별 AI 도우미의 필수 구성 요소이자 전문 지식 기반을 중심으로 대화형 AI를 구축하기 위한 합리적인 출발점이지만 지식 기반의 모든 문서를 스캔, 비교 및 ​​추론해야 하는 질문에 답할 수는 없습니다. 동시에, 특히 확장이 의미론적 검색에만 기반을 둔 경우 더욱 그렇습니다.

이러한 한계를 이해하기 위해 재무 보고서를 기반으로 어디에 투자할지 결정하는 예를 다시 생각해 보겠습니다. RAG를 사용하여 이러한 보고서와 대화한다면 "2022년 X 회사가 직면한 위험은 무엇입니까?" 또는 "2022년 Y 회사의 순이익은 얼마입니까?"와 같은 질문을 할 수 있습니다. 이러한 각 질문에 대해 질문의 의미론적 의미를 인코딩하는 해당 임베딩 벡터는 검색 인덱스에서 사용할 수 있는 의미론적으로 유사한 상위 K 문서 덩어리를 검색하는 데 사용됩니다. 이는 일반적으로 다음과 같은 대략적인 최근접 이웃 솔루션을 사용하여 수행됩니다. FAISS, NMSLIB, pgVector 또는 기타, 만족스러운 정확성을 유지하면서 실시간 성능을 달성하기 위해 검색 속도와 리콜 사이의 균형을 유지하려고 노력합니다.

그러나 이전 접근 방식은 "5년에 순수익이 가장 높은 상위 2022개 회사는 무엇입니까?"와 같은 모든 문서에 대한 분석 질문에 정확하게 대답할 수 없습니다.

이는 의미 검색 검색이 입력 질문과 가장 유사한 K개의 문서 덩어리를 찾으려고 시도하기 때문입니다. 그러나 어떤 문서에도 수익에 대한 포괄적인 요약이 포함되어 있지 않기 때문에 수익이 가장 높은 회사에 초점을 맞추는 필수 조건을 충족하지 않고 "순 수익" 및 "2022년"이라는 언급만 포함된 문서 덩어리가 반환됩니다. 입력 질문에 답변하기 위한 컨텍스트로 이러한 검색 결과를 LLM에 제시하면 필요한 올바른 정보가 누락되어 오해의 소지가 있는 답변을 공식화하거나 답변을 거부할 수 있습니다.

의미론적 검색은 관련 문서를 찾기 위해 모든 임베딩 벡터를 철저히 스캔하지 않기 때문에 이러한 제한은 의도적으로 발생합니다. 대신, 합리적인 검색 속도를 유지하기 위해 대략적인 최근접 이웃 방법을 사용합니다. 이러한 방법의 효율성을 위한 핵심 전략은 인덱싱 중에 임베딩 공간을 그룹으로 분할하는 것입니다. 이를 통해 쌍별 비교 없이 검색 중에 관련 임베딩을 포함할 수 있는 그룹을 빠르게 식별할 수 있습니다. 또한 모든 문서를 스캔하는 KNN과 같은 기존의 최근접 이웃 기술도 기본 거리 측정법만 계산하므로 분석적 추론에 필요한 복잡한 비교에는 적합하지 않습니다. 따라서 의미 검색 기능이 있는 RAG는 모든 문서에 걸쳐 분석적 추론이 포함된 질문에 답하는 데 적합하지 않습니다.

이러한 한계를 극복하기 위해 다음 섹션에 설명된 대로 RAG를 메타데이터 및 엔터티 추출, SQL 쿼리 및 LLM 에이전트와 결합하는 솔루션을 제안합니다.

메타데이터, SQL 및 LLM 에이전트를 통해 RAG 제한 극복

RAG가 실패하는 질문에 대해 더 자세히 조사하여 이 질문에 효과적으로 대답하는 데 필요한 추론을 추적해 보겠습니다. 이 분석을 통해 전체 솔루션에서 RAG를 보완할 수 있는 올바른 접근 방식을 찾을 수 있습니다.

다음 질문을 고려해보세요: “5년에 매출이 가장 높은 상위 2022개 회사는 무엇입니까?”

이 질문에 대답하려면 다음을 수행해야 합니다.

1. 각 회사의 수익을 확인합니다.
2. 필터링하여 각각의 2022년 수익을 유지합니다.
3. 수익을 내림차순으로 정렬합니다.
4. 회사 이름과 함께 상위 5개 수익을 구분합니다.

일반적으로 이러한 분석 작업은 Pandas 또는 SQL 엔진과 같은 도구를 사용하여 구조화된 데이터에 대해 수행됩니다. 열이 포함된 SQL 테이블에 액세스할 수 있는 경우 company, revenue및 year, 다음 예와 유사한 SQL 쿼리를 실행하여 질문에 쉽게 답할 수 있습니다.

SELECT company, revenue FROM table_name WHERE year = 2022 ORDER BY revenue DESC LIMIT 5;

관련 엔터티에 대한 정보가 포함된 SQL 테이블에 구조화된 메타데이터를 저장하면 올바른 SQL 쿼리를 작성하여 다양한 유형의 분석 질문에 답할 수 있습니다. 이것이 바로 우리가 오프라인 프로세스에서 추출한 메타데이터로 채워진 SQL 테이블에 대한 실시간 SQL 쿼리 모듈을 사용하여 솔루션의 RAG를 보완하는 이유입니다.

하지만 LLM 기반 대화형 AI에 대한 이러한 접근 방식을 어떻게 구현하고 통합할 수 있을까요?

SQL 분석 추론을 추가하려면 세 가지 단계가 있습니다.

• 메타데이터 추출 – 구조화되지 않은 문서의 메타데이터를 SQL 테이블로 추출
• 텍스트를 SQL로 – LLM을 사용하여 입력 질문에서 SQL 쿼리를 정확하게 공식화합니다.
• 도구 선택 – RAG 또는 SQL 쿼리를 사용하여 질문에 답변해야 하는지 식별

이러한 단계를 구현하기 위해 먼저 구조화되지 않은 문서에서 정보를 추출하는 것은 LLM이 제로 샷 또는 소수 샷 학습을 통해 높은 정확도를 달성할 수 있는 가능성을 보여주는 전통적인 NLP 작업이라는 것을 인식합니다. 둘째, 자연어에서 SQL 쿼리를 생성하는 이러한 모델의 능력은 다음에서 볼 수 있듯이 수년 동안 입증되었습니다. 2020 릴리스 of 아마존 퀵사이트 Q. 마지막으로 특정 질문에 적합한 도구를 자동으로 선택하면 사용자 경험이 향상되고 다단계 추론을 통해 복잡한 질문에 답할 수 있습니다. 이 기능을 구현하기 위해 이후 섹션에서 LLM 에이전트를 자세히 살펴보겠습니다.

요약하자면, 우리가 제안하는 솔루션은 다음과 같은 핵심 구성 요소로 구성됩니다.

• 생성 컨텍스트를 확대하기 위한 의미론적 검색 검색
• SQL을 사용한 구조화된 메타데이터 추출 및 쿼리
• 질문에 답하기 위해 올바른 도구를 사용할 수 있는 상담원

솔루션 개요

다음 다이어그램은 솔루션의 단순화된 아키텍처를 보여줍니다. 이는 핵심 구성 요소의 역할과 전체 LLM 지원 동작을 구현하기 위해 상호 작용하는 방식을 식별하고 이해하는 데 도움이 됩니다. 번호 매기기는 이 솔루션을 구현할 때 작업 순서에 따라 정렬됩니다.

실제로 우리는 다음 세부 아키텍처에 설명된 대로 이 솔루션을 구현했습니다.

이 아키텍처의 경우 다음 구현을 제안합니다. GitHub의, 백엔드(5), 데이터 파이프라인(1, 2, 3) 및 프런트 엔드(4)가 별도로 발전할 수 있는 느슨하게 결합된 구성 요소를 사용합니다. 이는 생산용 솔루션을 사용자 정의하고 개선할 때 역량 전반의 협업을 단순화하기 위한 것입니다.

솔루션 배포

AWS 계정에 이 솔루션을 설치하려면 다음 단계를 완료하십시오.

1. 클론 GitHub의 저장소.
2. 백엔드 설치 AWS 클라우드 개발 키트 (AWS 씨디케이) 앱:
   1. 열기 backend 폴더에 있습니다.
   2. 달리기 npm install 종속성을 설치합니다.
   3. 현재 계정 및 리전에서 AWS CDK를 사용한 적이 없는 경우 다음을 실행합니다. 부트 스트랩 과 npx cdk bootstrap.
   4. 달리기 npx cdk deploy 스택을 배포합니다.
3. 선택적으로 다음을 실행합니다. streamlit-ui 다음과 같이 :
   1. 이 저장소를 아마존 세이지 메이커 스튜디오 환경. 자세한 내용은 다음을 참조하세요. 빠른 설정을 사용하여 Amazon SageMaker 도메인에 온보딩.
   2. 내부 frontend/streamlit-ui 폴더, 실행 bash run-streamlit-ui.sh.
   3. 데모를 열려면 다음 형식의 링크를 선택하세요. https://{domain_id}.studio.{region}.sagemaker.aws/jupyter/default/proxy/{port_number}/.
4. 마지막으로 다음을 실행할 수 있습니다. 아마존 세이지 메이커 파이프라인은 data-pipelines/04-sagemaker-pipeline-for-documents-processing.ipynb 입력된 PDF 문서를 처리하고 LLM 보조자가 사용하는 SQL 테이블과 의미 검색 색인을 준비하는 노트북입니다.

이 게시물의 나머지 부분에서는 가장 중요한 구성 요소와 디자인 선택 사항을 설명하는 데 중점을 두고 내부 지식 기반에서 자신만의 AI 도우미를 디자인할 때 영감을 주기를 바랍니다. 우리는 구성 요소 1과 4가 이해하기 쉽다고 가정하고 핵심 구성 요소 2, 3, 5에 중점을 둡니다.

2부: 엔터티 추출 파이프라인

이 섹션에서는 분석적 질문 답변의 핵심 요소인 구조화된 데이터를 준비하는 데 사용되는 엔터티 추출 파이프라인에 대해 자세히 알아봅니다.

텍스트 추출

문서는 일반적으로 PDF 형식이나 스캔한 이미지로 저장됩니다. 간단한 단락 레이아웃이나 복잡한 표로 구성될 수 있으며 디지털 또는 손으로 쓴 텍스트를 포함할 수 있습니다. 정보를 올바르게 추출하려면 이러한 원본 문서를 원래 구조를 유지하면서 일반 텍스트로 변환해야 합니다. 이렇게 하려면 다음을 사용할 수 있습니다. 아마존 텍사스는 디지털 및 필기 입력에서 텍스트, 표, 양식 추출을 위한 성숙한 API를 제공하는 기계 학습(ML) 서비스입니다.

구성 요소 2에서는 다음과 같이 텍스트와 표를 추출합니다.

1. 각 문서에 대해 Amazon Textract를 호출하여 텍스트와 표를 추출합니다.
2. 우리는 다음을 사용합니다 파이썬 스크립트 테이블을 Pandas DataFrame으로 다시 생성합니다.
3. 결과를 단일 문서로 통합하고 표를 마크다운으로 삽입합니다.

이 프로세스는 다음 흐름도에 요약되어 있으며 구체적으로 설명되어 있습니다. notebooks/03-pdf-document-processing.ipynb.

LLM을 사용한 엔터티 추출 및 쿼리

분석 질문에 효과적으로 답하려면 문서의 지식 기반에서 관련 메타데이터와 엔터티를 액세스 가능한 구조화된 데이터 형식으로 추출해야 합니다. 인기, 사용 용이성 및 확장성으로 인해 SQL을 사용하여 이 정보를 저장하고 답변을 검색하는 것이 좋습니다. 이 선택은 또한 자연어에서 SQL 쿼리를 생성하는 검증된 언어 모델의 기능으로부터 이점을 얻습니다.

이 섹션에서는 분석 질문을 가능하게 하는 다음 구성 요소에 대해 자세히 알아봅니다.

• LLM을 사용하여 비정형 데이터에서 정형 데이터를 추출하는 일괄 프로세스
• 자연어 질문을 SQL 쿼리로 변환하고 SQL 데이터베이스에서 결과를 검색하는 실시간 모듈

다음과 같이 분석 질문을 지원하기 위해 관련 메타데이터를 추출할 수 있습니다.

1. 각 필드에 대한 설명과 해당 데이터 유형을 포함하고 예상 값의 예를 포함하는 추출해야 하는 정보에 대한 JSON 스키마를 정의합니다.
2. 각 문서에 대해 JSON 스키마를 사용하여 LLM에 메시지를 표시하고 관련 데이터를 정확하게 추출하도록 요청하세요.
3. 문서 길이가 컨텍스트 길이를 초과하는 경우 LLM을 사용한 추출 비용을 줄이기 위해 의미론적 검색을 사용하여 추출 중에 관련 문서 덩어리를 검색하고 LLM에 제공할 수 있습니다.
4. JSON 출력을 구문 분석하고 LLM 추출의 유효성을 검사합니다.
5. 선택적으로 Amazon S3의 결과를 CSV 파일로 백업합니다.
6. 나중에 쿼리하기 위해 SQL 데이터베이스에 로드합니다.

이 프로세스는 다음 아키텍처로 관리됩니다. 여기서 텍스트 형식의 문서는 다음에서 실행되는 Python 스크립트로 로드됩니다. Amazon SageMaker 처리 추출을 수행하는 작업입니다.

각 엔터티 그룹에 대해 정보 추출 작업에 대한 명확한 설명을 포함하고 예상 출력을 정의하며 관련 문서 청크를 컨텍스트로 포함하는 JSON 스키마를 포함하는 프롬프트를 동적으로 구성합니다. 또한 퓨샷 학습으로 추출 성능을 향상시키기 위해 입력 및 올바른 출력의 몇 가지 예를 추가합니다. 이는 다음에서 설명됩니다. notebooks/05-entities-extraction-to-structured-metadata.ipynb.

3부: Amazon Bedrock을 사용하여 에이전트 문서 도우미 구축

이 섹션에서는 Amazon Bedrock LLM을 사용하여 데이터를 쿼리하고 분석 기능으로 RAG를 향상시키는 LLM 에이전트를 구축하여 여러 문서에 걸쳐 복잡한 도메인별 질문에 답할 수 있는 지능형 문서 도우미를 구축하는 방법을 보여줍니다. 당신은 GitHub의 Lambda 함수 이 부분에 설명된 에이전트 및 도구의 구체적인 구현을 위해.

SQL 쿼리를 공식화하고 분석 질문에 답하세요.

이제 관련 엔터티가 추출되어 쿼리할 수 있는 SQL 데이터베이스에 로드된 구조화된 메타데이터 저장소가 있으므로 남은 질문은 입력 자연어 질문에서 올바른 SQL 쿼리를 생성하는 방법입니다.

최신 LLM은 SQL 생성에 능숙합니다. 예를 들어, Anthropic Claude LLM에서 다음을 통해 요청하는 경우 아마존 기반암 SQL 쿼리를 생성하면 그럴듯한 답변이 표시됩니다. 그러나 보다 정확한 SQL 쿼리에 도달하려면 프롬프트를 작성할 때 몇 가지 규칙을 준수해야 합니다. 이러한 규칙은 환각 및 구문 오류를 줄이기 위한 복잡한 쿼리에 특히 중요합니다.

• 프롬프트 내에서 작업을 정확하게 설명하세요.
• 테이블의 각 열을 설명하고 해당 데이터 유형을 지정하는 동안 프롬프트 내에 SQL 테이블의 스키마를 포함합니다.
• 기존 열 이름과 데이터 유형만 사용하도록 LLM에 명시적으로 지시합니다.
• SQL 테이블의 몇 행 추가

또한 생성된 SQL 쿼리를 다음을 사용하여 사후 처리할 수도 있습니다. linter 등 SQL플러프 형식을 수정하려면 다음과 같은 파서를 사용하세요. sqlglot 구문 오류를 감지하고 쿼리를 최적화합니다. 또한 성능이 요구 사항을 충족하지 못하는 경우 프롬프트 내에 몇 가지 예를 제공하여 보다 정확한 SQL 쿼리를 생성하는 방향으로 퓨샷 학습을 통해 모델을 조정할 수 있습니다.

구현 관점에서 우리는 AWS 람다 기능을 사용하여 다음 프로세스를 조정합니다.

1. 해당 SQL 쿼리를 얻으려면 입력 질문으로 Amazon Bedrock에서 Anthropic Claude 모델을 호출하세요. 여기서는 SQL데이터베이스 관련 SQL 테이블의 스키마 설명을 추가하고 사용자 정의 프롬프트를 사용하려면 LangChain의 클래스를 사용하세요.
2. SQL 쿼리를 구문 분석, 검증 및 실행합니다. Amazon Aurora PostgreSQL 호환 에디션 데이터 베이스.

솔루션의 이 부분에 대한 아키텍처는 다음 다이어그램에 강조되어 있습니다.

SQL 주입 공격을 방지하기 위한 보안 고려 사항

AI 도우미가 SQL 데이터베이스에 쿼리할 수 있도록 하려면 이로 인해 보안 취약점이 발생하지 않는지 확인해야 합니다. 이를 위해 우리는 SQL 주입 공격을 방지하기 위해 다음과 같은 보안 조치를 제안합니다.

• 최소 권한 IAM 권한 적용 – SQL 쿼리를 실행하는 Lambda 함수의 권한을 제한합니다. AWS 자격 증명 및 액세스 관리 (IAM) 정책과 역할은 다음과 같습니다. 최소 권한 원칙. 이 경우 읽기 전용 액세스 권한을 부여합니다.
• 데이터 액세스 제한 – 정보 유출 공격을 방지하기 위해 최소한의 테이블과 열에만 액세스를 제공합니다.
• 조정 레이어 추가 – 신속한 주입 시도를 조기에 감지하고 시스템의 나머지 부분으로 전파되는 것을 방지하는 조정 계층을 도입합니다. 이는 규칙 기반 필터, 알려진 프롬프트 삽입 예제 데이터베이스에 대한 유사성 일치 또는 ML 분류기의 형태를 취할 수 있습니다.

생성 컨텍스트를 확대하기 위한 의미론적 검색 검색

우리가 제안하는 솔루션은 구성 요소 3에서 의미 체계 검색과 함께 RAG를 사용합니다. 다음을 사용하여 이 모듈을 구현할 수 있습니다. Amazon Bedrock에 대한 지식 기반. 또한 RAG를 구현하는 데는 다음과 같은 다양한 옵션이 있습니다. Amazon Kendra 검색 API, Amazon OpenSearch 벡터 데이터베이스및 pgVector를 사용하는 Amazon Aurora PostgreSQL, 무엇보다도. 오픈소스 패키지 aws-genai-llm-chatbot LLM 기반 챗봇을 구현하기 위해 이러한 벡터 검색 옵션 중 다수를 사용하는 방법을 보여줍니다.

이 솔루션에서는 SQL 쿼리와 벡터 검색이 모두 필요하기 때문에 Amazon Aurora PostgreSQL을 다음과 함께 사용하기로 결정했습니다. pg벡터 두 기능을 모두 지원하는 확장입니다. 따라서 우리는 다음 아키텍처를 사용하여 의미 검색 RAG 구성 요소를 구현합니다.

이전 아키텍처를 사용하여 질문에 답하는 프로세스는 두 가지 주요 단계로 수행됩니다.

먼저, SageMaker 처리 작업으로 실행되는 오프라인 배치 프로세스는 다음과 같이 의미 체계 검색 인덱스를 생성합니다.

1. 주기적으로 또는 새 문서를 수신하면 SageMaker 작업이 실행됩니다.
2. Amazon S3에서 텍스트 문서를 로드하고 이를 겹치는 청크로 분할합니다.
3. 각 청크에 대해 Amazon Titan 임베딩 모델을 사용하여 임베딩 벡터를 생성합니다.
4. 그것은 PG벡터 LangChain의 클래스를 사용하여 문서 청크 및 메타데이터와 함께 임베딩을 Amazon Aurora PostgreSQL로 수집하고 모든 임베딩 벡터에 대한 의미 체계 검색 인덱스를 생성합니다.

둘째, 실시간으로 새로운 질문마다 다음과 같이 답변을 구성합니다.

1. 질문은 Lambda 함수에서 실행되는 오케스트레이터에 의해 수신됩니다.
2. 오케스트레이터는 동일한 임베딩 모델을 사용하여 질문을 임베드합니다.
3. PostgreSQL 의미 체계 검색 인덱스에서 가장 관련성이 높은 상위 K 문서 청크를 검색합니다. 선택적으로 메타데이터 필터링을 사용하여 정밀도를 향상시킵니다.
4. 이러한 청크는 입력 질문과 함께 LLM 프롬프트에 동적으로 삽입됩니다.
5. Amazon Bedrock의 Anthropic Claude에게 프롬프트가 표시되어 사용 가능한 컨텍스트를 기반으로 입력 질문에 답하도록 지시합니다.
6. 마지막으로 생성된 답변은 오케스트레이터로 다시 전송됩니다.

도구를 사용하여 추론하고 행동할 수 있는 에이전트

지금까지 이 게시물에서는 RAG 또는 분석적 추론이 필요한 질문을 별도로 처리하는 방법에 대해 논의했습니다. 그러나 많은 실제 질문에서는 최종 답변에 도달하기 위해 때로는 여러 단계의 추론을 통해 두 가지 기능을 모두 요구합니다. 이러한 보다 복잡한 질문을 뒷받침하려면 에이전트라는 개념을 도입해야 합니다.

다음과 같은 LLM 에이전트 Amazon Bedrock 에이전트는 LLM을 사용하여 현재 상황을 사용하여 추론하고 적응하며 일반적인 문제 해결 프레임워크를 제시하는 옵션 목록에서 적절한 조치를 선택할 수 있는 유망한 솔루션으로 최근 등장했습니다. 에서 논의한 바와 같이 LLM 기반 자율 에이전트, 복잡한 추론을 지원하는 LLM 에이전트에 대한 여러 프롬프트 전략과 디자인 패턴이 있습니다.

그러한 디자인 패턴 중 하나가 ReAct(React)입니다. ReAct: 언어 모델에서 추론과 행동의 시너지 효과. ReAct에서 에이전트는 질문이 될 수 있는 목표를 입력으로 받아들이고, 이에 답하기 위해 누락된 정보 조각을 식별하고, 사용 가능한 도구 설명을 기반으로 정보를 수집할 수 있는 올바른 도구를 반복적으로 제안합니다. LLM은 주어진 도구로부터 답변을 받은 후 질문에 완전히 답하는 데 필요한 모든 정보가 있는지 재평가합니다. 그렇지 않은 경우 최종 응답이 준비되거나 한계에 도달할 때까지 또 다른 추론 단계를 수행하고 동일하거나 다른 도구를 사용하여 더 많은 정보를 수집합니다.

다음 시퀀스 다이어그램은 ReAct 에이전트가 "지난 5년 동안 가장 높은 수익을 올린 상위 2개 회사를 제공하고 상위 회사와 관련된 위험을 식별합니다"라는 질문에 답하기 위해 어떻게 작동하는지 설명합니다.

Python에서 이 접근 방식을 구현하는 방법에 대한 자세한 내용은 다음 항목에 설명되어 있습니다. 맞춤형 LLM 에이전트. 우리 솔루션에서 에이전트와 도구는 다음과 같이 강조된 부분 아키텍처로 구현됩니다.

입력 질문에 답하기 위해 다음과 같이 AWS 서비스를 사용합니다.

1. 사용자는 API를 호출하는 UI를 통해 질문을 입력합니다. 아마존 API 게이트웨이.
2. API Gateway는 에이전트 실행기를 구현하는 Lambda 함수에 질문을 보냅니다.
3. 에이전트는 사용 가능한 도구에 대한 설명, ReAct 지침 형식 및 입력 질문이 포함된 프롬프트로 LLM을 호출한 후 다음 작업을 구문 분석하여 완료합니다.
4. 작업에는 호출할 도구와 작업 입력이 무엇인지 포함됩니다.
5. 사용할 도구가 SQL인 경우 에이전트 실행자는 SQLQA를 호출하여 질문을 SQL로 변환하고 실행합니다. 그런 다음 결과를 프롬프트에 추가하고 LLM을 다시 호출하여 원래 질문에 답할 수 있는지 또는 추가 조치가 필요한지 확인합니다.
6. 마찬가지로, 사용할 도구가 의미 체계 검색인 경우 작업 입력이 구문 분석되어 PostgreSQL 의미 체계 검색 인덱스에서 검색하는 데 사용됩니다. 프롬프트에 결과를 추가하고 LLM이 응답할 수 있는지 또는 다른 조치가 필요한지 확인합니다.
7. 질문에 답변하기 위한 모든 정보를 사용할 수 있게 되면 LLM 에이전트는 최종 답변을 작성하여 사용자에게 다시 보냅니다.

추가 도구를 사용하여 에이전트를 확장할 수 있습니다. 구현에서 사용 가능 GitHub의에서는 앞서 언급한 SQL 엔진 및 의미 체계 검색 도구에 추가 도구로 검색 엔진과 계산기를 추가하는 방법을 보여줍니다. 진행 중인 대화 기록을 저장하기 위해 우리는 아마존 DynamoDB 테이블.

지금까지의 경험을 통해 우리는 다음 사항이 성공적인 에이전트의 핵심임을 확인했습니다.

• ReAct 형식으로 추론할 수 있는 기본 LLM
• 사용 가능한 도구, 사용 시기, 입력 인수에 대한 설명(잠재적으로 입력 및 예상 출력의 예 포함)에 대한 명확한 설명
• LLM이 따라야 하는 ReAct 형식에 대한 명확한 개요
• LLM 에이전트가 사용할 수 있는 비즈니스 문제 해결을 위한 올바른 도구
• LLM 에이전트 응답의 출력을 이유에 맞게 올바르게 구문 분석합니다.

비용을 최적화하려면 가장 일반적인 질문과 답변을 캐싱하고 이 캐시를 주기적으로 업데이트하여 기본 LLM에 대한 호출을 줄이는 것이 좋습니다. 예를 들어, 앞서 설명한 대로 가장 일반적인 질문으로 의미 검색 색인을 생성하고 LLM을 호출하기 전에 먼저 새 사용자 질문을 색인과 일치시킬 수 있습니다. 다른 캐싱 옵션을 살펴보려면 다음을 참조하세요. LLM 캐싱 통합.

비디오, 이미지, 오디오, 3D 파일 등 다른 형식 지원

이미지, 동영상, 오디오 등 다양한 형태의 정보는 물론, CAD나 Mesh 파일과 같은 3D 디자인 파일에도 동일한 솔루션을 적용할 수 있습니다. 여기에는 확립된 ML 기술을 사용하여 파일 콘텐츠를 텍스트로 기술한 다음 이전에 살펴본 솔루션에 수집할 수 있는 작업이 포함됩니다. 이 접근 방식을 사용하면 다양한 데이터 유형에 대해 QA 대화를 수행할 수 있습니다. 예를 들어 이미지, 비디오 또는 오디오 콘텐츠에 대한 텍스트 설명을 만들어 문서 데이터베이스를 확장할 수 있습니다. 또한 이러한 형식 내의 요소에 대한 분류 또는 객체 감지를 통해 속성을 식별하여 메타데이터 테이블을 향상시킬 수도 있습니다. 이렇게 추출된 데이터가 메타데이터 저장소 또는 문서의 의미 검색 색인에 색인화된 후 제안된 시스템의 전체 아키텍처는 대체로 일관되게 유지됩니다.

결론

이 게시물에서는 RAG 디자인 패턴과 함께 LLM을 사용하는 것이 도메인별 AI 도우미를 구축하는 데 필요하지만 비즈니스 가치를 창출하는 데 필요한 안정성 수준에 도달하기에는 부족한 방법을 보여주었습니다. 이 때문에 우리는 에이전트와 도구의 개념으로 인기 있는 RAG 디자인 패턴을 확장할 것을 제안했습니다. 여기서 도구의 유연성을 통해 전통적인 NLP 기술과 최신 LLM 기능을 모두 사용하여 AI 보조자가 정보를 찾고 지원하는 더 많은 옵션을 사용할 수 있게 되었습니다. 사용자는 비즈니스 문제를 효율적으로 해결합니다.

이 솔루션은 모든 지식 기반에 걸쳐 다양한 유형의 검색, 분석 추론 및 다단계 추론 질문에 답할 수 있는 LLM 보조자를 향한 설계 프로세스를 보여줍니다. 또한 LLM 보조자가 사용자에게 도움을 줄 것으로 예상되는 질문 및 작업 유형을 거꾸로 생각하는 것이 중요하다는 점을 강조했습니다. 이 경우 설계 여정을 통해 의미 체계 검색, 메타데이터 추출 및 SQL 쿼리, LLM 에이전트 및 도구라는 세 가지 구성 요소가 포함된 아키텍처가 탄생했습니다. 이는 여러 사용 사례에 충분히 일반적이고 유연하다고 생각됩니다. 또한 우리는 이 솔루션에서 영감을 얻고 사용자의 요구 사항을 깊이 조사함으로써 귀하에게 가장 적합한 솔루션을 향해 이 솔루션을 더욱 확장할 수 있다고 믿습니다.

---

저자 소개

모하메드 알리 자마우이 프로덕션 기계 학습 분야에서 10년의 경험을 보유한 수석 ML 프로토타이핑 설계자입니다. 그는 기계 학습 및 소프트웨어 엔지니어링을 통해 비즈니스 문제를 해결하고 고객이 ML을 통해 비즈니스 가치를 추출하도록 돕는 것을 좋아합니다. AWS EMEA 프로토타이핑 및 클라우드 엔지니어링의 일환으로 그는 고객이 MLOP, NLP, CV 및 LLM의 혁신을 활용하는 비즈니스 솔루션을 구축하도록 돕습니다.

주세페 한넨 ProServe 준 컨설턴트입니다. Giuseppe는 AI&ML과 함께 자신의 분석 기술을 적용하여 고객을 위한 명확하고 효과적인 솔루션을 개발합니다. 그는 복잡한 문제, 특히 최신 기술 개발 및 연구와 관련된 문제에 대한 간단한 해결책을 찾는 것을 좋아합니다.

로렌스 텐 케이트 수석 데이터 과학자입니다. Laurens는 EMEA의 기업 고객과 협력하여 AWS AI/ML 기술을 사용하여 비즈니스 성과를 가속화하도록 돕습니다. 그는 NLP 솔루션을 전문으로 하며 공급망 및 물류 산업에 중점을 두고 있습니다. 여가 시간에는 독서와 미술을 즐깁니다.

이리나 라두 AWS EMEA 프로토타이핑 및 클라우드 엔지니어링의 일부인 프로토타이핑 참여 관리자입니다. 그녀는 고객이 최신 기술을 최대한 활용하고 더 빠르게 혁신하며 더 크게 생각할 수 있도록 돕고 있습니다.

• SEO 기반 콘텐츠 및 PR 배포. 오늘 증폭하십시오.
• PlatoData.Network 수직 생성 Ai. 자신에게 권한을 부여하십시오. 여기에서 액세스하십시오.
• PlatoAiStream. 웹3 인텔리전스. 지식 증폭. 여기에서 액세스하십시오.
• 플라톤ESG. 탄소, 클린테크, 에너지, 환경, 태양광, 폐기물 관리. 여기에서 액세스하십시오.
• PlatoHealth. 생명 공학 및 임상 시험 인텔리전스. 여기에서 액세스하십시오.
• 출처: https://aws.amazon.com/blogs/machine-learning/boosting-rag-based-intelligent-document-assistants-using-entity-extraction-sql-querying-and-agents-with-amazon-bedrock/