고급 검색 증강 세대 시스템 빌드
이전 문서에서는 비즈니스에서 생성 AI에 대한 첫 번째 사용 사례 중 하나인 "데이터에 대한 채팅" 애플리케이션을 빌드하기 위한 두 가지 옵션에 대해 설명했습니다.
- 사용자의 쿼리와 유사성에 따라 검색하고 완료를 위해 LLM에 전달할 수 있는 검색 가능한 아티클 데이터베이스를 사용하여 LLM(대규모 언어 모델) 학습을 보완하는 RAG(검색 확대 생성)입니다.
- 미세 조정- 문제 도메인에 대한 자세한 내용을 이해하기 위해 LLM의 학습을 확장합니다.
이전 문서에서는 각 접근 방식, 각 접근 방식의 장점 및 단점을 사용하는 시기와 다른 몇 가지 고려 사항에 대해서도 설명했습니다.
이 문서에서는 RAG, 특히 프로덕션 준비 솔루션을 만드는 데 필요한 모든 작업을 자세히 살펴봅니다.
이전 문서에서는 다음 다이어그램을 사용하여 RAG의 단계 또는 단계를 설명했습니다.
이 묘사는 "순진한 RAG"라고 하며 RAG 기반 채팅 시스템을 구현하는 데 필요한 메커니즘, 역할 및 책임을 먼저 이해하는 유용한 방법입니다.
그러나 실제 구현에는 아티클, 쿼리 및 사용할 응답을 준비하기 위한 더 많은 사전 및 사후 처리 단계가 있습니다. 다음 다이어그램은 "고급 RAG"이라고도 하는 RAG의 보다 현실적인 묘사입니다.
이 문서에서는 다음과 같이 구성된 실제 RAG 기반 채팅 시스템에서 사전 및 사후 처리 문제의 유형을 이해하기 위한 개념 프레임워크를 제공합니다.
- 수집 단계
- 유추 파이프라인 단계
- 평가 단계
개념적 개요로서 키워드와 아이디어는 추가 탐색 및 연구를 위한 시작점이자 컨텍스트로 제공됩니다.
수집
수집은 주로 사용자의 질문에 대답하기 위해 쉽게 검색할 수 있는 방식으로 조직의 문서를 저장하는 것과 관련이 있습니다. 문제는 사용자의 쿼리와 가장 일치하는 문서 부분이 유추 중에 배치되고 활용되도록 하는 것입니다. 일치는 주로 벡터화된 포함 및 코사인 유사성 검색을 통해 수행됩니다. 그러나 콘텐츠의 특성(패턴, 양식 등)과 데이터 조직 전략(벡터 데이터베이스에 저장될 때의 데이터 구조)을 이해하여 촉진됩니다.
이를 위해 개발자는 다음을 고려해야 합니다.
- 콘텐츠 사전 처리 및 추출
- 청크 분할 전략
- 청크 분할 조직
- 업데이트 전략
콘텐츠 사전 처리 및 추출
깨끗하고 정확한 콘텐츠는 RAG 기반 채팅 시스템의 전반적인 품질을 개선하는 가장 좋은 방법 중 하나입니다. 이를 위해 개발자는 인덱싱할 문서의 모양과 형태를 분석하여 시작해야 합니다. 문서가 설명서와 같은 지정된 콘텐츠 패턴을 준수합니까? 그렇지 않은 경우 문서에서 대답할 수 있는 질문 유형은 무엇인가요?
최소한 개발자는 수집 파이프라인에서 다음을 수행하는 단계를 만들어야 합니다.
- 텍스트 형식 표준화
- 특수 문자 처리
- 관련이 없는 오래된 콘텐츠 제거
- 버전이 지정된 콘텐츠에 대한 계정
- 콘텐츠 환경 계정(탭, 이미지, 테이블)
- 메타데이터 추출
이 정보 중 일부(예: 메타데이터)는 유추 파이프라인의 검색 및 평가 프로세스 중에 사용하기 위해 벡터 데이터베이스의 문서와 함께 보관하거나 텍스트 청크와 결합하여 청크의 벡터 포함을 설득하는 데 유용할 수 있습니다.
청크 분할 전략
개발자는 더 긴 문서를 더 작은 청크로 분할하는 방법을 결정해야 합니다. 이렇게 하면 LLM으로 전송된 추가 콘텐츠의 관련성이 향상되어 사용자의 쿼리에 정확하게 응답할 수 있습니다. 또한 개발자는 검색 시 청크를 활용하는 방법을 고려해야 합니다. 이 영역은 시스템 디자이너가 업계에서 사용되는 기술에 대한 몇 가지 연구를 수행하고, 조직에서 제한된 용량으로 테스트하는 등 일부 실험을 수행해야 하는 영역입니다.
개발자는 다음을 고려해야 합니다.
- 청크 크기 최적화 - 청크의 이상적인 크기 및 청크를 지정하는 방법을 결정합니다. 섹션별로? 단락으로? 문장으로?
- 겹치는 창 청크 및 슬라이딩 윈도우 청크 - 콘텐츠를 불연속 청크로 나누는 방법을 결정합니다. 아니면 청크가 겹치나요? 또는 둘 다 (슬라이딩 윈도우)?
- Small2Big - 단일 문장처럼 세분화된 수준에서 청크할 때 콘텐츠가 인접한 문장을 쉽게 찾거나 단락을 포함하는 방식으로 구성되나요? ("청크 분할 조직"을 참조하세요.) 이 추가 정보를 검색하고 LLM에 제공하면 사용자의 쿼리에 응답할 때 더 많은 컨텍스트를 제공할 수 있습니다.
청크 분할 조직
RAG 시스템에서는 벡터 데이터베이스의 데이터 구성이 생성 프로세스를 보강하기 위해 관련 정보를 효율적으로 검색하는 데 매우 중요합니다. 개발자가 고려할 수 있는 인덱싱 및 검색 전략 유형은 다음과 같습니다.
- 계층적 인덱스 - 이 방법은 여러 인덱스 계층을 만드는 방법을 포함하며, 최상위 인덱스(요약 인덱스)는 검색 공간을 잠재적으로 관련된 청크의 하위 집합으로 빠르게 좁히고 두 번째 수준 인덱스(청크 인덱스)는 실제 데이터에 대한 보다 자세한 포인터를 제공합니다. 이 메서드는 먼저 요약 인덱스를 필터링하여 세부 인덱스에 검색할 항목 수를 줄여 검색 프로세스 속도를 크게 높일 수 있습니다.
- 특수 인덱스 - 데이터의 특성과 청크 간의 관계에 따라 그래프 기반 또는 관계형 데이터베이스와 같은 특수 인덱스를 사용할 수 있습니다. 예컨대:
- 그래프 기반 인덱스는 청크에 상호 연결된 정보 또는 인용 네트워크 또는 지식 그래프와 같은 검색을 향상시킬 수 있는 관계가 있는 경우에 유용합니다.
- 관계형 데이터베이스는 청크가 특정 특성 또는 관계에 따라 데이터를 필터링하고 검색하는 데 SQL 쿼리를 사용할 수 있는 테이블 형식으로 구성된 경우 효과적일 수 있습니다.
- 하이브리드 인덱스 - 하이브리드 접근 방식은 여러 인덱싱 전략을 결합하여 각 인덱스의 강점을 활용합니다. 예를 들어 개발자는 초기 필터링에 계층적 인덱스와 그래프 기반 인덱스를 사용하여 검색하는 동안 청크 간의 관계를 동적으로 탐색할 수 있습니다.
맞춤 최적화
검색된 청크의 관련성과 정확도를 높이기 위해 답변하려는 질문 또는 쿼리 유형에 더 가깝게 맞추는 것이 좋습니다. 이를 수행하기 위한 한 가지 전략은 청크가 답변에 가장 적합한 질문을 나타내는 각 청크에 대한 가상의 질문을 생성하고 삽입하는 것입니다. 이는 다음과 같은 여러 가지 방법으로 도움이 됩니다.
- 일치 개선: 검색하는 동안 시스템은 들어오는 쿼리를 이러한 가상 질문과 비교하여 가장 일치하는 항목을 찾아 가져온 청크의 관련성을 향상시킬 수 있습니다.
- Machine Learning 모델용 학습 데이터: 질문과 청크의 이러한 페어링은 RAG 시스템의 기반이 되는 기계 학습 모델을 개선하기 위한 학습 데이터 역할을 할 수 있으며, 어떤 유형의 질문이 어떤 청크로 가장 잘 답변되는지 알아볼 수 있도록 도와줍니다.
- 직접 쿼리 처리: 실제 사용자 쿼리가 가상의 질문과 밀접하게 일치하는 경우 시스템은 해당 청크를 신속하게 검색하고 사용하여 응답 시간을 단축할 수 있습니다.
각 청크의 가상 질문은 검색 알고리즘을 안내하는 일종의 "레이블"로 작동하여 보다 집중적이고 상황에 맞는 인식이 됩니다. 이는 청크가 광범위한 토픽 또는 정보 유형을 다루는 시나리오에서 유용합니다.
업데이트 전략
조직에서 자주 업데이트되는 문서를 인덱싱해야 하는 경우 리트리버 구성 요소(벡터 데이터베이스에 대해 쿼리를 수행하고 결과를 반환하는 시스템의 논리)가 최신 정보에 액세스할 수 있도록 업데이트된 모음을 유지해야 합니다. 이러한 시스템에서 벡터 데이터베이스를 업데이트하기 위한 몇 가지 전략은 다음과 같습니다.
- 증분 업데이트:
- 정규 간격: 문서 변경 빈도에 따라 정기적으로(예: 매일, 매주) 업데이트를 예약합니다. 이 메서드는 데이터베이스가 주기적으로 새로 고쳐지도록 합니다.
- 트리거 기반 업데이트: 업데이트가 다시 인덱싱을 트리거하는 시스템을 구현합니다. 예를 들어 문서를 수정하거나 추가하면 영향을 받는 섹션의 다시 인덱싱이 자동으로 시작될 수 있습니다.
- 부분 업데이트:
- 선택적 다시 인덱싱: 전체 데이터베이스를 다시 인덱싱하는 대신 변경된 모음의 부분만 선택적으로 업데이트합니다. 이는 특히 큰 데이터 세트의 경우 전체 다시 인덱싱보다 더 효율적일 수 있습니다.
- 델타 인코딩: 기존 문서와 업데이트된 버전 간의 차이점만 저장합니다. 이 방법은 변경되지 않은 데이터를 처리할 필요가 없도록 하여 데이터 처리 부하를 줄입니다.
- 버전 관리:
- 스냅샷: 다른 시점에서 문서 모음의 버전을 유지 관리합니다. 이렇게 하면 필요한 경우 시스템에서 이전 버전을 되돌리거나 참조할 수 있으며 백업 메커니즘을 제공합니다.
- 문서 버전 제어: 버전 제어 시스템을 사용하여 문서의 변경 내용을 체계적으로 추적합니다. 이렇게 하면 변경 기록을 유지하는 데 도움이 되며 업데이트 프로세스를 간소화할 수 있습니다.
- 실시간 업데이트:
- 스트림 처리: 스트림 처리 기술을 활용하여 문서를 변경함에 따라 실시간으로 벡터 데이터베이스를 업데이트합니다. 이는 정보 타임라인이 가장 중요한 애플리케이션에 중요할 수 있습니다.
- 실시간 쿼리: 미리 인덱싱된 벡터에만 의존하는 대신, 라이브 데이터를 쿼리하여 최신 응답을 쿼리하는 메커니즘을 구현하여 효율성을 위해 캐시된 결과와 결합할 수 있습니다.
- 최적화 기술:
- 일괄 처리: 변경 내용을 누적하고 일괄 처리하여 리소스 사용을 최적화하고 빈번한 업데이트로 인한 오버헤드를 줄입니다.
- 하이브리드 접근 방식: 사소한 변경에 증분 업데이트 사용, 문서 모음의 주요 업데이트 또는 구조적 변경에 대한 전체 다시 인덱싱과 같은 다양한 전략을 결합합니다.
올바른 업데이트 전략 또는 전략 조합을 선택하는 것은 문서 모음의 크기, 업데이트 빈도, 실시간 데이터 요구 사항 및 리소스 가용성과 같은 특정 요구 사항에 따라 달라집니다. 각 접근 방식에는 복잡성, 비용 및 업데이트 대기 시간 측면에서 단점이 있으므로 애플리케이션의 특정 요구 사항에 따라 이러한 요소를 평가해야 합니다.
유추 파이프라인
아티클이 청크, 벡터화 및 벡터 데이터베이스에 저장되었으므로 이제 포커스가 완료 시 과제로 바뀝니다.
- 사용자의 쿼리가 사용자가 찾고 있는 시스템에서 결과를 가져오는 방식으로 작성되어 있나요?
- 사용자의 쿼리가 정책을 위반하나요?
- 벡터 데이터베이스에서 가장 가까운 일치 항목을 찾을 가능성을 높이기 위해 사용자의 쿼리를 다시 작성하려면 어떻게 해야 하나요?
- 쿼리 결과를 평가하여 아티클 청크가 쿼리에 맞춰지도록 하려면 어떻게 해야 할까요?
- LLM에 전달하기 전에 쿼리 결과를 평가하고 수정하여 가장 관련성이 큰 세부 정보가 LLM 완료에 포함되도록 하려면 어떻게 해야 할까요?
- LLM의 완료가 사용자의 원래 쿼리에 응답하는지 확인하기 위해 LLM의 응답을 평가하려면 어떻게 해야 할까요?
- LLM의 응답이 정책을 준수하도록 하려면 어떻게 해야 할까요?
여기에서 볼 수 있듯이 개발자가 고려해야 하는 작업은 대부분 다음과 같은 형태로 고려해야 합니다.
- 원하는 결과를 얻을 가능성을 최적화하기 위한 사전 처리 입력
- 원하는 결과를 보장하기 위한 후처리 출력
전체 유추 파이프라인이 실시간으로 실행되고 있음을 명심하세요. 사전 및 사후 처리 단계를 수행하는 논리를 디자인하는 올바른 방법은 없지만 프로그래밍 논리와 LLM에 대한 추가 호출의 조합일 수 있습니다. 가장 중요한 고려 사항 중 하나는 가능한 가장 정확하고 규정을 준수하는 파이프라인을 빌드하는 것과 이를 실현하는 데 필요한 비용과 대기 시간 간의 절상입니다.
각 단계를 살펴보고 특정 전략을 식별해 보겠습니다.
쿼리 사전 처리 단계
쿼리 사전 처리는 다음 다이어그램에 표시된 대로 사용자가 쿼리를 제출한 직후에 발생합니다.
이러한 단계의 목표는 사용자가 시스템 범위 내에서 질문을 하고(그리고 의도하지 않은 작업을 수행하도록 시스템을 "탈옥"하려고 하지 않음) 코사인 유사성/ "가장 가까운 이웃" 검색을 사용하여 최상의 아티클 청크를 찾을 가능성을 높이기 위해 사용자의 쿼리를 준비하는 것입니다.
정책 검사 - 이 단계에는 특정 콘텐츠를 식별, 제거, 플래그 지정 또는 거부하는 논리가 포함될 수 있습니다. 일부 예로는 개인 식별 정보를 제거하고, 폭발물을 제거하고, "탈옥" 시도를 식별하는 것이 포함될 수 있습니다. 탈옥 은 사용자가 모델의 기본 제공 안전, 윤리적 또는 운영 지침을 우회하거나 조작하기 위해 사용할 수 있는 방법을 나타냅니다.
쿼리 재작성 - 머리글자어를 확장하고 속어를 제거하는 것에서부터 질문을 다시 구문화하여 높은 수준의 개념과 원칙을 추출하도록 보다 추상적으로 요청할 수 있습니다("스텝백 프롬프트").
스텝백 프롬프트의 변형은 LLM을 사용하여 사용자의 질문에 대답하고 , 해당 응답에 대한 포함(가상 문서 포함)을 만들고, 해당 포함을 사용하여 벡터 데이터베이스에 대한 검색을 수행하는 가상의 HyDE(문서 포함)입니다.
하위 쿼리
이 처리 단계는 원래 쿼리와 관련이 있습니다. 원래 쿼리가 길고 복잡한 경우 프로그래밍 방식으로 여러 개의 작은 쿼리로 분할한 다음 모든 응답을 결합하는 것이 유용할 수 있습니다.
예를 들어, 특히 물리학 분야에서 과학적 발견과 관련된 질문을 고려해 보세요. 사용자의 쿼리는 다음과 같습니다: "누가 현대 물리학에 더 중요한 기여를 했습니까, 알버트 아인슈타인 또는 닐스 보어?"
"중요한 기여"는 주관적이고 다각적일 수 있으므로 이 쿼리는 직접 처리하기가 복잡할 수 있습니다. 하위 쿼리로 분해하면 관리가 더 용이할 수 있습니다.
- 하위 쿼리 1: "현대 물리학에 알버트 아인슈타인의 주요 기여는 무엇입니까?"
- 하위 쿼리 2: "현대 물리학에 닐스 보어의 주요 기여는 무엇입니까?"
이러한 하위 쿼리의 결과는 각 물리학자의 주요 이론과 발견을 자세히 설명합니다. 예시:
- 아인슈타인의 경우 기여에는 상대성 이론, 광전 효과 및 E=mc^2가 포함될 수 있습니다.
- Bohr에게 기여에는 수소 원자의 모델, 양자 역학에 대한 그의 작업 및 보수성의 원칙이 포함될 수 있습니다.
이러한 기여가 설명되면 평가하여 다음을 확인할 수 있습니다.
- 하위 쿼리 3: "아인슈타인의 이론은 현대 물리학의 개발에 어떻게 영향을 미쳤습니까?"
- 하위 쿼리 4: "보어의 이론이 현대 물리학의 발전에 어떻게 영향을 미쳤습니까?"
이러한 하위 쿼리는 아인슈타인의 이론이 우주론과 양자 이론의 발전으로 이어진 방법, 그리고 Bohr의 작품이 원자 구조와 양자 역학의 이해에 어떻게 기여했는지와 같은 분야에서 각 과학자의 작품의 영향을 탐구할 것입니다.
이러한 하위 쿼리의 결과를 결합하면 언어 모델이 이론적 발전의 범위와 영향에 따라 현대 물리학에 더 중요한 기여를 한 사람에 대해 보다 포괄적인 응답을 형성하는 데 도움이 될 수 있습니다. 이 메서드는 보다 구체적이고 응답 가능한 구성 요소를 처리한 다음, 이러한 결과를 일관된 답변으로 합성하여 원래의 복잡한 쿼리를 간소화합니다.
쿼리 라우터
조직에서 콘텐츠 모음을 여러 벡터 저장소 또는 전체 검색 시스템으로 나누기로 결정할 수 있습니다. 이 경우 개발자는 제공된 쿼리를 기반으로 사용할 인덱스 또는 검색 엔진을 지능적으로 결정하는 메커니즘인 쿼리 라우터를 사용할 수 있습니다. 쿼리 라우터의 기본 기능은 특정 쿼리에 가장 적합한 답변을 제공할 수 있는 가장 적절한 데이터베이스 또는 인덱스를 선택하여 정보 검색을 최적화하는 것입니다.
쿼리 라우터는 일반적으로 사용자가 쿼리를 공식화한 후 검색 시스템으로 전송되기 전의 지점에서 작동합니다. 간소화된 워크플로는 다음과 같습니다.
- 쿼리 분석: LLM 또는 다른 구성 요소는 들어오는 쿼리를 분석하여 해당 콘텐츠, 컨텍스트 및 필요한 정보 유형을 이해합니다.
- 인덱스 선택: 분석에 따라 쿼리 라우터는 사용 가능한 여러 인덱스에서 하나 이상을 선택합니다. 각 인덱스는 다양한 유형의 데이터 또는 쿼리에 최적화될 수 있습니다. 예를 들어 일부 인덱스는 사실 쿼리에 더 적합할 수 있지만 다른 인덱스는 의견이나 주관적인 콘텐츠를 제공하는 데 탁월할 수 있습니다.
- 쿼리 디스패치: 쿼리가 선택한 인덱스로 디스패치됩니다.
- 결과 집계: 선택한 인덱스의 응답이 검색되고 집계되거나 추가로 처리되어 포괄적인 답변을 형성할 수 있습니다.
- 답변 생성: 마지막 단계에서는 검색된 정보를 기반으로 일관된 응답을 생성하여 여러 원본의 콘텐츠를 통합하거나 합성할 수 있습니다.
조직에서는 다음과 같은 사용 사례에 대해 여러 검색 엔진 또는 인덱스를 사용할 수 있습니다.
- 데이터 형식 전문화: 일부 인덱스는 뉴스 기사, 학술 논문의 다른 인덱스 및 일반 웹 콘텐츠 또는 의료 또는 법률 정보 등의 특정 데이터베이스의 인덱스를 전문으로 할 수 있습니다.
- 쿼리 유형 최적화: 특정 인덱스는 빠른 사실 조회(예: 날짜, 이벤트)에 최적화될 수 있으며, 다른 인덱스는 복잡한 추론 작업 또는 심층 도메인 지식이 필요한 쿼리에 더 적합할 수 있습니다.
- 알고리즘 차이점: 벡터 기반 유사성 검색, 기존 키워드 기반 검색 또는 고급 의미 체계 이해 모델과 같은 다양한 검색 알고리즘을 다른 엔진에서 사용할 수 있습니다.
의료 자문 컨텍스트에서 사용되는 RAG 기반 시스템을 상상해 보십시오. 시스템에서 여러 인덱스에 액세스할 수 있습니다.
- 상세하고 기술적인 설명을 위해 최적화된 의학 연구 논문 인덱스입니다.
- 증상과 치료의 실제 예를 제공하는 임상 사례 연구 인덱스입니다.
- 기본 쿼리 및 공중 보건 정보에 대한 일반 상태 정보 인덱스입니다.
사용자가 신약의 생화학 효과에 대한 기술적 질문을 하는 경우 쿼리 라우터는 깊이와 기술적 초점으로 인해 의학 연구 논문 인덱스의 우선 순위를 지정할 수 있습니다. 일반적인 질병의 일반적인 현상에 관하여 질문, 그러나, 일반적인 건강 지수는 그것의 광범위하고 쉽게 이해할 수 있는 내용을 위해 선택될 수 있습니다.
검색 후 처리 단계
검색 후 처리는 검색기 구성 요소가 다이어그램에 표시된 대로 벡터 데이터베이스에서 관련 콘텐츠 청크를 검색한 후에 발생합니다.
후보 콘텐츠 청크를 검색하면 다음 단계는 LLM 프롬프트를 보강할 때 문서 청크가 유용한지 확인하고 LLM에 표시할 프롬프트를 준비하기 시작하는 것입니다.
개발자는 프롬프트의 여러 측면을 고려해야 합니다. 너무 많은 보충 정보와 일부 (아마도 가장 중요 한 정보)를 포함 하는 프롬프트 무시 될 수 있습니다. 마찬가지로 관련 없는 정보를 포함하는 프롬프트는 답변에 지나치게 영향을 미칠 수 있습니다.
또 다른 고려 사항은 건초 더미 문제의 바늘입니다, 프롬프트의 시작과 끝에있는 콘텐츠가 중간의 콘텐츠보다 LLM에 더 큰 무게를 가지고 일부 LLM의 알려진 단점을 참조하는 용어.
마지막으로 LLM의 최대 컨텍스트 창 길이와 매우 긴 프롬프트를 완료하는 데 필요한 토큰 수(특히 대규모 쿼리 처리 시)를 고려해야 합니다.
이러한 문제를 처리하기 위해 검색 후 처리 파이프라인에는 다음 단계가 포함될 수 있습니다.
- 결과 필터링 - 이 단계에서 개발자는 벡터 데이터베이스에서 반환된 아티클 청크가 쿼리와 관련이 있는지 확인합니다. 그렇지 않은 경우 LLM에 대한 프롬프트를 작성할 때 결과가 무시됩니다.
- 순위 다시 매기 기 - 벡터 저장소에서 검색된 아티클 청크의 순위를 지정하여 관련 세부 정보가 프롬프트의 가장자리(시작 및 끝) 근처에 있는지 확인합니다.
- 프롬프트 압축 - LLM으로 보내기 전에 여러 아티클 청크를 단일 압축 프롬프트로 결합하고 요약하도록 설계된 저렴한 작은 모델을 사용합니다.
완료 후 처리 단계
완료 후 처리는 다음 다이어그램에 표시된 대로 사용자의 쿼리와 모든 콘텐츠 청크가 LLM으로 전송된 후에 발생합니다.
LLM에서 프롬프트를 완료한 후에는 완료의 유효성을 검사하여 답변이 정확한지 확인해야 합니다. 완료 후 처리 파이프라인에는 다음 단계가 포함될 수 있습니다.
- 사실 확인 - 여러 가지 형태를 취할 수 있지만, 의도는 사실로 제시되는 문서에서 수행 된 특정 클레임을 식별한 다음 정확성에 대한 해당 사실을 확인하는 것입니다. 팩트 검사 단계가 실패하면 더 나은 답변을 위해 LLM을 다시 쿼리하거나 사용자에게 오류 메시지를 반환하는 것이 적절할 수 있습니다.
- 정책 검사 - 사용자 또는 조직에 관계없이 답변에 유해한 콘텐츠가 포함되지 않도록 하는 마지막 방어선입니다.
평가
비결정적 시스템의 결과를 평가하는 것은 대부분의 개발자가 잘 알고 있는 단위 또는 통합 테스트만큼 간단하지 않습니다. 고려해야 할 몇 가지 요소가 있습니다.
- 사용자가 얻은 결과에 만족하고 있나요?
- 사용자가 질문에 대한 정확한 응답을 받고 있나요?
- 사용자 피드백을 캡처하려면 어떻게 해야 할까요? 사용자 데이터에 대해 수집할 수 있는 데이터를 제한하는 정책이 있습니까?
- 불만족 스러운 응답에 대 한 진단에 대 한, 우리는 질문에 대답에 들어간 모든 작업에 대 한 가시성이 있습니까? 근본 원인 분석을 수행할 수 있도록 각 단계의 로그를 입력 및 출력의 유추 파이프라인에 보관하나요?
- 결과를 회귀하거나 저하하지 않고 시스템을 변경하려면 어떻게 해야 할까요?
사용자의 피드백 캡처 및 작업
앞에서 설명한 것처럼 개발자는 조직의 개인 정보 보호 팀과 협력하여 피드백 캡처 메커니즘 및 원격 분석, 로깅 등을 설계하여 지정된 쿼리 세션에서 포렌식 및 근본 원인 분석을 사용하도록 설정해야 할 수 있습니다.
다음 단계는 평가 파이프라인을 개발하는 것입니다. 평가 파이프라인의 필요성은 축자 피드백을 분석하는 복잡성과 시간이 많이 걸리는 특성과 AI 시스템에서 제공하는 응답의 근본 원인에서 발생합니다. 이 분석은 AI 쿼리가 결과를 생성하는 방법을 이해하기 위해 모든 응답을 조사하고, 설명서에서 사용되는 콘텐츠 청크의 적합성 및 이러한 문서를 분할하는 데 사용되는 전략을 확인하는 것과 관련이 있기 때문에 매우 중요합니다.
또한 결과를 향상시킬 수 있는 추가 사전 또는 사후 처리 단계를 고려하는 것이 포함됩니다. 이 상세 검사는 특히 사용자의 쿼리에 대한 응답으로 적절한 설명서가 없는 경우 콘텐츠 차이를 발견합니다.
따라서 평가 파이프라인을 빌드하는 것은 이러한 작업의 규모를 효과적으로 관리하는 데 필수적입니다. 효율적인 파이프라인은 사용자 지정 도구를 활용하여 AI에서 제공하는 답변의 품질을 근사하는 메트릭을 평가합니다. 이 시스템은 사용자의 질문에 특정 답변이 제공된 이유, 해당 답변을 생성하는 데 사용된 문서 및 쿼리를 처리하는 유추 파이프라인의 효율성을 결정하는 프로세스를 간소화합니다.
골든 데이터 세트
RAG 채팅 시스템과 같은 비결정적 시스템의 결과를 평가하는 한 가지 전략은 "골든 데이터 세트"를 구현하는 것입니다. 골든 데이터 세트는 승인된 답변, 메타데이터(예: 주제 및 질문 유형), 답변에 대한 근거로 사용할 수 있는 원본 문서에 대한 참조, 심지어 변형(사용자가 동일한 질문을 할 수 있는 방법의 다양성을 포착하기 위한 다양한 구문)이 포함된 큐레이팅된 질문 집합입니다.
"골든 데이터 세트"는 "최상의 시나리오"를 나타내며 개발자는 시스템을 평가하여 시스템이 얼마나 잘 작동하는지 확인하고 새 기능 또는 업데이트를 구현할 때 회귀 테스트를 수행할 수 있습니다.
피해 평가
피해 모델링은 잠재적인 피해를 예측하고, 개인에게 위험을 초래할 수 있는 제품의 결함을 발견하고, 이러한 위험을 완화하기 위한 사전 전략을 개발하기 위한 방법론입니다.
기술, 특히 AI 시스템의 영향을 평가하도록 설계된 도구는 제공된 리소스에 설명된 대로 피해 모델링 원칙에 따라 몇 가지 주요 구성 요소를 제공합니다.
피해 평가 도구의 주요 기능은 다음과 같습니다.
이해 관계자 식별: 이 도구는 사용자가 직접 사용자, 간접적으로 영향을 받는 당사자 및 미래 세대 또는 환경 문제와 같은 비인간적 요인과 같은 기타 엔터티를 포함하여 기술의 영향을 받는 다양한 이해 관계자를 식별하고 분류하는 데 도움이 됩니다.
피해 범주 및 설명: 개인 정보 보호 손실, 정서적 고통 또는 경제적 착취와 같은 잠재적 피해의 포괄적인 목록을 포함합니다. 이 도구는 기술이 이러한 피해를 유발하는 방법을 보여 주는 다양한 시나리오를 통해 사용자를 안내하여 의도된 결과와 의도하지 않은 결과를 모두 평가하는 데 도움이 될 수 있습니다.
심각도 및 확률 평가: 이 도구를 사용하면 사용자가 확인된 각 피해의 심각도 및 확률을 평가할 수 있으므로 먼저 해결해야 할 문제의 우선 순위를 지정할 수 있습니다. 여기에는 정성적 평가가 포함될 수 있으며 사용 가능한 경우 데이터에서 지원될 수 있습니다.
완화 전략: 피해를 식별하고 평가할 때 이 도구는 잠재적 완화 전략을 제안합니다. 여기에는 시스템 설계 변경, 더 많은 안전 장치 또는 식별된 위험을 최소화하는 대체 기술 솔루션이 포함될 수 있습니다.
피드백 메커니즘: 이 도구는 이해 관계자로부터 피드백을 수집하기 위한 메커니즘을 통합하여 피해 평가 프로세스가 새로운 정보와 관점에 동적으로 반응하도록 해야 합니다.
설명서 및 보고: 투명성과 책임을 지원하기 위해 이 도구는 잠재적 위험을 완화하기 위해 수행된 피해 평가 프로세스, 결과 및 조치를 문서화하는 자세한 보고서를 쉽게 만들 수 있습니다.
이러한 기능은 위험을 식별하고 완화하는 데 도움이 될 뿐만 아니라 처음부터 광범위한 영향을 고려하여 보다 윤리적이고 책임 있는 AI 시스템을 설계하는 데 도움이 됩니다.
자세한 내용은 다음을 참조하세요.
안전 장치 테스트 및 확인
이 문서에서는 RAG 기반 채팅 시스템이 악용되거나 손상될 가능성을 완화하기 위한 몇 가지 프로세스를 설명했습니다. 레드 팀은 완화가 효과적인지 확인하는 데 중요한 역할을 합니다. 레드 팀 구성에는 잠재적인 약점 또는 취약성을 파악하기 위해 애플리케이션을 대상으로 하는 악의적 사용자의 작업을 시뮬레이션하는 작업이 포함됩니다. 이 접근 방식은 탈옥의 중요한 위험을 해결하는 데 특히 중요합니다.
RAG 기반 채팅 시스템의 안전 장치를 효과적으로 테스트하고 확인하려면 개발자는 이러한 지침을 테스트할 수 있는 다양한 시나리오에서 이러한 시스템을 엄격하게 평가해야 합니다. 이는 견고성을 보장할 뿐만 아니라 정의된 윤리적 표준 및 운영 절차를 엄격하게 준수하도록 시스템의 응답을 미세 조정하는 데에도 도움이 됩니다.
애플리케이션 디자인 결정에 영향을 줄 수 있는 최종 고려 사항
다음은 애플리케이션 디자인 결정에 영향을 주는 이 문서에서 고려해야 할 사항 및 기타 내용의 짧은 목록입니다.
- 디자인에서 생성 AI의 비결정적 특성을 인정하고, 출력의 가변성을 계획하고, 응답에서 일관성과 관련성을 보장하기 위한 메커니즘을 설정합니다.
- 잠재적인 대기 시간 및 비용 증가에 대해 전처리 사용자 프롬프트의 이점을 평가합니다. 제출 전에 프롬프트를 단순화하거나 수정하면 응답 품질이 향상될 수 있지만 응답 주기에 복잡성과 시간이 더해질 수 있습니다.
- 성능을 향상시키기 위해 LLM 요청을 병렬화하는 전략을 조사합니다. 이 방법은 대기 시간을 줄일 수 있지만 복잡성 증가 및 잠재적 비용 영향을 방지하기 위해 신중한 관리가 필요합니다.
생성 AI 솔루션을 즉시 빌드하는 실험을 시작하려면 Python용 사용자 고유의 데이터 샘플을 사용하여 채팅을 시작하는 것이 좋습니다. .NET, Java 및 JavaScript에서도 사용할 수 있는 자습서 버전이 있습니다.