AI 아키텍처

GitLab은 제품 그룹 및 그들의 AI 활용을 지원하기 위한 공통 도구 세트를 생성했습니다. 우리의 공통 아키텍처에 대한 목표는 다음과 같습니다:

높은 품질의 사용 준비 도구 세트를 제공함으로써 피처 팀의 속도를 높이기
기술 전환을 빠르고 쉽게 할 수 있는 능력

AI는 매우 빠르게 발전하고 있으며, 우리는 이 분야의 변화에 발 맞춰야 합니다. 이를 위해 추상화 계층을 구축하여 REST API 내에서 코드 중복을 방지하고, 기존 모델, 데이터 리포지터리 및 기타 기술에 대한 “플러그 가능”한 접근 방식을 취할 수 있도록 했습니다.

다음 아키텍처 블루프린트에서의 다이어그램은 GitLab의 다른 컴포넌트가 어떻게 상호 작용하는지를 단순화된 형태로 보여줍니다. 추상화 계층은 GitLab 내에서 코드 중복을 방지하는 데 도움이 됩니다.

SaaS 기반 AI 추상화 계층

GitLab은 현재 클라우드 기반의 AI 아키텍처를 운영하고 있습니다. 라이선스가 있는 Self-managed 인스턴스가 AI 게이트웨이를 사용하여 액세스할 수 있도록 허용할 것입니다. 자세한 내용은 블루프린트를 참조하세요.

이에는 두 가지 주요 이유가 있습니다: 최고의 AI 모델은 특수 하드웨어에 의존하는 경우가 많으며, 적절한 성능으로 대규모 AI를 수행하기 위한 Self-managed 인프라를 운영하는 것은 상당한 작업이기 때문입니다. 우리는 현재 AI에 관심이 있는 Self-managed 고객을 적극적으로 추적하고 있습니다.

AI 게이트웨이

AI 게이트웨이(이전의 모델 게이트웨이)는 모든 GitLab 사용자에게 AI 기능에 액세스할 수 있는 독립적인 서비스입니다. 이는 Self-managed, 전용 또는 GitLab.com을 사용하든지에 상관없이 SaaS 기반 AI 추상화 계층이 클라우드 기반 공급 업체에 직접 액세스하는 것이 아닌 이 게이트웨이에 연결되도록 전환될 것입니다.

GitLab-rails에서 AI-게이트웨이로의 호출은 추상화 계층을 사용하여 이루어집니다. 기본적으로 이러한 작업들은 Sidekiq 작업을 통해 비동기적으로 수행되어 Puma에서 장시간 실행되는 요청을 방지합니다. 추가된 Sidekiq의 지연 시간으로 인해 실시간 반응이 필요하지 않은 작업에 사용해야 합니다.

작성 시점에서 추상화 계층은 여전히 AI 공급 업체에 직접 호출을 하고 있습니다. Epic 11484는 이를 변환하기를 제안하고 있습니다.

특정 작업이 지연 시간이므로, AI-게이트웨이를 직접 호출하기로 결정할 수 있습니다. 이를 통해 Sidekiq에 의해 추가된 지연 시간을 피할 수 있습니다. code_suggestions를 이미 이렇게 처리하고 있으므로 새로운 엔드포인트를 추가할 경우 /api/v4/ai_assisted 네임스페이스 내에 포함시켜야 합니다. 이렇게 함으로써 GitLab.com의 요청을 ai-assisted 플릿으로 라우팅하고 규모 확장이 필요한 경우 이를 수월하게 만들 수 있습니다.

지원되는 기술

AI 워킹 그룹의 일환으로 다양한 기술을 조사하고 인증해 왔습니다. 이미 검토하고 GitLab 응용 프로그램 내에서 사용하기로 승인된 도구 디렉터리은 아래와 같습니다.

기타 모델이나 기술을 활용할 수는 있지만, 사용 전에 리뷰 과정을 거쳐야 합니다. 아이디어의 일환으로 새로운 도구들을 지원하기 위해 AI 프로젝트 제안 템플릿을 사용하세요.

모델

다음 모델들을 사용하기로 승인하였습니다:

벡터 리포지터리

다음 벡터 리포지터리들을 사용하기로 승인하였습니다:

pgvector는 벡터 임베딩을 저장하고 근사 인근 이웃을 계산하는 기능을 추가하는 포스트그레스 익스텐션입니다.

인덱싱 업데이트

우리는 현재 완벽한 검색을 제공하는 순차 검색을 사용하고 있습니다. pgvector 인덱싱 문서에 기록된대로 여전히 정확한 결과를 생성할 수 있다는 것을 보장할 수 있다면 인덱스를 추가하는 것을 고려하고 있습니다.

테이블이 수천 개의 항목을 포함하고 있기 때문에, 이러한 업데이트된 설정으로 인덱싱을 하는 것은 검색 속도를 향상시키고 높은 정확도를 유지하는데 도움이 될 것으로 예상됩니다. 그러나 프로덕션 배포 전에 이러한 데이터셋 크기에 대한 최적의 구성을 확인하기 위해 추가 테스트가 필요할 수 있습니다.

인덱스 기능은 검색 품질을 향상시키기 위해 업데이트되었습니다. 이는 다음 SQL 명령어를 사용하여 로컬에서 테스트되었습니다.

::Embedding::Vertex::GitlabDocumentation.connection.execute("SET ivfflat.probes = 10")

인덱싱을 위한 probes 값 설정은 이웃 문서에 따라 결과를 향상시킵니다.

최적의 probes 및 lists 값을 위해:

1백만 개의 행을 포함하는 테이블의 경우 lists를 rows / 1000으로, 크기가 큰 데이터셋의 경우 sqrt(rows)로 사용하세요.
1백만 개의 행을 포함하는 테이블의 경우 probes는 lists / 10으로 시작하고, 크기가 큰 데이터셋의 경우 sqrt(lists)으로 사용하세요.

코드 제안

코드 제안은 GitLab-Rails 리포지터리의 한 부분으로 통합되고, 이를 통해 추상화 계층을 사용하는 코드 제안 및 다른 AI 기능에 대한 Self-managed 지원이 통합될 것입니다.

다음 표는 코드 제안이 현재 제공하는 기능과 통합을 통해 어떻게 변할지를 문서화하고 있습니다:

주제	세부 정보	현재 발생 위치	향후 발생 위치
요청 처리
	IDE(Visual Studio Code, GitLab WebIDE, MS Visual Studio, IntelliJ, JetBrains, VIM, Emacs, Sublime)로부터 요청을 수신(커서 이전 및 이후 코드를 포함)	GitLab Rails	GitLab Rails
	현재 사용자의 인증, 해당 프로젝트에서 코드 제안을 사용할 권한이 있는지 확인	GitLab Rails + AI 게이트웨이	GitLab Rails + AI 게이트웨이
	TreeSitter를 통한 수입을 포함한 맥락을 추가하기 위한 요청 전처리	AI 게이트웨이	미결정
	AI 공급 업체로의 요청 라우팅	AI 게이트웨이	AI 게이트웨이
	IDE에 대한 응답 반환	GitLab Rails	GitLab Rails
	타임스탬프, 응답 시간, 모델 등을 포함한 요청 로깅	양쪽	양쪽
텔레메트리
	IDE에서 사용자의 수락 또는 거부	AI 게이트웨이	양쪽
	일일 고유 사용자 수	GitLab Rails, AI 게이트웨이	미결정
	오류율, 모델 사용, 응답 시간, IDE 사용	AI 게이트웨이	양쪽
	언어별 제안 수	AI 게이트웨이	양쪽
모니터링		양쪽	양쪽

모델 라우팅
	현재는 이 기능을 사용하지 않고 있지만, 코드 제안은 트래픽의 일부분에 따라 여러 모델로의 라우팅을 지원할 수 있습니다	AI 게이트웨이	양쪽
내부 모델
	현재 유지되지 않고 있으며, 자체 인스턴스에서 모델 실행, Triton 내에서 실행 및 자체 모델로의 요청 라우팅 지원	AI 게이트웨이	AI 게이트웨이

Self-managed 지원

Self-managed 사용자를 위한 코드 제안이 Cloud Connector MVC의 일부로 소개되었습니다.

이 프로젝트의 기술적 솔루션에 대한 자세한 내용은 Cloud Connector 아키텍처 문서를 참조하세요.

이 솔루션을 향후 Cloud Connector 제품군의 다른 AI 기능을 지원하도록 발전시키기 위한 의도가 있습니다.

코드 제안 대기 시간

코드 제안 수락률은 대기 시간에 매우 민감합니다. AI 어시스턴트를 사용하여 코드를 작성하는 동안 사용자는 코드 블록을 매뉴얼으로 입력하기 전에 짧은 시간 동안 만 일시적으로 일시 정지합니다. 사용자가 후속 키프레스를 누르면 기존 제안이 무효화되고 새로운 요청이 코드 제안 엔드포인트에 발행되어야 합니다. 결과적으로 이 요청도 대기 시간에 매우 민감할 것입니다.

최악의 경우에는 충분한 대기 시간으로 IDE가 요청 문자열을 발행하고, 사용자가 응답을 기다리지 않고 진행함에 따라 각각 무시되는 요청이 연속적으로 발생할 수 있습니다. 이로써 사용자에게는 가치가 없는 상황이 발생하면서도 여전히 서비스에 부하가 걸릴 것입니다.

이 기능의 대기 시간을 어떻게 반복 개선할 것인지에 대한 우리의 토론은 여기에서 확인하실 수 있습니다.