필수 구성 요소: 요구 사항 수집
명확하고 포괄적인 사용 사례 요구 사항을 정의하는 것은 성공적인 RAG 애플리케이션을 개발하는 데 중요한 첫 번째 단계입니다. 이러한 요구 사항은 두 가지 주요 목적으로 사용됩니다. 첫째, RAG이 지정된 사용 사례에 가장 적합한 방법인지 여부를 결정하는 데 도움을 줍니다. RAG이 실제로 적합한 경우 이러한 요구 사항은 솔루션 설계, 구현 및 평가 결정을 안내합니다. 프로젝트의 시작 부분에 시간을 투자하여 자세한 요구 사항을 수집하면, 추후 개발 프로세스에서 발생할 수 있는 중대한 문제 및 차질을 방지하고, 최종 사용자 및 이해 관계자의 요구를 충족하는 결과 솔루션을 제공할 수 있습니다. 잘 정의된 요구 사항은 단계별 개발 수명 주기의 기초를 제공합니다.
이 섹션의 샘플 코드는 GitHub 리포지토리에서 확인하세요. 리포지토리 코드를 사용자 고유의 AI 애플리케이션을 만드는 템플릿으로 사용할 수도 있습니다.
사용 사례가 RAG에 적합한가요?
가장 먼저 해야 할 일은 RAG가 사용 사례에 적합한 접근 방식인지 여부를 판단하는 것입니다. RAG에 대한 과대 광고로 인해 RAG를 모든 문제에 대한 만능 해답으로 여기기 쉽습니다. 그러나 RAG가 적합한 경우와 그렇지 않은 경우의 미묘한 차이가 있습니다.
RAG는 다음과 같은 경우에 적합합니다.
- LLM의 컨텍스트 window 완전히 맞지 않는 검색된 정보(구조화되지 않은 정보 및 구조화됨)에 대한 추론
- 여러 소스의 정보 합성(예: 하나의 주제에 대한 여러 문서의 요점을 요약하여 생성)
- 사용자 쿼리를 기반으로 하는 동적 검색이 필요한 경우(예: 사용자 쿼리가 지정된 경우 검색할 데이터 원본 결정)
- 사용 사례에서 검색된 정보를 기반으로 새로운 콘텐츠를 생성해야 할 경우(예: 질문에 답변하기, 설명 제공, 권장 사항 제공)
RAG는 다음과 같은 경우에 적합하지 않을 수 있습니다.
- 쿼리별 검색이 필요하지 않은 작업의 경우. 예를 들어 통화 기록 요약을 생성하는 경우: 개별 대본이 LLM 프롬프트에서 컨텍스트로 제공되더라도 검색된 정보는 각 요약에 대해 동일하게 유지됩니다.
- 검색할 정보의 전체 set가 LLM의 컨텍스트 window 내에 맞을 수 있습니다.
- 대기 시간이 매우 짧은 응답이 필요한 경우(예: 응답이 밀리초 단위로 필요한 경우)
- 간단한 규칙 기반 또는 템플릿 응답으로 충분한 경우(예: 키워드를 기반으로 미리 정의된 답변을 제공하는 고객 지원 챗봇).
검색 요구 사항
RAG가 사용 사례에 적합하다는 것을 확인한 후, 구체적인 요구 사항을 파악하기 위해 다음 질문을 고려하세요. 요구 사항은 다음과 같이 우선 순위가 지정됩니다.
🟢 P0: POC를 시작하기 전에 반드시 정의해야 하는 요구 사항입니다.
🟡 P1: 프로덕션으로 전환하기 전에 정의해야 하지만 POC 중에 반복적으로 구체화할 수 있는 요구 사항입니다.
⚪ P2: 있으면 좋은 요구 사항.
이것은 질문의 포괄적인 list 아닙니다. 그러나 RAG 솔루션에 대한 주요 요구 사항을 캡처하기 위한 견고한 기반을 제공합니다.
사용자 환경
사용자가 RAG 시스템과 상호 작용하는 방법 및 예상되는 응답 종류를 정의하세요
🟢 [P0] RAG 체인에 대한 일반적인 요청은 어떤 모습일까요? 이해 관계자에게 잠재적인 사용자 쿼리의 예를 요청하세요.
🟢 [P0] 사용자는 어떤 종류의 응답을 기대할까요? (짧은 답변, 긴 형식 설명, 조합형 또는 다른 응답 등)
🟡 [P1] 사용자는 시스템과 어떻게 상호 작용할까요? 채팅 인터페이스, 검색 창 또는 다른 형식의 상호 작용인가요?
🟡 [P1] 생성된 응답은 어떤 어조나 스타일을 가져야 할까요? (격식 있는, 일상적인, 기술적인 어조 등)
🟡 [P1] 응용 프로그램은 모호하거나 불완전하거나 관련이 없는 쿼리를 어떻게 처리해야 할까요? 이러한 경우 특정 형식의 피드백이나 지침을 제공해야 할까요?
⚪ [P2] 생성된 출력에 대해 특정 서식 또는 프레젠테이션 요구 사항이 있나요? 출력에 체인의 응답 외에 메타데이터가 포함되어야 하나요?
데이터
RAG 솔루션에서 사용할 데이터의 특성, 원본 및 품질을 결정하세요.
🟢 [P0] 사용할 수 있는 원본은 무엇인가요?
각 데이터 소스에 대해:
- 🟢 [P0] 데이터는 구조화 되어있나요, 비구조화되어 있나요?
- 🟢 [P0] 검색 데이터의 원본 형식(예: PDF, 이미지/tables설명서, 구조적 API 응답)은 무엇인가요?
- 🟢 [P0] Where 해당 데이터가 상주하나요?
- 🟢 [P0] 얼마나 많은 데이터가 사용 가능한가요?
- 🟡 [P1] 데이터는 얼마나 자주 업데이트되나요? 이러한 업데이트는 어떻게 처리해야 하나요?
- 🟡 [P1] 각 데이터 원본에 대해 알려진 데이터 품질 문제 또는 불일치가 있나요?
인벤토리 table 만들어 이 정보를 통합하는 것이 좋습니다. 예를 들면 다음과 같습니다.
| 데이터 원본 | Source | 파일 형식 | 크기 | Update 빈도 |
|---|---|---|---|---|
| 데이터 원본 1 | Unity Catalog 볼륨 | JSON | 10GB | 일간 |
| 데이터 원본 2 | 퍼블릭 API | XML | NA (API) | 실시간 |
| 데이터 원본 3 | SharePoint | PDF, .docx | 500MB | 매월 |
성능 제약 조건
RAG 애플리케이션에 대한 성능 및 리소스 요구 사항을 정의하세요.
🟡 [P1] 응답을 생성하기 위해 허용되는 최대 대기 시간은 무엇인가요?
🟡 [P1] 첫 번째 토큰에 허용되는 최대 시간은 얼마인가요?
🟡 [P1] 출력이 스트리밍되는 경우, 더 높은 총 대기 시간이 허용될 수 있나요?
🟡 [P1] 추론에 사용할 수 있는 컴퓨팅 리소스에 대한 비용 제한이 있나요?
🟡 [P1] 예상되는 사용 패턴과 최대 부하는 어떻게 되나요?
🟡 [P1] 시스템이 처리해야 할 동시 사용자 또는 요청 수는 얼마나 되나요? Databricks는 모델 서비스를 사용하여 자동으로 크기를 조정하는 기능을 통해 기본적으로 이러한 확장성 요구 사항을 처리합니다.
평가
RAG 솔루션을 평가하고 시간이 지나면서 개선할 방법을 설정하세요.
🟢 [P0] 달성하고자 하는 비즈니스 목표 또는 KPI는 무엇인가요? 현재 기준 값과 대상은 무엇인가요?
🟢 [P0] 초기 및 지속적인 피드백을 제공할 사용자나 이해 관계자는 누구인가요?
🟢 [P0] 생성된 응답의 품질을 평가하기 위해 어떤 메트릭을 사용해야 하나요? Mosaic AI 에이전트 평가 사용하기 위한 권장 메트릭 set 제공합니다.
🟡 [P1] RAG 앱이 프로덕션에 가기 위해 잘해야 하는 질문의 set 무엇인가요?
[P1] 🟡 [평가 set]가 있나요? 사용자 쿼리의 평가 set 기본 진실 답변 및 검색해야 하는 올바른 지원 문서(선택 사항)와 함께 get 수 있나요?
🟡 [P1] 사용자 피드백은 어떻게 수집되고 시스템에 반영되나요?
보안
보안 및 개인 정보 보호 고려 사항을 식별하세요.
🟢 [P0] 주의하여 처리해야 하는 중요한/기밀 데이터가 있나요?
🟡 [P1] 솔루션에서 액세스 제어를 구현해야 합니까(예: 지정된 사용자가 제한된 문서 set 검색할 수만 있습니다)?
배포
RAG 솔루션을 통합, 배포 및 유지 관리하는 방법을 이해하세요.
🟡 RAG 솔루션은 기존 시스템 및 워크플로와 어떻게 통합되어야 하나요?
🟡 모델은 어떻게 배포, 크기 조정 및 버전 관리되어야 하나요? 이 자습서에서는 MLflow, Unity Catalog, 에이전트 SDK 및 모델 서비스를 사용하여 Databricks에서 엔드투엔드 수명 주기를 처리하는 방법을 설명합니다.
예시
예를 들어 Databricks 고객 지원 팀에서 사용하는 이 예제 RAG 애플리케이션에 이러한 질문이 어떻게 적용되는지 고려해 보세요.
| 영역 | 고려 사항 | 요구 사항 |
|---|---|---|
| 사용자 환경 | - 상호 작용 형식 - 일반적인 사용자 쿼리 예제 - 예상 응답 형식 및 스타일 - 모호하거나 관련이 없는 쿼리 처리 |
- Slack과 통합된 채팅 인터페이스 - 예제 쿼리: "클러스터 시작 시간을 어떻게 줄일 수 있나요?" "어떤 종류의 지원 계획이 있나요?" - 코드 조각과 관련 문서에 대한 링크가 포함된 명확한 기술 응답이 적절합니다. where - 상황에 맞는 제안을 제공하고 필요할 때 엔지니어를 지원하도록 에스컬레이션합니다 |
| 데이터 | - 데이터 원본의 수 및 유형 - 데이터 서식 및 위치 - 데이터 크기 및 update 빈도입니다. - 데이터 품질 및 일관성을 보장 |
- 세 개의 데이터 원본 - 회사 설명서(HTML, PDF) - 확인된 지원 티켓(JSON) - 커뮤니티 포럼 게시물(Delta table). - Unity Catalog에 저장되어 매주 업데이트되는 데이터입니다. - 총 데이터 크기: 5GB. - 전용 문서 및 지원 팀에서 유지 관리하는 일관된 데이터 구조 및 품질 |
| 성능 | - 최대 허용 대기 시간 - 비용 제약 조건 - 예상 사용량 및 동시 실행 |
- 최대 대기 시간 요구 사항 - 비용 제약 조건 - 예상 최대 부하 |
| 평가 | - 평가 데이터 세트 가용성 - 품질 메트릭 - 사용자 피드백 컬렉션 |
- 출력을 검토하고 잘못된 답변을 조정하여 평가 데이터 세트를 만드는 데 도움을 주는 각 제품 영역의 실무 전문가 - 비즈니스 KPI - 지원 티켓 해결률 증가 - 지원 티켓당 소요되는 사용자 시간 감소소 - 품질 메트릭 - LLM 판단 응답 정확성 및 관련성 - 검색 정밀도를 판단하는 LLM - 사용자 호출 또는 다운 호출 - 피드백 수집 - Slack에 좋아요/싫어요 기능이 추가될 예정입니다. |
| 보안 | - 중요한 데이터 처리 - Access Control 요구 사항 |
- 중요한 고객 데이터는 검색 원본에 없어야 합니다 - Databricks Community SSO를 통한 사용자 인증 |
| 배포 | - 기존 시스템과의 통합 - 배포 및 버전 관리 |
- 지원 티켓 시스템과의 통합 - Databricks 모델 서비스 엔드포인트로 배포된 체인 |
다음 단계
Get은/는 단계 1에서 시작했습니다. 코드 리포지토리를 복제하고 컴퓨트를 만듭니다.