개인 LLM 배포: 기업을 위한 실용적인 RAG

개인 LLM 배포는 검색 증강 생성(retrieval-augmented generation)을 통해 감사를 위한 데이터와 도메인에 정확한 답변을 제공하며, 데이터를 귀하의 경계 내에 유지합니다. 이 가이드는 엔지니어링 및 제품 팀이 모델 선택에서부터 안전한 RAG 파이프라인, 평가, 최소한의 프로덕션 청사진까지의 간결하고 실용적인 경로를 제공합니다.

제약 조건에 맞는 모델 및 임베딩 선택

지연 시간, 비용 및 라이선스 제약에 맞는 모델을 선택하십시오. Leafy.dev 및 PocketLLM과 같은 최근 오픈 가중치 목록은 작은 7B 모델에서 70B 패밀리에 이르기까지 다양한 선택지를 보여줍니다. 작은 모델은 호스팅 비용을 줄이고 온프레미스 추론을 실용적으로 만들며, 더 큰 모델은 즉시 사용 가능한 추론을 개선합니다. 인덱싱과 런타임 모두를 위해 동일한 공급자 또는 L2 호환 임베딩 모델을 사용하여 벡터 드리프트를 방지합니다. 우리는 정적 문서에 대한 임베딩을 사전 계산하면 쿼리 지연 시간을 단일 전방 패스의 대략적인 시간만큼 줄이고 롤백을 단순화한다는 것을 관찰했습니다.

안전한 벡터 저장소 및 프라이버시 기술

500만 개 미만의 벡터를 가진 많은 팀의 경우, pgvector를 사용하는 임베디드 Postgres는 운영 비용이 낮고 간단한 기본 옵션입니다. 그러나 Pinecone, Weaviate 및 Milvus와 같은 관리 서비스는 비용이 더 높지만 특별한 기능을 제공하여 운영 부담을 줄입니다. Inductivee 및 Tensoria 벤치마크는 100만 개에서 1억 개의 벡터 데이터셋에 대한 처리량 및 비용 차이를 논의하며 선택이 벡터 크기, QPS 및 다중 지역 복제가 필요한지에 따라 다르다는 것을 보여줍니다.

벡터를 저장소에서 암호화하고 키에 대해 봉투 암호화를 사용하십시오. 벡터 저장소에 대해 엄격한 IAM을 적용하고 모든 서비스 연결에 대해 mTLS를 요구하십시오. 위협 모델링 및 레드 팀 가이드를 위해 우리의 LLM 보안 플레이북 LLM security playbook를 참조하십시오. 형식적인 프라이버시 보장이 필요한 경우, 우리가 제공하는 튜토리얼 differential privacy techniques에서 차별적 프라이버시 옵션과 안전한 집계를 검토하십시오.

우리가 실제에서 겪었던 문제 중 하나는 벡터 메타데이터를 노출하는 잘못 구성된 서비스 계정입니다. 메타데이터는 높은 민감도로 처리하고 벡터와 동일한 제어 아래에 잠금 장치를 설정하십시오.

관련성, 환각, 지연 및 비용 측정

검색 지표인 Hit@k, MRR 및 NDCG를 사용하여 검색기를 평가하고 RAGEval 및 RAGAS와 같은 참조 및 비참조 평가 프레임워크를 사용하여 완전성, 환각 및 비관련성을 평가하십시오. RAGEval 및 RAGAS는 도메인 작업에 대한 시나리오별 테스트를 제공하며 평가 확장을 위한 자동화된 LLM-as-judge 검사를 제안합니다. 세 가지 프로덕션 신호를 모니터링합니다: 검색 정확성, 답변 진실성 및 꼬리 지연. 실제로, 검색기의 리콜을 높이면 모델 크기 증가보다 환각을 더 효과적으로 줄이는 경향이 있습니다.

개인 LLM 배포를 위한 배포 청사진

최소한의 청사진: VPC 뒤에서 컨테이너화된 모델 제공, 잠긴 네트워크 ACL을 가진 별도의 벡터 저장소 클러스터, 단기 토큰을 발급하는 인증 프록시, 감사용으로 검색 ID와 답변을 기록하는 가시성 스택. 지연 예측을 위해 단일 지역 VPC 호스팅 모델로 시작한 후, 필요할 경우에만 교차 지역 복제를 추가하십시오. 작은 배포의 경우 더 높은 고정 비용을 예상하지만 더 나은 제어 및 프라이버시가 제공됩니다.

명백한 반대는 공급업체 혁신입니다. 클라우드 호스팅 LLM 서비스는 빠르게 발전하고 있으며, 엔지니어링 비용을 고려할 때 더 저렴할 수 있습니다. 제 추정으로는, 지속적으로 수백만 건 이상의 월별 쿼리 볼륨을 처리하는 경우 관리된 추론이 총 소유 비용에서 자주 이깁니다. 그러나 규제가 있는 데이터나 엄격한 레지던스 규칙이 있는 경우 개인 배포가 유일한 실행 가능 옵션입니다.

스스로 시도해 보십시오: 아래 두 프롬프트는 기초를 노출하고 지원되지 않는 주장을 감지하는 방법을 보여줍니다.

이 프롬프트는 모델에게 제공된 컨텍스트를 사용하여 쿼리에 답하고 사용한 원본 ID 목록을 나열하도록 요청합니다. 간결한 답변과 원본 인용을 기대하세요.

다음의 컨텍스트 스니펫과 ID를 사용하여 사용자 질문에 답하고, 사용한 상위 3개의 컨텍스트 ID의 번호 매기기 목록과 각 ID에 대한 정확한 인용 증거를 포함하십시오.
컨텍스트 1 [id=C1]: "..."
컨텍스트 2 [id=C2]: "..."
사용자 질문: "X를 설명하고 상위 3개의 지원 스니펫을 인용하십시오."

이 프롬프트는 모델에게 자신의 답변에서 지원되지 않는 주장을 표시하도록 요청합니다. 지원 여부를 표시하고 가능할 경우 지원하는 스니펫 ID를 제공하는 짧은 목록을 기대하세요.

귀하는 이 답변을 생성했습니다. 각 문장에 대해 제공된 컨텍스트에 의해 완전히 지원되는지 마킹하고 지원하는 컨텍스트 ID를 제공하거나 지원되지 않음으로 마킹하십시오.
답변: "..."
컨텍스트: C1, C2, C3

우리는 검색 매개변수에 대한 작은 반복 실험이 진실성을 크게 향상시킨다는 것을 관찰했습니다. 평가를 반복 가능하게 유지하고 뿌리 원인 분석을 위해 답변과 함께 검색 ID를 기록하십시오.