• 요약
• 언어: Python
• API
  • AI-gateway를 위한 기본 안정적인 API
    • 프로토콜
    • 단일 목적 엔드포인트
  • AI-게이트웨이 API 프로토콜
    • 교차 버전 호환성
    • 예시 기능: 코드 제안
    • AI 공급 업체 노출
  • GitLab 인스턴스의 API
• 인증 및 권한 부여
• 임베딩
• 배포
• 대체 솔루션

AI-gateway

요약

AI-gateway는 독립형 서비스로, GitLab의 모든 사용자에게 AI 기능에 액세스 권한을 부여할 것입니다. 어느 인스턴스를 사용하더라도(self-managed, 전용 또는 GitLab.com) 모두 해당됩니다.

최초에는 모든 AI-gateway 배포가 GitLab(조직)에 의해 관리되며, GitLab.com 및 모든 GitLab self-managed 인스턴스가 동일한 게이트웨이를 사용할 것입니다. 그러나 향후 필요에 따라 지역 게이트웨이나 심지어 고객별 게이트웨이를 배포할 수도 있습니다.

AI-Gateway는 클라이언트(이 경우 GitLab 설치)로부터 트래픽을 가져와 다른 서비스(이 경우 AI-공급자 및 모델)로 보내는 API Gateway입니다. 이러한 북/남 트래픽 패턴은 필요에 따라 요청을 어디로 보낼지 제어하고 리디렉트된 요청의 내용을 필요에 따라 변환하는 것을 가능하게 합니다.

현재, 다기능 지역 배포는 지원되지 않습니다. 고려 중인 기능입니다. 기존 다이어그램은 여러 지역에 걸쳐 배포하는 잠재적인 아키텍처를 보여줍니다.

다이어그램 출처

GitLab의 통제를 받는 호스팅된 서비스를 사용함으로써 우리는 모든 GitLab 인스턴스에 AI 기능을 확장 가능한 방식으로 제공할 수 있습니다. GitLab-rails 및 해당 종속 항목(데이터베이스, Redis)을 확장하는 것보다 이러한 작은 stateless 서비스를 확장하는 것이 더 쉽습니다.

자체 관리형 설치 사용자들이 자체 모델을 호스팅하거나 3rd party 제공업체에 연결할 필요없이 AI를 사용하여 기능에 액세스할 수 있도록 합니다.

언어: Python

AI-Gateway는 원래 IDE에서 Code Suggestions를 제공하기 위해 시작된 “model-gateway”로, Python으로 작성되었습니다.

Python은 객체 지향 언어로, Rubyists가 쉽게 습득할 수 있는 언어입니다. Python 경험이 있는 데이터 및 ML 엔지니어들이 기여할 수 있는 젊은 코드베이스를 통해 쉽게 배울 수도 있습니다.

API

AI-gateway를 위한 기본 안정적인 API

AI-gateway의 API는 다양한 GitLab 인스턴스에서 사용될 것이므로 안정적이면서 유연한 API를 설계하는 것이 중요합니다.

이를 위해 각 use-case 당 API-endpoint를 구현할 수 있습니다. 이는 GitLab과 AI-gateway 간의 인터페이스가 우리가 구축하고 소유한다는 것을 의미합니다. 이는 미래의 확장성, 조합성 및 보안을 보장합니다.

API는 버전이 지정되지 않지만 하위 호환성이 있습니다. 자세한 내용은 교차 버전 호환성을 참조하세요. AI-gateway는 최근 2개의 주요 버전을 지원할 것입니다. 예를 들어, GitLab 17.2에서 작업할 때 GitLab 17 및 GitLab 16을 모두 지원할 것입니다.

우리는 또한 이 스택의 이 수준에서 rate-limiting, circuit-breakers 및 secret redaction과 같은 공통 기능을 추가할 수 있습니다.

프로토콜

AI-Gateway 서비스와 클라이언트(포함하여 GitLab Rails 애플리케이션) 간의 통신은 JSON 기반 API를 사용해야 합니다.

AI-Gateway API는 서로 다른 AI 기능에 액세스할 수 있는 역할 담당 단일 목적의 엔드포인트를 노출해야 합니다. 나중에 다루게 될 섹션은 특정 엔드포인트를 구축하는 데 대한 자세한 지침을 제공합니다.

AI Gateway 통신 프로토콜은 feature-specific dynamic 정보를 래핑하는 기본적인 래퍼만을 기대해야 합니다. 이 프로토콜의 제안된 아키텍처는 API 엔드포인트가 버전에 무관하며, AI-Gateway API가 GitLab(또는 GitLab을 통해 게이트웨이를 사용하는 기타 클라이언트)의 여러 버전과 호환되도록 합니다.

즉, 버전과 관계없이 모든 클라이언트가 동일한 AI-Gateway API feature endpoints 집합을 사용합니다. AI-gateway feature endpoints는 지원되는 클라이언트 버전에 따라 달라져야 하며, 다른 지원 클라이언트 버전마다 여러 feature endpoints를 생성하는 대신에 지원되어야 합니다.

그러나 특정 엔드포인트를 진화시키기를 원할 경우 경로에 버전을 추가할 수 있습니다. 이는 자주 이를 해야할 것으로 기대하지는 않지만, 경로에 버전을 추가함으로써 옵션을 열어둘 수 있습니다. 이러한 이점은 개별 GitLab 마일스톤 릴리스가 릴리스 시점에서 테스트된 엔드포인트 버전을 계속 가리키는 반면, 새로운 엔드포인트 버전을 도입함으로써 빠르게 반복할 수 있게 합니다.

또한, VSCode 용 새로운 Ruby-gRPC 서버를 사용할 수 있다는 등 gRPC에 대해 고려해 보았습니다. gRPC 및 REST + JSON은 이러한 항목에서 차이가 있습니다.

논의: 우리가 이미 부분적으로 존재하는 기능을 전환하기 위해 현재 REST+JSON을 선택했다고 해서 gRPC나 웹소켓을 사용하는 새로운 기능을 배제해야 할 필요는 없습니다. 예를 들어, 채팅 기능은 요청 및 응답을 스트리밍할 수 있는 더 나은 기능일 수 있습니다. use-case 당 엔드포인트를 제안했기 때문에 서로 다른 프로토콜을 선택할 수도 있지만, 교차 버전 호환성을 염두에 두어야 합니다.

단일 목적 엔드포인트

AI를 사용하는 기능의 경우, 직접 프록시로 노출시키는 대신 안정적인 API를 사용하여 단일 목적 엔드포인트를 구축하는 것을 선호합니다. 노출된 AI 제공 엔드포인트를 거쳐 직접 프록시로 사용하는 방법보다 안정적인 API를 사용하여 단일 목적 엔드포인트를 구축하는 것을 선호합니다.

일부 기능은 특정 엔드포인트를 갖고 있을 수 있고, 다른 것은 엔드포인트를 공유할 수 있습니다. 예를 들어, 코드 제안이나 채팅은 각각의 엔드포인트를 갖을 수 있지만, 문제 또는 병합 요청을 요약하는 여러 기능은 동일한 엔드포인트를 사용하되 페이로드에서 제공되는 정보에 따라 구분할 수 있습니다.

우리의 목표는 고객을 대신하여 업데이트할 수 없는 코드를 최소화하는 것이며, 이는 GitLab의 단일 부호체계코드에 AI 관련 로직을 하드코딩하는 것을 피하는 것을 의미합니다.

• 우리는 고객이 최신 기능을 채택하는 데 필요한 시간을 최소화하고,
• 오래된 인스턴스의 지원을 유지하면서 제품 변경을 유연하게 할 수 있기를 원합니다.
• (무엇보다도) 최소한의 복잡성으로 모든 GitLab 배포(.com SaaS, Self-managed, 그리고 Dedicated)를 지원할 수 있기를 원합니다.
• 리스크를 줄이고 통합된 통제 플레인을 갖도록 AI 능력을 격리할 수 있기를 원합니다.
• 여러 AI 모델과 AI 공급 업체를 쉽게 지원할 수 있게 하는 차세대 멀티 모델 앙상블 접근을 지원할 수 있는 통합 구현을 제공하기를 원합니다.
• 비용을 제어하고 측정할 수 있는 단일 지점을 원합니다.
• 가능한 한 많은 메트릭(사용 통계, 응답 실패, 사용 패턴, 질문 범주 등)을 분산되지 않도록 게이트웨이에 기록하는 것을 원합니다. (물론 일부 메트릭은 클라이언트 측에서만 캡처할 수 있습니다.)

GitLab-Rails에 비즈니스 로직이 포함되어 있는 경우 고객이 GitLab 인스턴스를 업그레이드해야 하며, 이는 첫 번째 지점에 영향을 미칩니다. 온프레미스 사용자 중 일부는 회사 정책으로 인해 즉시 인스턴스를 업그레이드할 수 없을 수 있습니다. 예를 들어, GitLab-Rails의 프롬프트 템플릿에 버그가 있고 16.6에서 수정했을 경우, 고객이 16.5를 사용하고 다음 업그레이드가 3개월 후 예정되어 있다면, 3개월 동안 버그가있는 기능을 사용해야 합니다.

이는 프롬프트를 AI-게이트웨이 내에 구축해야 한다는 의미는 아닙니다. 그러나 프롬프트가 단일 목적 엔드포인트로의 페이로드의 일부인 경우, 페이로드에 어떤 모델을 위해 구축되었는지와 프롬프트에 대한 기타 메타데이터를 지정해야 합니다. 이렇게 함으로써 AI 게이트웨이에서 지원되지 않는 프롬프트 페이로드 중 하나가 발생해도 요청을 우아하게 강등하거나 지원할 수 있습니다. 또한 AI의 변화에 따른 오래된 GitLab 설치에서의 기능 파괴을 피할 수 있습니다.

AI-게이트웨이 API 프로토콜

각각의 단일 목적 엔드포인트를 버전에 구애받지 않는 방식으로 구축하는 것이 중요합니다. 이 목표를 달성하기 위해:

AI-게이트웨이 프로토콜은 모든 기능별 정보를 감싼 간단한 JSON 래퍼에 의존해야 합니다. AI-게이트웨이 프로토콜은 OSI 모델의 전송 계층 프로토콜(예: TCP, UDP)로 볼 수 있으며, 노드 간에 정보를 전송하는 방법을 정의하는 것입니다. 전송되는 정보가 무엇인지인지를 인식하지 않고, 감싸여진 방식을 정의합니다.

AI-게이트웨이 프로토콜은 받은 단일 목적 엔드포인트에서 어떤 정보가 처리되어야 하는지 또는 어떤 방식으로 처리되어야 하는지를 명시하지 않습니다. 엔드포인트에는 각 프로토콜 래퍼에서 나오는 데이터를 사용할지 무시할지를 결정할 수 있는 자유가 주어집니다.

AI-게이트웨이 프로토콜은 다음과 같이 각각의 요청을 정의합니다:

1. 각각의 단일 목적 엔드포인트는 단일 JSON 객체를 포함하는 요청을 허용합니다. 이 객체에는 prompt_components라는 단일 키가 포함되어 있어야 합니다.
2. prompt_components 키에는 다음 규칙에 따라 구성된 JSON 래퍼 배열이 포함되어 있어야 합니다:

각 JSON 래퍼에는 다음 3가지 요소가 포함되어 있습니다:

1. type: 래퍼 내에 제시되어 있는 정보의 유형을 지정하는 문자열 식별자입니다. AI-게이트웨이 단일 목적 엔드포인트는 모르는 유형은 무시할 수 있습니다.
2. payload: 제3자 AI 서비스 제공업체에 요청을 보내기 위해 사용할 수 있는 실제 정보입니다. payload 요소 내의 데이터는 type와 클라이언트 버전에 따라 다를 수 있습니다. 이는 AI-게이트웨이 단일 목적 엔드포인트가 payload 내부에 존재하는 데이터의 구조와 유형을 고려하여 부재 또는 잘못된 정보를 우아하게 처리해야 함을 의미합니다.
3. metadata: 이 필드에는 이 prompt_components 래퍼를 작성한 클라이언트에 대한 정보가 포함되어 있습니다. metadata 필드의 정보는 GitLab에서 통계 수집을 위해 사용될 수도, 사용되지 않을 수도 있습니다. payload와 마찬가지로 metadata 내의 모든 필드는 옵션이라고 간주되어야 합니다.

가장 자주 변경될 것으로 예상되는 래퍼 필드는 payload입니다. 여기에는 모든 필드가 옵셔널하고, 필드의 이름을 변경하거나 삭제하거나 다른 목적으로 사용하는 것을 피해야 합니다.

payload의 내용을 문서화하고 유효성을 검사하기 위해 JSON-schema를 사용하여 형식을 지정할 수 있습니다.

AI-게이트웨이 구성요소에 따른 예시 요청은 다음과 같습니다:

{
  "prompt_components": [
    {
      "type": "prompt",
      "metadata": {
        "source": "GitLab EE",
        "version": "16.7.0-pre",
      },
      "payload": {
        "content": "...",
        "params": {
          "temperature": 0.2,
          "maxOutputTokens": 1024
        },
        "model": "code-gecko",
        "provider": "vertex-ai"
      }
    },
    {
      "type": "editor_content",
      "metadata": {
        "source": "vscode",
        "version": "1.1.1"
      },
       "payload": {
        "filename": "application.rb",
        "before_cursor": "require 'active_record/railtie'",
        "after_cursor": "\nrequire 'action_controller/railtie'",
        "open_files": [
          {
            "filename": "app/controllers/application_controller.rb",
            "content": "class ApplicationController < ActionController::Base..."
          }
        ]
      }
    }
  ]
}

다른 예시용으로, 2개의 버전의 프롬프트가 prompt_components 페이로드로 전달되는 경우가 있습니다. 각 버전은 서로 다른 제3자 AI 모델 제공자를 위해 맞춤화되어 있습니다:

{
  prompt_components: [
    {
      "type": "prompt",
      "metadata": {
        "source": "GitLab EE",
        "version": "16.7.0-pre",
      },
      "payload": {
        "content": "You can fetch information about a resource called an issue...",
        "params": {
          "temperature": 0.2,
          "maxOutputTokens": 1024
        },
        "model": "text-bison",
        "provider": "vertex-ai"
      }
    },
    {
      "type": "prompt",
      "metadata": {
        "source": "GitLab EE",
        "version": "16.7.0-pre",
      },
      "payload": {
        "content": "System: You can fetch information about a resource called an issue...\n\nHuman:",
        "params": {
          "temperature": 0.2,
        },
        "model": "claude-2",
        "provider": "anthropic"
      }
    }

  ]
}

교차 버전 호환성

payload 내부의 필드 이름을 변경, 제거 또는 다른 목적으로 사용해야 하는 경우, 영향을 받는 봉투 타입을 사용하는 단일 목적 엔드포인트가 게이트웨이에 이전 버전을 위해 지원되어야 하며, 적어도 GitLab의 메이저 버전을 2개 버전 유지해야 합니다.

역 호환성을 지원하는 데 도움이 될 수 있는 좋은 방법: prompt_components 내부에서 완전한 프롬프트 대신 빌딩 블록을 제공합니다. 프롬프트를 빌딩 블록에서 AI-Gateway로의 컴파일 책임으로 옮김으로써 미래에 더 유연한 프롬프트 조정이 가능해집니다.

예시 기능: 코드 제안

예를 들어, 초기 코드 제안 서비스는 다음과 같이 보일 수 있습니다:

POST /v3/code/completions

{
  "prompt_components": [
    {
      "type": "prompt",
      "metadata": {
        "source": "GitLab EE",
        "version": "16.7.0-pre"
      },
      "payload": {
        "content": "...",
        "params": {
          "temperature": 0.2,
          "maxOutputTokens": 1024
        },
        "model": "code-gecko",
        "provider": "vertex-ai"
      }
    },
    {
      "type": "editor_content",
      "metadata": {
        "source": "vscode",
        "version": "1.1.1"
      },
      "payload": {
        "filename": "application.rb",
        "before_cursor": "require 'active_record/railtie'",
        "after_cursor": "\nrequire 'action_controller/railtie'",
        "open_files": [
          {
            "filename": "app/controllers/application_controller.rb",
            "content": "class ApplicationController < ActionController::Base..."
          }
        ]
      }
    }
  ]
}

응답은 다음과 같을 수 있습니다:

{
  "response": "require 'something/else'",
  "metadata": {
    "identifier": "deadbeef",
    "model": "code-gecko",
    "timestamp": 1688118443
  }
}

metadata 필드는 AI-gateway에서 텔레메트리 엔드포인트에서 사용할 수 있는 정보를 포함하고 있습니다. 여기서 우리는 제안 수락률을 계산할 수 있습니다.

코드 제안에 대한 텔레메트리를 받는 방식은 #415745에서 논의 중입니다. 모든 AI 관련 기능에 대한 아키텍처를 고안하려 합니다.

AI 공급 업체 노출

현재 GitLab-Rails에는 이미 다양한 AI 기능이 내장되어 있으며, 현재 이러한 기능은 프롬프트를 작성하고 이를 다양한 AI 제공 업체에 직접 제출합니다. 작성 시점에서 다음과 같은 공급 업체를 위한 GitLab의 API 클라이언트가 있습니다:

• Anthropic
• Vertex
• OpenAI

이러한 기능을 GitLab.com, Self-Managed 또는 전용 설치가 사용할 수 있도록 하기 위해 각각에 대한 엔드포인트를 제공해야 합니다.

우리는 먼저 클라이언트가 호출할 것을 명시하는 엔드포인트를 생성하는 식으로 프록시가 요청을 처리하는 엔드포인트를 작성할 수 있을 것입니다. 예를 들어, Anthropic에 대한 엔드포인트는 다음과 같이 보일 수 있습니다:

POST /internal/proxy/anthropic/(*endpoint)

*endpoint는 클라이언트가 호출할 내용을 지정하게 해주는 것으로, 예를 들어 /v1/complete와 같습니다. 요청 본문은 AI 공급 업체로 완전히 전달됩니다. AI-gateway는 요청이 올바르게 인증되었는지 확인합니다.

GitLab와 AI 공급 업체 사이에 프록시를 두는 것은 AI 공급 업체로 전달되는 내용을 여전히 제어할 수 있게 하며, 필요한 경우 API가 변경되거나 특정 공급 업체와의 협업을 중단하기로 결정하더라도 요청을 조작하거나 다른 공급 업체로 라우팅할 수 있습니다. 이렇게 함으로써, 과거 GitLab 설치의 기능을 계속 지원할 수 있게 되며 공급 업체의 API가 변경되거나 특정 공급 업체와의 협업을 중단하기로 결정하더라도 이전의 GitLab 설치의 기능을 지원할 수 있게 됩니다.

API 공급 업체를 직접 사용하는 기능들을 기능별로 목적을 갖는 API로 이동하는 것에 가치가 있다고 생각합니다. 이렇게 함으로써, 우리는 AI 공급 업체가 진화함에 따라 이러한 기능을 개선할 수 있게 되며 우리가 관리하는 AI-gateway를 변경하면서 개선할 수 있게 됩니다. Self-Managed 또는 전용 설치를 사용하는 고객들은 GitLab 인스턴스를 업그레이드할 필요 없이 더 나은 AI 기능을 지원받을 수 있게 됩니다.

현재 실험 중인 기능은 이러한 일반적인 API를 사용할 수 있으나, Self-Managed 설치를 위해 기능을 일반적으로 사용 가능하게하기 전에 단일 목적 API 엔드포인트로 변환하는 데 노력해야 합니다. 이렇게 함으로써, AI 공급 업체의 풍경이 변한다 하더라도 장기적으로 기능을 지원할 수 있게 됩니다.

GitLab 팀 멤버들이 사용할 수 있는 실험용 REST API도 단기적으로 이 프록시를 사용해야 합니다. 장기적으로는 개발자가 GitLab 소유의 인증을 사용하여 실험을 진행하는 데 AI 공급 업체에 대한 액세스를 제공해야 합니다. 이렇게 하면 새로운 기능을 시도하는 개발자들의 트래픽을 유료 고객을 서비스하는 플릿에서 분리할 수 있습니다.

GitLab 인스턴스의 API

이것은 외부 클라이언트가 지역 GitLab 인스턴스에서 사용할 수 있는 API입니다. 예를 들어, self-managed 인스턴스에 연결된 VSCode와 같은 경우입니다.

이러한 버전은 크게 달라질 수 있습니다. VSCode 확장 프로그램이 개발자에 의해 최신 상태로 유지될 수 있지만, 작업에 사용하는 GitLab 인스턴스는 이전 버전으로 유지될 수 있습니다. 따라서 안정성과 유연성에 대한 동일한 요구 사항이 AI 게이트웨이에 대한 클라이언트에도 적용됩니다.

최초 반복에서는 VSCode 확장 프로그램과 Web-IDE가 보내는 현재 REST 페이로드를 유지하되, 이를 적절한 GitLab 설치로 직접 전달할 수 있습니다. GitLab-rails는 페이로드를 AI-게이트웨이에게 해석할 필요 없이 래핑할 수 있습니다.

이렇게 하면 확장 프로그램에서 요청을받은 GitLab 인스턴스는 이를 이해하여 AI-Gateway로 전달할 필요가 없습니다. GitLab은 prompt_components에 정보를 추가하고 기존에 있던 모든 것들을 AI-게이트웨이에 직접 전달할 수 있습니다.

다른 클라이언트(예: VSCode)에서 요청이 시작되면, GitLab-rails는 다른 개선 및 프롬프트와 함께 전체 페이로드를 전달해야 합니다. 이것은 최신 버전의 클라이언트에서 오래된 GitLab 설치를 통해 최근 AI-게이트웨이로 이동하는 변경 사항을 지원할 수 있도록 필요합니다.

토론: 이 첫 번째 반복은 REST+JSON 방식을 사용하고 있습니다. 현재 VSCode 확장 프로그램이 모델 게이트웨이와 통신하고 있는 방식입니다. 따라서 기존의 페이로드를 래핑하는데 이어서 교차 버전 호환성의 추가적인 이점이 있습니다. 그러나 향후 반복이 REST+JSON을 사용해야 한다는 것은 아닙니다. 각 기능마다 고유한 엔드포인트가 있기 때문에 프로토콜 또한 다를 수 있습니다.

인증 및 권한 부여

GitLab은 권한의 첫 번째 레이어를 제공합니다: 사용자를 인증하고 사용자가 사용하려는 기능을 사용할 수 있는 라이선스가 있는지 확인합니다. 이는 GitLab에 이미 내장된 인증, 정책 및 라이선스 확인을 통해 수행될 수 있습니다.

AI-게이트웨이에서 GitLab-인스턴스를 인증하는 것은 다음에서 논의되었습니다:

• 이슈 177
• Epic 10808

최종 사용자, GitLab 인스턴스 및 AI-게이트웨이 간의 신뢰 위임 메커니즘에 대한 구체적인 메커니즘은 Cloud Connector 접근 제어 문서에서 다루고 있습니다.

임베딩

임베딩은 모든 기능을 위해 단일 엔드포인트로 요청할 수 있으며, 예를 들어 다음과 같은 요청을 통해 가능합니다:

POST /internal/embeddings

{
  "content": "The lazy fox and the jumping dog",
  "content_type": "issue_title",
  "metadata": {
    "source": "GitLab EE",
    "version": "16.3"
  }
}

content_type과 content 속성은 앞으로 적절한 것에 따라 다른 모델에서 임베딩을 생성하는 데 사용될 수 있습니다.

응답에는 사용된 제공자와 모델 외에도 임베딩 벡터가 포함됩니다. 예를 들면 다음과 같습니다:

{
  "response": [0.2, -1, ...],
  "metadata": {
    "identifier": "8badf00d",
    "model": "text-embedding-ada-002",
    "provider": "open_ai",
  }
}

임베딩을 저장할 때는 모델 및 제공자 데이터를 포함해야 합니다. 임베딩이 프롬프트를 생성하는 데 사용될 때 페이로드에 해당 메타데이터를 포함하여 임베딩의 품질을 판단할 수 있습니다.

배포

현재 AI-게이트웨이가 될 모델 게이트웨이는 gitlab-org/modelops/applied-ml/code-suggestions/ai-assist의 프로젝트 저장소에서 배포됩니다.

이것은 자체 프로젝트에서 Kubernetes 클러스터로 배포됩니다. 현재 엔지니어들이 직접 테스트하기 위해 사용하는 스테이징 환경이 있습니다.

향후에는 Runway를 사용하여 배포될 것입니다. 그 시점에는 프로덕션 및 스테이징 배포가 있을 것입니다. 스테이징 배포는 프로덕션 단계에 도달하는 것을 막을 수 있는 자동화된 QA 실행에 사용될 수 있습니다.

더 많은 테스트 전략은 &10563에서 논의 중입니다.

대체 솔루션

대체 솔루션에 대해 applied-ml/code-suggestions/ai-assist#161에서 논의되었습니다.