프로토타입에서 생산 가능한 시스템으로 전환하는 과정은 특히 복잡한 머신러닝 모델과 파이프라인이 포함되어 있을 때 상당한 도전과제를 수반할 수 있습니다. Haystack 및 RAG(Retrieval Augmented Generative) AI를 중점적으로 다루면서 이러한 전환을 어떻게 이룰 수 있는지 개요를 설명하겠습니다.
개발과 프로토타입
- 초기 프로토타입: Haystack 같은 프레임워크를 사용하여 시스템의 초기 버전을 만듭니다. 여기서는 대화형 AI, 의미론적 검색, 요약과 같은 기본 기능을 구현합니다.
- 테스팅: 프로토타입이 준비되면 병목 현상, 오류, 또는 개선이 필요한 부분을 파악하기 위해 철저히 테스트합니다.
- 이해당사자 피드백: 이해당사자로부터 피드백을 모아 필요한 조정을 합니다.
- 세부 조정과 지표: 성능 지표를 사용하여 시스템을 세부 조정하고 원하는 출력에 가깝게 만듭니다.
생산 환경(제품화)으로의 전환
- 코드 리팩토링: 프로토타입을 제품화 가능한 수준으로 만들기 위해 코드를 리팩토링합니다. 이는 코드의 성능, 확장성, 유지보수성을 최적화하는 것을 의미할 수 있습니다.
- 데이터 스케일링: 시스템이 제품화에서 필요한 데이터 규모를 처리할 수 있도록 합니다.
- 보안과 준수: 보안 문제를 해결하고 관련 규제에 준수하는지 확인합니다.
- 배포: 먼저 제어된 환경에서 시스템을 배포하고, 성능을 모니터링한 다음 일반 사용을 위해 출시합니다.
RAG 시스템을 위한 특별한 사항
- 데이터 인사이트: RAG 시스템은 데이터에서 인사이트를 추출하는 독특한 능력을 가지고 있으며, 이를 통해 생성 언어 모델(LLM)과 검색 시스템을 효과적으로 결합합니다. 데이터가 깨끗하고 잘 정리되어 있는지 확인하세요.
- 파이프라인 아키텍처: RAG는 생성 시스템과 검색 시스템을 결합하기 때문에 파이프라인 아키텍처가 복잡할 수 있습니다. 각 구성 요소를 철저히 테스트해야 합니다.
- 사용자 인터페이스: 진정으로 도움이 되는 사용자 인터페이스를 만드는 것이 목표 중 하나이므로, 최종 제품이 사용자 친화적이고 대상 사용자의 필요를 충족시키는지 확인합니다.
- 모니터링과 유지보수: 생산 환경에서는 시스템의 성능을 지속적으로 모니터링하고 필요에 따라 조정이 필요합니다.
이러한 측면에 중점을 두면 프로토타입에서 완전히 기능하는 RAG 시스템으로의 전환의 복잡성을 해결할 수 있습니다.
생산 환경으로의 배포는 복잡하고 위협적일 수 있습니다. 프로토타입 단계에서 생산 환경으로 원활하게 전환하기 위해 여러 요소가 정교하게 조정되어야 합니다.
인프라 계획
- 자원 할당: 배포하기 전에 시스템이 생산 환경에서 필요로 할 컴퓨팅 자원(CPU, GPU, 메모리, 스토리지 등)을 이해해야 합니다.
- 고가용성: 시스템의 일부가 실패하더라도 서비스가 계속 이용 가능하도록 예비 계획을 세웁니다.
- 로드 밸런싱: 들어오는 요청을 여러 서버에 분산시켜 리소스를 최적화하고 처리량을 극대화합니다.
버전 관리와 롤백
- 모델 버전 관리: 모델, 훈련 데이터, 코드베이스의 모든 변경 사항을 추적하여 필요한 경우 이전 버전으로 쉽게 되돌릴 수 있게 합니다.
- 롤백 전략: 배포 후 예상치 못한 오류나 문제가 발생한 경우 변경 사항을 되돌릴 수 있는 계획을 세워 둡니다.
지속적 통합과 지속적 배포 (CI/CD)
- 자동 테스트: 배포 파이프라인에 자동 테스트를 통합하여 생산 환경에 도달하기 전에 오류를 포착합니다.
- 자동 배포: 배포 과정을 최대한 자동화하여 인간의 오류를 줄입니다.
모니터링과 로깅
- 실시간 모니터링: 시스템의 성능 지표를 실시간으로 모니터링하여 문제를 빠르게 파악하고 해결합니다.
- 로그 기록: 시스템 성능, 사용자 상호작용, 오류 추적을 위해 상세한 로그를 유지합니다. 이는 디버깅과 미래의 개선을 위해 중요합니다.
모범 사례와 문서화
- 문서화: 전체 과정과 시스템 아키텍처를 문서화하여 팀의 누구나 배포된 시스템을 쉽게 이해할 수 있게 합니다.
- 모범 사례: 항상 최신의 모범 사례를 따르고 시스템을 업데이트합니다.
- 팀 협업: 문제 해결과 시스템 개선에 있어 팀이 가장 좋은 자산이 될 수 있으므로 지식과 모범 사례의 공유 문화를 육성합니다.
이러한 각 영역을 체계적으로 다루면 생산 환경으로의 전환과 관련된 위험을 최소화하고, RAG 시스템을 가능한 빠르게 생산 준비 상태로 만들 수 있습니다.
From Prototype to Production
프로토타입에서 생산 환경으로 전환하는 것은 그 자체로 복잡한 단계로, 고유한 일련의 도전과 고려사항을 불러일으킵니다. 여기 주요 포인트들을 나열해 보겠습니다.
확장성과 견고성
- 확장성: 생산 환경에서는 쿼리의 양이 예측할 수 없습니다. 따라서 시스템은 성능 저하 없이 쿼리 수가 증가해도 쉽게 처리할 수 있도록 확장 가능해야 합니다.
- 견고성: 시스템에 높은 부하가 발생해도 그것이 시스템을 다운시키면 안 됩니다. 여러 쿼리와 예기치 않은 상황을 효과적으로 처리할 수 있는 견고한 시스템을 구축해야 합니다.
예측 가능성과 비상 계획
- 예측 불가능한 사용: 얼마나 많은 사람들이 시스템을 사용할지 또는 언제 사용할지 예측할 수 없습니다. 예기치 않은 사용 상황을 수용하고 계획할 필요가 있습니다.
- 비상 계획: 모든 사용 패턴이나 들어오는 쿼리를 예상할 수 없기 때문에, 높은 부하 상황이나 예기치 않은 문제에 대비한 비상 계획을 세워둘 것이 중요합니다.
모니터링과 관측 가능성
- 성능 모니터링: 시스템이 실시간으로 작동할 때는 지속적으로 그 성능을 모니터링하여 사용자의 기대를 충족시키고 문제를 신속하게 해결하는 것이 필수적입니다.
- 관측 가능성: 시스템의 내부 상태를 외부 출력을 통해 이해하는 것, 종종 ‘관측 가능성’이라고 불리는 것은 문제를 진단하는 데 중요합니다. 이는 복잡한 주제이지만, 효과적인 모니터링과 성능 튜닝에는 필수적입니다.
시스템을 프로토타입에서 생산 환경으로 옮기는 것은, 제어 가능한 개발 환경에서 예측 불가능한 현실 세계의 시나리오로 바뀌는 것을 의미합니다. 이 때문에 철저한 준비, 모니터링, 그리고 적응 능력이 성공적인 배포를 위해 중요합니다.
The Use Case
특정 사용 사례를 고려하면 프로토타입에서 생산 환경으로의 전환을 맞춤화할 수 있습니다. 여기 RAG(검색 증강 생성 모델) 파이프라인 사용 사례에 특화된 고려사항과 도전 과제가 있습니다:
요구 사항
- 초기 데이터 적재: 시스템은 초기에 대량의 문서를 처리할 수 있어야 합니다. 이것은 기존의 온라인 뉴스 기사나 내부 회사 보고서일 수 있습니다.
- 점진적 업데이트: 초기 로드 이후에는 시스템이 새로운 문서의 더 작은 배치를 정기적으로 적재할 수 있어야 합니다. 이것은 일일 기준이거나 새 문서가 생성될 때마다 가능해야 합니다.
- 사용자 쿼리: 마지막으로, 시스템은 사용자 인터페이스(아마도 웹 브라우저)를 통해 언제든지 쿼리를 할 수 있어야 합니다.
Haystack에서의 처리 방법
Haystack에서는 이러한 요구 사항을 다음과 같이 관리할 수 있습니다:
- 인덱싱 파이프라인: 초기 배치 업로드와 정기적인 업데이트를 처리합니다. 이는 자동으로 데이터 저장소에서 새 문서를 가져와 기존 인덱스에 추가하는 방식으로 설계될 수 있습니다.
- 쿼리 파이프라인: 사용자로부터의 실시간 쿼리를 처리합니다. 이 파이프라인은 인덱싱된 데이터베이스에서 관련 문서를 가져와서 RAG 모델을 통해 응답이나 통찰력을 생성합니다.
Haystack에서는 이 두 파이프라인을 하나의 YAML 설정 파일에서 정의할 수 있어, 관리가 더 쉬워집니다.
생산 환경에서의 고려사항
- 확장성: 실시간 쿼리 요구와 데이터 저장소의 정기적인 업데이트를 고려할 때, 시스템은 확장 가능해야 합니다.
- 견고성: 다양하고 고량의 쿼리가 들어올 가능성을 고려하여 견고성이 중요합니다.
- 모니터링: 시스템이 24/7로 작동할 것이므로, 견고한 모니터링과 알림 기능이 중요합니다.
- 버전 관리: 데이터 저장소가 업데이트될 때마다, 변경 사항을 추적하고 필요한 경우 롤백할 수 있도록 버전 관리가 중요합니다.
이러한 시스템을 프로토타입에서 생산 환경으로 옮기려면, 데이터 흐름과 잠재적인 쿼리 부하를 종합적으로 이해할 필요가 있으며, 필요에 따라 확장하고 적응할 수 있는 견고한 시스템 설계가 필요합니다.
Moving to Production
생산 환경으로 이동하는 과정에서 사용할 수 있는 다양한 도구가 있습니다. 정확한 선택은 필요와 선호에 따라 다르며, 이전에 시스템을 배포한 경험이 있다면 이미 선호하는 설정이 있을 것입니다. 어쨌든, 성공적인 배포를 위해 필요한 것들을 살펴보겠습니다:
- 생산 준비가 완료된 관리형 데이터베이스: OpenSearch, Weaviate, Pinecone과 같은 데이터베이스를 사용하는 것이 좋습니다. 제3자가 관리하는 데이터베이스의 장점은 모든 복잡한 작업, 예를 들어 데이터베이스 유지 관리와 보안,이 제3자에 의해 처리된다는 것입니다.
- 데이터베이스와 컴퓨팅 인프라를 호스팅할 서버: CPU뿐만 아니라 GPU도 필요할 것입니다. 인덱싱을 위해 필요할 수도 있고, 추론(inference)을 위해서는 확실히 필요합니다. 클라우드 제공 업체에는 많은 옵션이 있으므로 가장 편안하게 느끼는 것을 선택하십시오.
- 오케스트레이션 도구: Kubernetes(일반적으로 K8s라고 표기)와 같은 도구가 필요합니다. 이 도구는 서버(데이터와 파이프라인이 실행되는 곳)와 클라이언트(REST API를 통해 요청을 보내는 사용자 인터페이스) 양쪽과 통신합니다.
- 대부분의 실제 프로젝트에서는 외부 서버에 배포하기 전에 로컬에서 애플리케이션을 테스트하고 싶을 것입니다. k3d를 사용하여 로컬에서 Kubernetes 환경을 설정할 수 있습니다. 이를 통해 자신의 기계에서 도커 위에 경량 Kubernetes 클러스터를 생성할 수 있습니다. 자세한 지침은 Kristof의 기사를 참고하십시오.
이러한 구성 요소들을 모두 고려하면, 복잡한 데이터 과학 프로젝트를 프로토타입에서 생산 환경으로 성공적으로 이동시킬 수 있는 좋은 기반을 마련할 수 있을 것입니다.
인덱싱 파이프라인을 생산 환경에 배포하기
인덱싱은 데이터베이스에 문서를 추가하는 과정입니다. 생산 환경에서 어떻게 인덱싱을 할지는 키워드 검색기(keyword retriever)와 임베딩 검색기(embedding retriever), 또는 이 둘을 혼합한 하이브리드 검색(hybrid retrieval ) 설정에 따라 다소 다릅니다.
키워드 검색기는 빠르고 특별한 하드웨어가 필요하지 않습니다. 그러나 임베딩 검색기는 다른 종류의 도구입니다.
임베딩 방법은 문서를 Transformer 기반의 언어 모델을 통해 실행해야 하므로 더 많은 시간이 걸립니다. 이 모델은 데이터베이스에 추가될, 의미론적으로 풍부한 밀집 벡터(dense vector)를 출력합니다. 이후의 검색 단계에서 이 벡터를 검색할 수 있게 됩니다. 이 단계는 계산적으로 비용이 많이 들기 때문에, GPU를 사용하여 이 과정을 가속화하려고 할 것입니다.
생산 환경에서의 주요 고려사항:
- 하드웨어 선택: 임베딩 방법을 사용한다면, GPU를 통한 가속이 필요합니다.
- 병렬 처리: 문서가 많다면, 병렬 처리를 통해 인덱싱 속도를 높일 수 있습니다.
- 스케쥴링: 문서가 지속적으로 업데이트 된다면, 자동 인덱싱을 위한 스케쥴링이 필요할 수 있습니다.
- 모니터링과 로깅: 인덱싱 과정에서의 성능과 문제점을 신속하게 파악하기 위한 모니터링과 로깅이 필요합니다.
이러한 고려사항들을 충족시키면, 인덱싱 파이프라인을 생산 환경에 효과적으로 배포할 수 있을 것입니다.
데이터베이스 준비하기
인덱싱 중에 문서와 해당 텍스트 임베딩은 데이터베이스의 메모리에 저장됩니다. 관리형 데이터베이스에 가입하기 전에, 문서와 벡터가 차지할 공간의 대략적인 개념을 갖는 것이 좋습니다. 그 이유는 나중에 공간을 추가하는 것이 번거롭기 때문이고, 너무 많은 공간을 구매한 뒤 사용하지 않으면 수천 달러나 유로, 엔 등이 들게 됩니다.
필요한 공간의 양은 대부분 벡터의 길이에 따라 다릅니다. 예를 들어, Cohere의 거대한 텍스트 임베딩은 생산 환경에서 자주 사용하는 것보다 5배 길어, 따라서 5배 더 많은 공간이 필요합니다. 따라서 벡터 길이를 최적화하면 매달 많은 돈을 절약할 수 있습니다.
관리형 데이터베이스를 설정할 때 마주치게 될 또 다른 개념은 “고가용성(high availability)”입니다. 이는 문서를 하나 이상의 서버와 물리적 위치에 저장하는 것을 의미합니다. 이러한 중복성의 실천은 서버가 일시적이거나 영구적으로 다운되더라도 문서가 계속 사용 가능하도록 보장합니다.
주요 고려사항:
- 공간 예측: 문서와 벡터가 차지할 공간을 미리 알아보는 것이 중요합니다.
- 벡터 최적화: 벡터의 길이를 최적화하여 저장 공간을 절약할 수 있습니다.
- 고가용성: 데이터의 안정성을 위해 다중 서버와 다중 위치에 데이터를 저장해야 합니다.
이러한 요소들을 고려하면 데이터베이스를 효과적으로 준비하고 관리할 수 있습니다.
문서 전처리 및 인덱싱
프로토타이핑 중에는 인덱싱 파이프라인을 정의해 문서를 전처리한 다음 데이터베이스에 추가하는 방식을 설정합니다. 프로덕션용으로는 이 인덱싱 파이프라인을 클라우드 공급자에 옮겨, Kubernetes가 가상 머신에서 배포하게 됩니다. 문서 저장소의 자격증명, 파이프라인의 yaml 설정 파일, 파이프라인 및 하드웨어의 스케일링 규칙 등의 모든 세부 설정을 Helm chart에 요약하는 것이 유용합니다. 그러면 Kubernetes는 차트에 지정된 설정에 따라 시스템을 배포합니다.
원본 파일을 외부 서비스로 어떻게 전송할 것인지는 주로 애플리케이션과 파일의 출처에 따라 다릅니다. 예를 들어, 매일 또는 매주 정해진 시간에 파일 배치를 인덱싱 엔드포인트로 전송하는 스크립트를 작성할 수 있습니다. 또는 들어오는 파일을 스트림으로 전송하도록 설정할 수 있습니다. 새로운 데이터를 인덱싱할 것으로 예상되면, Kubernetes에서 오토스케일링을 활성화하여 인덱싱 파이프라인의 복제본을 생성하고 병렬로 실행할 수 있습니다.
인덱싱 과정은 쿼리 과정만큼 시간에 민감하지 않으므로, 파일을 인덱싱 대기열에 넣을 수 있습니다. 대기열은 요청을 거의 즉시 받아들일 수 있지만, 미래의 어느 시점에 처리될 수 있도록 합니다. KEDA를 사용한 대기열에 대해 더 알고 싶다면, 인덱싱 파이프라인 스케일링에 관한 글 시리즈를 참조하세요. series of articles about scaling indexing pipelines
문서의 임베딩이 준비되면 서비스가 이를 데이터베이스에 추가하며, 이제 이 데이터를 쿼리할 수 있게 됩니다.
