GitLab Duo 术语表

以下术语列表包含通用含义，但在 GitLab 中可能有特定含义。如果您遇到与 AI 相关的技术术语，认为应列入此列表，欢迎添加！

通用术语

Adapters（适配器）

微调的一种变体。不直接修改模型层权重，而是将新训练的层添加到模型中，或托管在上游独立模型中。也称为基于适配器的模型。通过选择性微调特定模块而非整个模型，适配器使预训练模型能针对不同任务进行定制，且仅需少量增加参数。此方法可在不改变模型基础结构的情况下，实现模型精确的任务特定调整。

AI gateway（AI 网关）

为非 SaaS GitLab 用户访问 AI 功能提供的独立服务。当 Cloud Connector 服务就绪后，相关逻辑将迁移至该服务。未来，AI 网关将用于托管代理请求至 AI 提供商的端点，消除 GitLab Rails 单体直接集成和通信第三方大语言模型（LLMs）的需求。设计文档

AI gateway prompt（AI 网关提示词）

对提示词模板、模型选择和模型参数的封装。作为 AI 网关作为单体访问模型的唯一入口 的一部分，我们正将这些组件从 GitLab Rails 单体迁移至 AI 网关中的 prompts 包。

AI gateway prompt registry（AI 网关提示词注册表）

负责维护可用于执行特定操作的 AI 网关提示词列表的组件。目前我们使用 LocalPromptRegistry，它从 AI 网关的 YAML 文件中读取定义。

Air-Gapped Model（隔离模型）

仅在组织内网托管的模型。在 GitLab AI 功能的上下文中，此类模型可能连接到隔离的 GitLab 实例。

Bring Your Own Model (BYOM)（自带模型）

连接到一个或多个 GitLab Duo 功能的第三方模型。可以是现成的开源（OS）模型、微调模型或闭源模型。GitLab 计划为 GitLab Duo 功能支持特定的、经验证的 BYOM，但不计划支持通用的 BYOM 使用。

Chat Evaluation（聊天评估）

自动评估 GitLab Duo Chat 对各类用户问题的帮助性和准确性的机制。MVC 是通过 GitLab CI 运行的 RSpec 测试，向 Chat 提问集，然后由两个不同的第三方 LLM 判断生成答案的准确性。MVC。下一迭代设计文档。

Cloud Connector（云连接器）

访问多个 GitLab 部署、实例和单元通用服务的方式。我们将其用作伞形术语，指代使此类服务对所有 GitLab 客户可用的技术解决方案和 API 集合。更多信息请参阅 Cloud Connector 架构。

Closed Source Model（闭源模型）

由组织微调或从头构建的私有模型。可作为云服务托管，例如 ChatGPT。

Consensus Filtering（共识过滤）

一种 LLM 评估方法。要求 LLM 评估者对多个 LLM 针对提示集的输出进行评分和比较。这是聊天评估 MVC 使用的评估方法。模型验证团队问题。

Context（上下文）

围绕数据点、事件或信息片段的相关信息，有助于阐明其含义和影响。对于 GitLab Duo Chat，上下文是用户问题中引用的 Issue 或 Epic 的属性。

Custom Model（自定义模型）

使用自托管模型、BYOM、微调模型、RAG 增强模型或基于适配器的模型实现的任何 GitLab Duo 功能。

Embeddings（嵌入）

在机器学习和大型语言模型的上下文中，嵌入是一种将单词、短语甚至整个文档表示为连续向量空间中密集数值向量的技术。在 GitLab 中，我们使用 Vertex AI 的 Embeddings API 创建 GitLab 文档的向量表示。这些嵌入存储在 embeddings 数据库的 vertex_gitlab_docs 数据库表中。嵌入搜索使用 vector 扩展在 Postgres 中完成。Vertex 嵌入数据库通过每日运行 Llm::Embedding::GitlabDocumentation::CreateEmbeddingsRecordsWorker 作为 cronjob，根据最新版本的 GitLab 文档进行更新。

Fine Tuning（微调）

使用监督学习过程修改现有模型，该过程利用标记示例数据集更新 LLM 权重，提高其在代码补全或聊天等特定任务中的输出质量。

Foundational Model（基础模型）

使用通用目标（通常是下一个词预测）训练的通用 LLM。这些模型功能强大且灵活，可通过微调或提示工程调整以解决许多领域特定任务。这意味着这些通用模型非常适合作为许多下游模型的基础。基础模型示例：GPT-4o、Claude 3.7 Sonnet。

Frozen Model（冻结模型）

无法进行微调的 LLM（也称为 Frozen LLM）。

GitLab Duo

GitLab DevSecOps 平台上的 AI 辅助功能。这些功能旨在帮助提高开发速度并解决软件开发生命周期中的关键痛点。另请参阅 GitLab Duo 功能页面。

GitLab Managed Model（GitLab 托管模型）

由 GitLab 管理的 LLM。目前所有 GitLab 托管模型 均托管在外部并通过 AI 网关访问。使用 GitLab 拥有的 API 密钥访问这些模型。

Golden Questions（黄金问题）

我们认为用户应能向 GitLab Duo Chat 提问的问题类型的子集。用于生成聊天评估数据。聊天 Beta 问题。

Ground Truth（真实数据）

针对给定输入确定的真实输出，代表 AI 模型旨在学习和预测的现实。真实数据通常由人工标注，但也可能来自可信来源，例如针对特定用例具有已知良好输出的 LLM。

Local Model（本地模型）

在用户工作站上运行的 LLM。更多信息。

LLM（大语言模型）

大语言模型（LLM）是经过训练以理解和生成类人文本的超大规模神经网络。对于 GitLab Duo 功能，GitLab 目前正与托管在 Google 和 Anthropic 的冻结模型合作。

Model Validation（模型验证）

AI 驱动阶段内的团队，负责提示库、支持 GitLab Duo 功能的 AI 验证，以及研究支持 GitLab 其他 AI 用例的 AI/ML 模型。团队手册章节。

Offline Model（离线模型）

在没有互联网或内网连接下运行的模型（例如，在飞机上笔记本电脑上运行的模型）。

Open Source Model（开源模型）

发布源代码和权重可供修改和再分发的模型。示例：Llama / Llama 2、BLOOM、Falcon、Mistral、Gemma。

Prompt library（提示词库）

“提示词库” 是一个提供 CLI 的 Python 库，用于使用 LLM 测试不同的提示技术。它通过促进假设测试，实现 LLM 应用程序的数据驱动改进。关键功能包括使用 Apache Beam 管理和运行数据流管道，以及在单个管道运行中对具有各种第三方 AI 服务的提示执行多个评估实验。代码。

Prompt Registry（提示词注册表）

用于与第三方 AI 服务交互的存储、版本化提示词。设计文档提案 MR（已关闭）。

Prompt（提示词）

发送给 LLM 以执行特定任务的自然语言指令。提示词指南。

RAG (Retrieval Augmented Generation)（检索增强生成）

作为查询的一部分向 LLM 提供上下文数据以个性化结果。RAG 用于向提示注入额外上下文，以减少幻觉并提高输出质量。

RAG Pipeline（RAG 管道）

一种将输入（如用户问题）送入系统、检索相关数据、用额外上下文增强输入、然后综合信息以生成连贯且上下文相关答案的机制。此设计模式有助于使用 LLM 进行开放域问答，因此我们将其用于回答 GitLab Duo Chat 的问题。

Self-hosted model（自托管模型）

由组织在 GitLab 外部托管并与 GitLab AI 功能交互的 LLM。另请参阅 风格指南参考。

Similarity Score（相似度分数）

一种数学方法，用于确定 LLM 生成的答案与参考真实答案之间的相似程度。另请参阅 模型验证方向页面。

Tool（工具）

执行特定 LLM 相关任务的逻辑；每个工具有其描述和自己的提示词。如何添加新工具。

Unit Primitive（基本单元）

GitLab 特定术语，指权限或访问范围可控制的基本逻辑功能。示例：duo_chat 和 code_suggestions。这些功能目前均属于 GitLab Duo Pro 许可证，但我们正在围绕每个 Duo 功能构建基本单元概念，以便 Duo 功能可轻松组合成不同分组，以适应潜在的未来产品打包需求。

Word-Level Metrics（词级指标）

一种 LLM 评估方法，在单词粒度上比较文本的各个方面。模型验证团队问题。

Zero-shot agent（零样本代理）

在通用 AI 领域中，指在训练期间未见过任何任务示例即可执行任务的学习模型或系统。在 GitLab 中，我们使用此术语特指作为 GitLab Duo Chat 的某种 LLM 驱动的空中交通管制器的代码片段。GitLab 零样本代理具有系统提示，说明 LLM 应如何解释来自 GitLab Duo Chat 的用户输入以及工具描述列表。利用此信息，代理确定使用哪个工具回答用户问题。代理可能决定无需工具直接回答问题。如果使用工具，工具的答案将反馈给零样本代理，以评估答案是否充分，或是否需要使用额外工具回答问题。

代码。

零样本代理实际应用。

GitLab Duo Agent Platform 术语

核心层概念（GitLab 特定）

Flow（流程）

面向目标的结构化图，编排代理和工具以交付单一、具有经济价值的结果（例如 创建代码审查 MR、分类问题）。

• 结构 - 明确阶段：规划 → 执行 → 完成
• 节点 - 每个节点是一个 代理（决策者）或 确定性步骤：CRUD、布尔决策
• 触发器与终止器 - 每个流程具有一个或多个定义的起始触发器和定义的结束状态
• 输入 - 每个流程必须具有输入。输入设置流程会话的上下文，并将不同流程的结果区分开来。输入可以是：自由文本、实体（GitLab 或第三方）
• 会话 - 流程的一次执行；会话携带用户特定的目标和数据

Agent（代理）

专业的、由 LLM 驱动的决策者，拥有流程内的单个节点。可独立定义并作为可重用组件在多个流程中复用。

• 提示（系统） - 设置代理的整体行为、护栏和角色
• 提示（目标） - 接收来自流程的会话特定目标
• 工具 - 仅可调用流程节点定义和用户/公司定义的可用工具所授予的工具
• 代理/流程 - 如果可用，代理可调用其他代理或流程以实现其目标
• 推理 - 使用 LLM 将其目标分解为动态子任务
• 上下文感知 - 通过工具调用获取项目/仓库/问题数据

GitLab 代理是专家而非通才，以最大化可靠性和用户体验。

Tool（工具）

代理（或流程步骤）调用的离散、确定性能力，用于执行读写操作。工具可用于在 GitLab 或通过 MCP 或其他协议在第三方应用程序中执行这些操作。

示例： 读取 GitLab 问题、克隆仓库、提交并推送更改、调用 REST API。 工具暴露数据或副作用；它们本身不执行推理。

流程类型

当前实现

• Sequence（序列） - 流程执行代理，按预设方式将输出传递给下一个代理

未来实现

• Single Agent（单代理） - 单个代理执行整个流程直至完成，适合具有延迟考虑的小型定义任务
• Multi Agent（多代理） - 代理池以每个代理有机会解决问题和/或主管选择最终解决方案的方式协作完成任务。可支持不同的图拓扑结构

支持术语

术语	定义
Node (Flow node)（节点）	流程图中的单个步骤。GitLab 目前支持 Agent、Tool Executor、Agent Handover、Supervisor 和 Terminator 节点。
Run（运行）	具有具体用户输入和数据上下文的流程实例。
Task（任务）	表示运行内工作单元的正式对象。目前仅 Executor 代理保留任务，但该概念可扩展。
Trigger（触发器）	启动流程运行的事件（例如，斜杠命令、计划、问题标签）。
Agent Handover（代理交接）	将一个代理的上下文打包传递给另一个代理的节点类型。
Supervisor Agent（主管代理）	监控其他代理进度并强制执行运行级别约束（超时、最大令牌数等）的代理节点。
Subagent（子代理）**	在同一运行内由主管代理操作的代理的简写。
Autonomous Agent（自主代理）	历史术语，指无需人工批准即可循环的代理。在 GitLab 中，自主级别由流程设计而非独立代理类型控制。
Framework（框架）	构建多代理系统的平台。GitLab Duo Agent Platform 使用 LangGraph，这是 LangChain 的原生建模代理图的扩展。

执行方式

流程通过以下方式执行：

• Local（本地） - 在项目或文件夹（未来）上下文中执行流程
• Remote（远程） - 在与项目、组（未来）、命名空间（未来）相关的 CI Runner 中执行流程

快速参考矩阵

层级	人类类比	回答的关键问题
Tool（工具）	能力	“我能执行什么具体操作？”
Agent（代理）	技能/专家	“我如何使用工具达成目标？”
Flow（流程）	能力/工作	“何时及按何种顺序应用技能以交付价值？”

AI 上下文术语

Advanced Context Resolver（高级上下文解析器）

高级上下文是超越单个文件的全面代码相关信息，包括打开的文件标签、导入、依赖项、跨文件符号和定义，以及项目范围相关的代码片段。

高级上下文 解析器 是设计用于收集上述高级上下文的系统。通过提供高级上下文，解析器为 LLM 提供对项目结构的更全面理解，从而实现更准确和上下文感知的代码建议和生成。

AI Context Abstraction Layer（AI 上下文抽象层）

一个 Ruby gem，为 GitLab 内部多个向量数据库的检索增强生成（RAG）提供统一接口。该系统抽象了 Elasticsearch、OpenSearch 和 PostgreSQL with pgvector 之间的差异，使 AI 功能能独立于底层存储解决方案运行。

关键组件包括定义数据模式的集合、处理序列化的引用类、用于模式管理的迁移以及用于分块和嵌入生成的预处理器。该层支持在不同 LLM 之间自动迁移模型而无需停机，通过基于 Redis 的队列进行异步处理，以及具有自动脱敏的权限感知搜索。

此 架构 防止供应商锁定，并使没有 Elasticsearch 的 GitLab 客户户可通过 pgvector 访问 RAG 功能。

AI Context Policies（AI 上下文策略）

用户定义和用户管理的机制，允许精确控制可作为上下文信息发送给 LLM 的内容。 GitLab 有一份 架构文档，提出了 AI 上下文策略的格式。

Codebase as Chat Context（代码库作为聊天上下文）

指用户使用 /include 命令明确提供的仓库。用户可通过选择仓库内的目录缩小范围。 此功能允许用户询问整个仓库或通过选择特定目录询问仓库子集的问题。 此功能通过在包含仓库的 代码嵌入 上执行用户问题的语义搜索自动增强，然后将搜索结果添加到发送给 LLM 的上下文中。这为 LLM 提供了与用户问题特定相关的包含仓库或目录信息，使 LLM 能生成更有帮助的响应。 此 架构文档 提出了通过在代码嵌入上进行语义搜索增强的代码库作为聊天上下文。 未来，仓库或目录上下文也可能通过 知识图谱 搜索增强。

Code Embeddings（代码嵌入）

代码嵌入计划 旨在构建仓库中文件的向量嵌入表示。文件内容被分块为逻辑片段，然后为分块内容生成嵌入并存储在向量存储中。 通过代码嵌入，我们可以对给定仓库执行语义搜索，然后将搜索结果用作 LLM 的额外上下文。 （有关代码嵌入如何在 Duo Chat 中使用，请参阅 代码库作为聊天上下文）。

GitLab Zoekt

可扩展的精确代码搜索服务和基于文件的数据库系统，具有灵活的架构，支持传统搜索之外的多种 AI 上下文用例。它建立在开源代码搜索引擎 Zoekt 之上。 该系统由统一的 gitlab-zoekt 二进制文件组成，可在索引器和 Web 服务器模式下运行，管理持久存储上的索引文件以实现快速搜索。关键功能包括与 GitLab 的双向通信和自注册节点 架构 以便于扩展。 该系统旨在处理企业级部署，GitLab.com 已成功运营超过 48 TiB 的索引数据。 最有可能的是，此分布式数据库系统将用于支持 知识图谱。此外，我们可能会利用精确代码搜索为 GitLab Duo 提供额外上下文和/或工具。

Knowledge Graph（知识图谱）

知识图谱 项目旨在从代码仓库创建结构化、可查询的图数据库，以支持 GitLab 中的 AI 功能并提高开发人员生产力。 可以想象它像创建一个详细的蓝图，显示哪些函数调用其他函数、类如何相互关联，以及变量在整个代码库中的使用位置。与其让 GitLab Duo 每次提问时都阅读数千个文件，它可以快速导航这个预构建的地图，为您提供更好的代码建议、查找相关代码片段或帮助调试问题。它为 Duo 提供了一种更智能的方式来理解您的代码库，以便在代码审查、重构或您正在开发功能时确定更改位置等方面更有效地协助您。

One Parser (GitLab Code Parser)（单一解析器 (GitLab 代码解析器)）

GitLab 代码解析器 建立单一、高效且可靠的静态代码分析库。该库将作为 GitLab 多样化代码智能功能的基础，从服务器端索引（知识图谱、嵌入）到客户端分析（语言服务器、Web IDE）。初始范围限定为 AI 和编辑器功能。

Supplementary User Context（补充用户上下文）

用户从其本地环境提供的额外信息，例如 IDE 中的打开标签、文件和文件夹，以扩展默认 AI 上下文。这在内部有时称为“固定上下文”。GitLab Duo Chat 用户可通过 /include 命令（仅限 IDE）提供补充用户上下文。