AI 기능 기반 3rd-party 통합

로컬 개발 환경에서 GitLab Duo 기능 설정 지침

필요 사항: AI 게이트웨이 설치

왜: 모든 Duo 기능은 LLM 요청을 AI 게이트웨이를 통해 라우팅합니다.

방법: GDK와 함께 AI 게이트웨이를 설치하려면 다음 지침을 따르세요. 대부분의 사용자에게는 이 경로를 권장합니다.

또한, AI 게이트웨이를 설치하는 방법은 다음과 같습니다:

AI 게이트웨이를 GDK를 통해 실행하지 않는 특정 이유가 있는 사용자에게만 이를 권장합니다.

필요 사항: GitLab-Rails에서 라이선스 설정

왜: GitLab Duo는 프리미엄 및 얼티밋 고객에게 제공됩니다. GDK에는 아마도 얼티밋 라이선스가 필요할 것입니다. 얼티밋 라이선스를 통해 모든 GitLab Duo 기능에 액세스할 수 있습니다.

방법:

로컬 인스턴스용 EE 라이선스를 얻는 프로세스를 따르고, 라이선스를 업로드하세요.

적용된 라이선스를 확인하려면 관리 영역 > 구독으로 이동하여 구독 요금제를 확인하세요.

GDK 설정 및 실행

옵션 A: SaaS (GitLab.com) 모드에서

왜: 대부분의 Duo 기능이 먼저 GitLab.com에서 제공되므로 SaaS 모드로 실행하면 대부분의 기능에 액세스할 수 있습니다.

방법:

그룹에 대해 Duo 기능을 설정하는 Rake 작업을 실행하세요:

GITLAB_SIMULATE_SAAS=1 bundle exec 'rake gitlab:duo:setup[test-group-name]'

gdk restart

test-group-name을 원하는 최상위 그룹의 이름으로 대체하세요. 그룹을 구성합니다. 그룹이 없는 경우 새 그룹을 만듭니다.

스크립트가 성공했는지 확인하세요. 성공하지 못한 경우 해결 방법에 대한 링크가 포함된 오류 메시지가 표시됩니다. 성공할 때까지 스크립트를 다시 실행할 수 있습니다.

SaaS 모드에서 Duo 기능이 활성화된 그룹의 구성원으로 함께하는 것이 많은 AI 기능을 활성화시킵니다. 테스트 사용자가 Duo 기능이 활성화된 그룹의 구성원임을 확인하세요 (test-group-name).

이 Rake 작업이 해당 그룹에 연결된 Duo Enterprise 애드온을 생성합니다.

Duo Pro 애드온을 연결해야 하는 경우 명령은 다음과 같습니다:

GITLAB_SIMULATE_SAAS=1 bundle exec 'rake gitlab:duo:setup[test-group-name,duo_pro]'

Duo Pro 애드온은 기능의 더 작은 범위를 제공합니다. 애드온의 사용 여부는 사용하려는 기능에 따라 다릅니다.

옵션 B: Self-managed 모드에서

왜: 사용자 정의 모델과 같은 특정한 Self-managed 테스트를 수행하려는 경우.

방법:

인스턴스에 대한 Duo 기능을 설정하는 Rake 작업을 실행하세요:

GITLAB_SIMULATE_SAAS=0 bundle exec 'rake gitlab:duo:setup_instance'

gdk restart

이 Rake 작업은 인스턴스에 연결된 Duo Enterprise 애드온을 생성합니다.

Duo Pro 애드온을 연결해야 하는 경우 명령은 다음과 같습니다:

GITLAB_SIMULATE_SAAS=0 bundle exec 'rake gitlab:duo:setup_instance[duo_pro]'

Duo Pro 애드온은 기능의 더 작은 범위를 제공합니다. 애드온의 사용 여부는 사용하려는 기능에 따라 다릅니다.

권장: `CLOUD_CONNECTOR_SELF_SIGN_TOKENS` 환경 변수 설정

왜: 이 환경 변수를 설정하면 로컬 GitLab 인스턴스가 CustomersDot과 동기화 없이 자체 토큰을 발급할 수 있습니다. 이 설정을 하면 CustomersDot 설치를 건너뛸 수 있습니다.

방법: 다음을 GDK 루트의 env.runit 파일에 설정하세요:

# <GDK-root>/env.runit

export CLOUD_CONNECTOR_SELF_SIGN_TOKENS=1

변경 사항을 적용하려면 GDK를 다시 시작해야 합니다.

CLOUD_CONNECTOR_SELF_SIGN_TOKENS=1을 사용하는 경우, root/admin 사용자는 http://localhost:3000/admin/code_suggestions 페이지의 건강 확인을 통해 “코드 완성 테스트가 성공했습니다”알림을 받기 위해 할당된 좌석이 있어야 합니다.

저희 고객 (운영 환경)은 Code Suggestions 건강 확인을 위해 좌석을 할당하는 것이 필요하지 않습니다.

권장: 레일즈 콘솔에서 클라이언트 테스트

왜: 모든 설정 단계를 완료했으므로 GitLab Duo가 실제로 작동하는지 확인해야 합니다.

방법:

설정이 완료된 후 GitLab-Rails에서 클라이언트를 테스트하여 AI 게이트웨이에 올바르게 액세스할 수 있는지 확인할 수 있습니다:

gdk start를 실행합니다.
gdk rails console로 Rails 콘솔에 로그인합니다.

모델과 대화해보세요:

# Anthropic 모델과 대화
Gitlab::Llm::Anthropic::Client.new(User.first, unit_primitive: 'duo_chat').complete(prompt: "\n\nHuman: Hi, How are you?\n\nAssistant:")

# Vertex AI 모델과 대화
Gitlab::Llm::VertexAi::Client.new(User.first, unit_primitive: 'documentation_search').text_embeddings(content: "How can I create an issue?")

# `/v1/chat/agent` 엔드포인트 테스트
Gitlab::Llm::Chain::Requests::AiGateway.new(User.first).request(prompt: [{role: "user", content: "Hi, how are you?"}])

참고: Cloud Connector에 단위 기본을 등록하려면 이 문서를 참조하세요.

선택 사항: AI 게이트웨이에서 인증 및 권한 부여 활성화

왜: AI 게이트웨이에는 클라이언트가 기능에 액세스할 수 있는 권한이 있는지 확인하는 인증 및 권한 부여 플로우가 있습니다. 인증은 GitLab 인프라 팀이 호스팅하는 모든 실제 환경에서 강제로 적용됩니다. 로컬 개발 환경에서 이 플로우를 테스트하려면 권장사항입니다.

참고: 개발 환경(예: GDK)에서는 이 프로세스가 기본적으로 비활성화됩니다.

권한 확인을 활성화하려면 AI 게이트웨이의 application setting 파일(<GDK-root>/gitlab-ai-gateway/.env)에 있는 AIGW_AUTH__BYPASS_EXTERNAL을 false로 설정하세요.

교체: 교체하여 애플리케이션 설정을 변경합니다.

옵션 1: GitLab 인스턴스를 사용하여 공급자로 사용

왜: 이것은 가장 간단한 방법으로 인증을 테스트하고 있으며, GitLab.com에서의 설정을 반영합니다.

방법: Assuming that you are running the AI Gateway with GDK, apply the following configuration to GDK:

# <GDK-root>/env.runit

export GITLAB_SIMULATE_SAAS=1

아래 설정을 AI Gateway의 application settings file에 업데이트하세요:

# <GDK-root>/gitlab-ai-gateway/.env

AIGW_AUTH__BYPASS_EXTERNAL=false
AIGW_GITLAB_URL=<your-gdk-url>

그리고 gdk restart.

옵션 2: 고객의 인스턴스를 공급자로 사용

왜: 고객의 인스턴스 설정은 클라우드 라이선싱에 관련된 기능을 테스트하거나 업데이트하려는 경우, 또는 GDK를 SaaS 모드가 아닌 상태로 실행하는 경우에 필요합니다.

참고: 이 설정은 어렵습니다. 로컬에서 customersDot 통합을 테스트하기 쉽게하는 방법에 대해 논의하는 이슈가 있습니다. 해당 문제가 해결될 때까지 이 설정 과정은 시간이 많이 소요되므로 가능하면 피해야 합니다.

어떠한 이유로든 지역 GitLab Rails 인스턴스에 대해 customersDot를 작동시켜야 하는 경우, Slack의 #s_fulfillment_engineering로 문의하세요. AI 사용 사례를 제공하기 위해 다른 시스템과 CDot의 통합에 대한 문의는 #g_cloud_connector로 문의하세요.

도움말

여기를 통해 저희에게 연락하는 방법을 확인하세요.
GitLab Duo Chat 작업에 대한 가이드라인을 확인하세요.

로컬 개발 팁

사용자 인터페이스에서 응답 시간이 너무 오래 걸릴 때는, gdk restart rails-background-jobs를 실행하여 Sidekiq을 다시 시작하는 것을 고려해보세요. 이것이 도움이 되지 않는다면 gdk kill을 시도한 다음 gdk start를 시도하세요.
또는 Sidekiq을 완전히 우회하고 서비스를 동기적으로 실행하세요. 이것은 GraphQL 오류가 Sidekiq 로그가 아닌 네트워크 검사기에서 사용할 수 있기 때문에 오류 디버깅에 도움이 될 수 있습니다. 이를 위해 Llm::CompletionWorker 클래스의 perform_for 메서드를 일시적으로 변경하여 perform_async를 perform_inline로 변경하세요.

기능 개발 (추상화 레이어)

기능 플래그

모든 AI 기능 작업에 다음 기능 플래그를 적용하세요:

모든 GitLab Duo Chat 기능에 적용되는 일반 플래그 (ai_duo_chat_switch). 기본적으로 활성화됩니다.
다른 모든 AI 기능에 적용되는 일반 플래그 (ai_global_switch). 기본적으로 활성화됩니다.
그 기능에 특화된 플래그. 기능 플래그 이름은 라이센스된 기능 이름과 다르게 지어야 합니다.

모든 기능 플래그 및 사용 방법에 대한 목록은 기능 플래그 트래커 에픽을 참조하세요.

AI Gateway로 기능 플래그 푸시

기능 플래그를 AI Gateway로 푸시할 수 있습니다. 이것은 AI Gateway에 기능이 포함된 상태에서도 점진적으로 사용자 인터페이스 변경을 배포하는 데 유용합니다. 다음 예제를 참조하세요:

# 기능 플래그 상태를 AI Gateway로 푸시합니다.
Gitlab::AiGateway.push_feature_flag(:new_prompt_template, user)

나중에 AI Gateway에서 기능 플래그 상태를 다음과 같이 사용할 수 있습니다:

from ai_gateway.feature_flags import is_feature_enabled

# "new_prompt_template" 기능 플래그가 활성화되어 있는지 확인합니다.
if is_feature_enabled('new_prompt_template'):
  # 새로운 프롬프트 템플릿에서 프롬프트를 작성합니다
else:
  # 기존의 프롬프트 템플릿에서 프롬프트를 작성합니다

중요: 정리 단계에서, GitLab-Rails 리포지토리에서 피처 플래그를 제거하기 전에 AI Gateway 리포지토리에서 해당 기능 플래그를 제거하세요. 먼저 GitLab-Rails 리포지토리에서 플래그를 정리하면, 해당 기능 플래그는 기본 상태이므로 AI Gateway에서 즉시 비활성화되므로 예상치 못한 동작을 만날 수 있습니다.

중요: AI Gateway에서 기능 플래그를 정리하면, GitLab.com, Self-Managed GitLab 및 전용 포함하여 모든 GitLab 인스턴스에 즉시 변경 사항이 배포됩니다.

기술적 세부 사항: push_feature_flag가 활성화된 기능 플래그에서 실행될 때, 플래그 이름은 나중에 현재 컨텍스트에서 캐시되어, GitLab-Sidekiq/Rails 요청시 AI Gateway로 x-gitlab-enabled-feature-flags HTTP 헤더에 첨부됩니다.

유사한 개념으로 우리는 push_frontend_feature_flag로 frontend에 기능 플래그를 푸시합니다.

GraphQL API

Abstraction Layer를 사용하여 AI 제공업체 API에 연결하기 위해, aiAction이라는 확장 가능한 GraphQL API를 사용하세요. input은 키/값 쌍을 받아들이며, key는 수행해야 하는 동작입니다. 하나의 변이 요청당 하나의 AI 동작만 허용됩니다.

변이의 예:

mutation {
  aiAction(input: {summarizeComments: {resourceId: "gid://gitlab/Issue/52"}}) {
    clientMutationId
  }
}

예를 들어, “코드 설명” 동작을 구축하려면, input을 새로운 키 explainCode로 확장합니다. 변이는 다음과 같이 보일 것입니다:

mutation {
  aiAction(
    input: {
      explainCode: { resourceId: "gid://gitlab/MergeRequest/52", code: "foo() { console.log() }" }
    }
  ) {
    clientMutationId
  }
}

그런 다음 GraphQL API는 Anthropic Client를 사용하여 응답을 보냅니다.

응답 수신하는 방법

AI 제공 업체로의 API 요청은 백그라운드 작업으로 처리됩니다. 따라서 요청을 유지하지 않고, 프런트엔드에서는 구독의 응답을 요청과 매치해야 합니다.

경고: userId와 resourceId만 사용하는 경우, 요청에 대한 올바른 응답을 결정하는 것은 문제를 일으킬 수 있습니다. 예를 들어 두 가지 AI 기능이 동일한 userId와 resourceId를 사용하는 경우, 두 구독은 서로의 응답을 받게 됩니다. 이러한 간섭을 방지하기 위해 clientSubscriptionId를 도입했습니다.

aiCompletionResponse 구독에서 응답을 매치하려면 aiAction 뮤테이션에 clientSubscriptionId를 제공할 수 있습니다.

clientSubscriptionId는 각 기능당 및 페이지 내에서 유일해야 하며, 다른 AI 기능에 간섭하지 않도록 해야 합니다. UUID를 사용하는 것을 권장합니다.
aiAction 뮤테이션의 일부로 clientSubscriptionId가 제공될 때에만, aiCompletionResponse를 브로드캐스트하는 데 사용됩니다.
clientSubscriptionId가 제공되지 않으면, aiCompletionResponse에는 userId 및 resourceId만 사용됩니다.

예를 들어 댓글을 요약하는 뮤테이션의 경우, 다음과 같이 randomId를 제공합니다:

mutation {
  aiAction(
    input: {
      summarizeComments: { resourceId: "gid://gitlab/Issue/52" }
      clientSubscriptionId: "randomId"
    }
  ) {
    clientMutationId
  }
}

그런 다음 구성 요소에서 aiCompletionResponse에 대해 userId, resourceId, 및 clientSubscriptionId("randomId")를 사용하여 청취합니다:

subscription aiCompletionResponse(
  $userId: UserID
  $resourceId: AiModelID
  $clientSubscriptionId: String
) {
  aiCompletionResponse(
    userId: $userId
    resourceId: $resourceId
    clientSubscriptionId: $clientSubscriptionId
  ) {
    content
    errors
  }
}

채팅을 위한 구독은 다르게 작동합니다.

많은 동시 구독이 발생하지 않도록 하기 위해서, 뮤테이션이 전송된 후에만 구독하도록 skip()을 사용해야 합니다.

현재 추상화 계층 흐름

다음 그래프는 VertexAI를 예로 들었습니다. 다른 제공업체를 사용할 수 있습니다.

flowchart TD A[GitLab 프런트엔드] -->B[AiAction GraphQL 뮤테이션] B --> C[Llm::ExecuteMethodService] C --> D[서비스 중 하나, 예: Llm::GenerateSummaryService] D -->|scheduled| E[AI 워커:Llm::CompletionWorker] E -->F[::Gitlab::Llm::Completions::Factory] F -->G[`::Gitlab::Llm::VertexAi::Completions::...` 클래스, `::Gitlab::Llm::Templates::...` 클래스 사용] G -->|호출| H[Gitlab::Llm::VertexAi::Client] H --> |응답| I[::Gitlab::Llm::GraphqlSubscriptionResponseService] I --> J[GraphqlTriggers.ai_completion_response] J --> K[::GitlabSchema.subscriptions.trigger]

새로운 작업 구현 방법

새로운 AI 작업을 구현하려면 GitLab 단일 모노리스 및 AI 게이트웨이에서 변경이 필요합니다. 이후 샘플로 이슈 설명을 주어진 프롬프트에 따라 다시 작성할 수 있는 작업을 구현하는 예시를 사용하겠습니다.

1. 클라우드 커넥터 기능 목록에 작업 추가

Cloud Connector 구성에는 서비스에 액세스하기 위해 필요한 권한과 추가 메타데이터가 저장됩니다. 자세한 내용은 Cloud Connector: Configuration를 참조하십시오.

# ee/config/cloud_connector/access_data.yml

services:
  # ...
  rewrite_description:
    backend: 'gitlab-ai-gateway'
    bundled_with:
      duo_enterprise:
        unit_primitives:
          - rewrite_issue_description

2. AI 게이트웨이에 에이전트 정의 생성

AI Gateway 프로젝트에서 새로운 에이전트 정의를 ai_gateway/agents/definitions 하위에 만들어야 합니다. 작업의 이름과 해당 에이전트를 나타내는 새로운 YAML 파일을 만들어야 합니다. 사용할 모델 및 제공자, 그리고 모델에 공급될 프롬프트를 지정해야 합니다. {}를 사용하여 프롬프트에 연결할 입력을 지정할 수 있습니다.

# ai_gateway/agents/definitions/rewrite_description/base.yml

name: Description rewriter
model:
  name: claude-3-sonnet-20240229
  params:
    model_class_provider: anthropic
prompt_template:
  system: |
    현재 설명을 다시 작성하는 유용한 어시스턴트입니다. 현재 설명과 설명을 다시 작성하는 방법에 대한 프롬프트가 제공됩니다. 다시 작성된 설명만 응답하십시오.

    <description>{description}</description>

    <prompt>{prompt}</prompt>

만약 AI 작업이 더 포괄적인 기능의 일부인 경우, 정의는 트리 구조로 구성할 수 있습니다:

# ai_gateway/agents/definitions/code_suggestions/generations/base.yml

name: Code generations
model:
  name: claude-3-sonnet-20240229
  params:
    model_class_provider: anthropic
...

여러 모델에 대한 프롬프트를 지정하려면, 정의의 파일명에 모델 이름을 사용합니다:

# ai_gateway/agents/definitions/code_suggestions/generations/mistral.yml

name: Code generations
model:
  name: mistral
  params:
    model_class_provider: litellm
...

3. 완료 클래스 생성

ee/lib/gitlab/llm/ai_gateway/completions/에 새로운 완료를 생성하고, Base AI Gateway 완료를 상속해야 합니다.

# ee/lib/gitlab/llm/ai_gateway/completions/rewrite_description.rb

module Gitlab
  module Llm
    module AiGateway
      module Completions
        class RewriteDescription < Base
          def agent_name
            'base' # AI Gateway에서 정의한 에이전트 이름과 일치해야 합니다.
          end

          def inputs
            { description: resource.description, prompt: prompt_message.content }
          end
        end
      end
    end
  end
end

4. 서비스 생성

ee/app/services/llm/ 아래에 새 서비스를 생성하고 BaseService에서 상속받습니다.
resource는 우리가 작업하려는 객체입니다. Ai::Model concern을 포함하는 모든 객체가 될 수 있습니다. 예를 들어 Project, MergeRequest, 또는 Issue일 수 있습니다.

# ee/app/services/llm/rewrite_description_service.rb

module Llm
  class RewriteDescriptionService < BaseService
    extend ::Gitlab::Utils::Override

    override :valid
    def valid?
      super &&
        # 서비스가 적용되는 리소스 유형을 제한할 수 있습니다
        resource.to_ability_name == "issue" &&
        # 항상 사용자가 리소스에서 이 작업을 수행할 수 있는지 확인합니다
        Ability.allowed?(user, :rewrite_description, resource)
    end

    private

    def perform
      schedule_completion_worker
    end
  end
end

5. 카탈로그에 기능 등록

Gitlab::Llm::Utils::AiFeaturesCatalogue에 이동하여 AI 작업에 대한 새 항목을 추가하세요.

class AiFeaturesCatalogue
  LIST = {
    # ...
    rewrite_description: {
      service_class: ::Gitlab::Llm::AiGateway::Completions::RewriteDescription,
      feature_category: :ai_abstraction_layer,
      execute_method: ::Llm::RewriteDescriptionService,
      maturity: :experimental,
      self_managed: false,
      internal: false
    }
  }.freeze

기존 작업을 AI 게이트웨이로 마이그레이션하는 방법

AI 작업은 처음에 GitLab 단일체에 구현되었습니다. 단일체에서 모델에 액세스하는 AI 게이트웨이로의 전환이후 프롬프트, 모델 선택 및 모델 매개변수를 AI 게이트웨이로 마이그레이션하고 있습니다. 이렇게 하면 프롬프트 및 모델 변경을 단일체 릴리스와 분리함으로써 자체 호스팅 사용자에게 개선 사항을 신속하게 제공할 수 있습니다. 기존 작업을 마이그레이션하려면 다음을 수행하세요:

새로운 작업을 구현하는 방법의 단계 1부터 3까지 따릅니다.
카탈로그에 AI 작업에 대한 항목을 수정하여 aigw_service_class로 새 완료 클래스를 나열합니다.

class AiFeaturesCatalogue
  LIST = {
    # ...
    generate_description: {
      service_class: ::Gitlab::Llm::Anthropic::Completions::GenerateDescription,
      aigw_service_class: ::Gitlab::Llm::AiGateway::Completions::GenerateDescription,
      prompt_class: ::Gitlab::Llm::Templates::GenerateDescription,
      feature_category: :ai_abstraction_layer,
      execute_method: ::Llm::GenerateDescriptionService,
      maturity: :experimental,
      self_managed: false,
      internal: false
    },
    # ...
  }.freeze

기능 플래그 ai_gateway_agents가 활성화되면 aigw_service_class가 AI 작업을 처리하는 데 사용됩니다. 올바른 작동을 확인한 후 aigw_service_class 키를 제거하고 새 AiGateway::Completions 클래스로 service_class를 대체하여 영구적인 제공자로 만들 수 있습니다.

AI 게이트웨이에서 인증 및 권한 부여를 활성화하는 것이 선택 사항인 경우에 대한 GitLab AI 게이트웨이 문서에서 자세한 정보를 참조하세요.

요청에 대한 응답 매칭

여러 사용자의 요청이 병렬로 처리될 수 있기 때문에 응답을 받을 때 원래 요청과 일치시키기 어려울 수 있습니다. requestId 필드를 사용하여 이러한 목적에 사용할 수 있습니다. 왜냐하면 요청과 응답은 모두 동일한 requestId UUID를 가지는 것이 확증되기 때문입니다.

캐싱

AI 요청 및 응답은 캐시될 수 있습니다. 현재 구현에서는 이 캐시를 사용하여 사용자 상호 작용을 표시하는 데 사용되고 있습니다. 현재 구현에서는 이 캐시를 사용하여 사용자가 요청을 반복할 때 AI 서비스에 대한 연이은 호출을 건너뛰기 위해 사용되고 있지는 않습니다.

query {
  aiMessages {
    nodes {
      id
      requestId
      content
      role
      errors
      timestamp
    }
  }
}

이 캐시는 채팅 기능에 사용되고 있습니다. 기타 서비스의 경우 캐싱이 비활성화되어 있습니다. cache_response: true 옵션을 사용하여 서비스에 대해이를 활성화할 수 있습니다.

캐싱의 제한 사항은 다음과 같습니다:

메시지는 Redis 스트림에 저장됩니다.
사용자 당 메시지에 대한 단일 스트림이 있습니다. 즉, 현재 모든 서비스가 동일한 캐시를 공유합니다. 필요한 경우 인프라 팀과 상의한 후 예상되는 메시지 양을 처리할 수 있는지 여부를 확인한 후 사용자 당 여러 스트림으로 확장할 수 있습니다.
마지막 50개의 메시지(요청 + 응답)만 보관됩니다.
스트림의 만료 시간은 마지막 메시지 추가 후 3일입니다.
사용자는 자신의 메시지에만 액세스할 수 있습니다. 캐시 수준에서 권한이 없으며 (현재 사용자가 아닌 경우) 권한이 예상되는 경우 서비스 계층에서 액세스됩니다.

루트 네임스페이스 수준에서 허용된 기능을 기반으로 리소스의 기능을 확인하세요

AI 기능의 사용을 제한하는 루트 네임스페이스 수준에서 허용된 하나의 설정이 있습니다.

experiment_features_enabled

주어진 네임스페이스에서 해당 기능이 허용되었는지 확인하려면 다음을 호출하세요:

Gitlab::Llm::StageCheck.available?(namespace, :name_of_the_feature)

기능의 이름을 Gitlab::Llm::StageCheck 클래스에 추가하세요. 여기에는 실험 및 베타 기능을 구분하는 배열이 있습니다.

이렇게 하면 다음과 같은 다양한 케이스에 대비할 수 있습니다:

만일 기능이 어느 배열에도 없다면, 확인은 true를 반환합니다. 예를 들어, 해당 기능이 GA로 이동된 경우입니다.

실험 단계에서 기능을 베타 단계로 이동하려면, 해당 기능의 이름을 EXPERIMENTAL_FEATURES 배열에서 BETA_FEATURES 배열로 이동하세요.

AI API 및 프롬프트 호출 구현

CompletionWorker에서 Completions::Factory를 호출하고 해당 서비스를 초기화하며 실제 API 호출을 실행합니다. 우리의 예제에서는 VertexAI를 사용하고 두 가지 새로운 클래스를 구현할 것입니다:

# /ee/lib/gitlab/llm/vertex_ai/completions/rewrite_description.rb

module Gitlab
  module Llm
    module VertexAi
      module Completions
        class AmazingNewAiFeature < Gitlab::Llm::Completions::Base
          def execute
            prompt = ai_prompt_class.new(options[:user_input]).to_prompt

            response = Gitlab::Llm::VertexAi::Client.new(user, unit_primitive: 'amazing_feature').text(content: prompt)

            response_modifier = ::Gitlab::Llm::VertexAi::ResponseModifiers::Predictions.new(response)

            ::Gitlab::Llm::GraphqlSubscriptionResponseService.new(
              user, nil, response_modifier, options: response_options
            ).execute
          end
        end
      end
    end
  end
end

# /ee/lib/gitlab/llm/vertex_ai/templates/rewrite_description.rb

module Gitlab
  module Llm
    module VertexAi
      module Templates
        class AmazingNewAiFeature
          def initialize(user_input)
            @user_input = user_input
          end

          def to_prompt
            <<~PROMPT
            당신은 다음과 같은 맥락에 대한 코드를 작성하는 어시스턴트입니다:

            맥락: #{user_input}
            PROMPT
          end
        end
      end
    end
  end
end

여러 AI 공급업체를 지원하기 때문에 동일한 예제에 이러한 제공업체를 사용할 수도 있습니다:

Gitlab::Llm::VertexAi::Client.new(user, unit_primitive: 'your_feature')
Gitlab::Llm::Anthropic::Client.new(user, unit_primitive: 'your_feature')

모니터링

각 AI 액션의 오류 비율 및 응답 대기 시간 apdex는 SLI Detail: llm_completion 아래에서 Sidekiq Service 대시보드에서 찾을 수 있습니다.
사용한 토큰, 각 AI 기능의 사용 및 기타 통계는 periscope 대시보드에서 찾을 수 있습니다.
AI Gateway 로그.
AI Gateway 메트릭.
프록시를 통한 기능 사용 대시보드.

로그

개요

기존 GitLab Rails Monolith 인스턴스에 대한 표준 로깅 외에, 대형 언어 모델(LLM)을 기반으로 한 기능에 대한 전문화된 로깅이 가능합니다.

로깅된 이벤트

현재 로깅된 이벤트는 여기에 문서화되어 있습니다.

구현

로거 클래스

LLM별 로깅을 구현하려면 Gitlab::Llm::Logger 클래스를 사용하세요.

개인 정보 고려사항

중요: 사용자 입력 및 사용자 데이터를 포함하는 완전한 프롬프트는 명시적으로 허용되지 않는 한 로그에 남겨서는 안 됩니다.

기능 플래그

expanded_ai_logging이라는 기능 플래그가 민감한 데이터의 로깅을 제어합니다. 기능 플래그 상태에 따라 조건부 로깅을 위해 conditional_info 도우미 메서드를 사용하세요:

현재 사용자에 대해 기능 플래그가 활성화된 경우, 정보를 info 수준으로 로깅합니다 (로그는 Kibana에서 접근 가능).
현재 사용자에 대해 기능 플래그가 비활성화된 경우, 정보를 info 수준으로 로깅하지만 선택적 매개변수는 포함되지 않습니다(Kibana에서 로그는 접근 가능하지만 필수 필드만 포함됨).

모범 사례

LLM 기능에 대한 로깅을 구현할 때 다음 사항을 고려하세요:

디버깅을 위한 중요 정보 식별.
적절한 승인 없이 민감한 사용자 데이터를 로깅하지 않음으로서 개인 정보 요구 사항 준수 보장.
conditional_info 도우미 메서드를 사용하여 expanded_ai_logging 기능 플래그를 준수.
문제 해결 및 분석을 위한 의미 있는 통찰을 제공하기 위해 로그를 구조화.

사용 예

# 로깅 핸들링하는 concern 포함
include Gitlab::Llm::Concerns::Logger

# 잠재적으로 민감한 정보 로깅
log_conditional_info(user, message:"User prompt processed", event_name: 'ai_event', ai_component: 'abstraction_layer', prompt: sanitized_prompt)

# 응용 프로그램 오류 정보 로깅
log_error(user, message: "시스템 응용 프로그램 오류", event_name: 'ai_event', ai_component: 'abstraction_layer', error_message: sanitized_error_message)

중요: 저희의 데이터 보존 정책에 익숙해지시고 사용자 입력 및 LLM-originated 출력이 로깅되지 않도록 확인하십시오.

보안

인공 지능(AI) 기능에 대한 안전한 코딩 지침을 참조하세요.

AI 기능 기반 3rd-party 통합

로컬 개발 환경에서 GitLab Duo 기능 설정 지침

필요 사항: AI 게이트웨이 설치

필요 사항: GitLab-Rails에서 라이선스 설정

GDK 설정 및 실행

옵션 A: SaaS (GitLab.com) 모드에서

옵션 B: Self-managed 모드에서

권장: CLOUD_CONNECTOR_SELF_SIGN_TOKENS 환경 변수 설정

권장: 레일즈 콘솔에서 클라이언트 테스트

선택 사항: AI 게이트웨이에서 인증 및 권한 부여 활성화

옵션 1: GitLab 인스턴스를 사용하여 공급자로 사용

옵션 2: 고객의 인스턴스를 공급자로 사용

도움말

로컬 개발 팁

기능 개발 (추상화 레이어)

기능 플래그

AI Gateway로 기능 플래그 푸시

GraphQL API

응답 수신하는 방법

현재 추상화 계층 흐름

새로운 작업 구현 방법

1. 클라우드 커넥터 기능 목록에 작업 추가

2. AI 게이트웨이에 에이전트 정의 생성

3. 완료 클래스 생성

4. 서비스 생성

5. 카탈로그에 기능 등록

기존 작업을 AI 게이트웨이로 마이그레이션하는 방법

요청에 대한 응답 매칭

캐싱

루트 네임스페이스 수준에서 허용된 기능을 기반으로 리소스의 기능을 확인하세요

AI API 및 프롬프트 호출 구현

모니터링

로그

개요

로깅된 이벤트

구현

로거 클래스

개인 정보 고려사항

기능 플래그

모범 사례

사용 예

보안

도움말

기능 사용 가능성과 제품 평가판

도움받기

권장: `CLOUD_CONNECTOR_SELF_SIGN_TOKENS` 환경 변수 설정