Yuriy Gavrilov: posts tagged MCP

Cline и Continue: два подхода к AI-ассистенту в VS Code

Sun, 11 Oct 2026 20:16:12 +0300

За последние два года AI-ассистенты для программирования перестали быть экзотикой и превратились в рабочий инструмент миллионов разработчиков. Однако выбрать подходящий — задача нетривиальная. Cline и Continue — два самых популярных open-source решения для VS Code, и хотя оба ставят перед собой схожую цель, подходы у них принципиально разные.

Эта статья поможет разобраться, чем они отличаются, как настроить каждый из них и когда какой инструмент стоит использовать.

Cline: автономный агент

Cline — это автономный кодинг-агент, который живёт прямо в вашей IDE. Вы описываете задачу, а он читает файлы, вносит правки, запускает команды в терминале и повторяет цикл, пока задача не будет выполнена. Это ближайший open-source аналог Claude Code по стилю работы: агент владеет циклом выполнения, человек проверяет diff’ы.

Ключевые особенности:

Чтение и запись файлов — навигация по кодовой базе, создание файлов и точечные правки. Каждое изменение показывается в виде diff’а перед применением.
Выполнение команд — запуск shell-команд, тестов, установка пакетов и мониторинг вывода в реальном времени.
Браузер — headless-браузер для тестирования веб-приложений, скриншотов и отладки ошибок.
MCP-серверы — расширение возможностей через подключение внешних инструментов: баз данных, API, документации.
Любая модель — Claude, GPT-4, Gemini, DeepSeek, локальные Ollama или любой OpenAI-совместимый endpoint.

Каждое действие требует вашего подтверждения — это zero-trust архитектура, при которой код не покидает вашу машину. Cline распространяется под лицензией Apache 2.0 и недавно преодолел отметку в 5 миллионов установок.

Continue: ассистент, который остаётся в потоке

Continue — это open-source AI-ассистент, построенный вокруг чата, inline-правок и автодополнения. Здесь человек остаётся за рулём: модель помогает, но не берёт управление на себя.

Ключевые особенности:

Автодополнение кода — inline-подсказки прямо в редакторе, работающие на низкой задержке.
Чат и inline-редактирование — общение с моделью в боковой панели и правки прямо в файле.
Контекстные провайдеры — `@codebase`, `@file`, `@terminal` для запросов с учётом кода проекта.
Slash-команды — кастомные команды для типовых задач: ревью кода, генерация тестов, рефакторинг.
Гибкая конфигурация — всё управляется через единый `config.yaml`.

Continue — это middleware между редактором и LLM: расширение не поставляет собственную модель, а маршрутизирует запросы к тому провайдеру, который вы укажете. Проект поддерживает VS Code, JetBrains и Neovim, а его кодовая база остаётся открытой.

Сравнение: что выбрать

Характеристика	Cline	Continue
Философия	Автономный агент — модель владеет циклом	Ассистент — человек владеет циклом
Лицензия	Apache 2.0	Open source
Автодополнение	Нет	Да (inline-подсказки)
Агентный режим	Plan/Act с подтверждением каждого шага	Есть, но вторичен
MCP	Полная поддержка	Полная поддержка
Конфигурация	`cline_mcp_settings.json` (JSON)	`config.yaml` (YAML)
Установок	5M+	Данные не раскрыты

Если коротко: Cline лучше подходит для крупных механических задач — массовых рефакторингов, скаффолдинга, повторяющихся правок. Continue — для быстрой помощи в потоке, когда вы не хотите, чтобы модель «убегала вперёд».

Большинство разработчиков используют оба инструмента, переключаясь в зависимости от задачи.

Стоит упомянуть и о третьем игроке — Hermes. Это open-source AI-агент, который работает по протоколу Agent Client Protocol (ACP) и может быть подключён к VS Code, Zed или JetBrains через отдельное расширение ACP Client. Hermes CLI запускается как локальный подпроцесс, без облачного прокси, а расширение для VS Code стримит чат, выполняет инструменты и управляет сессиями. Главное отличие Hermes от Cline и Continue в том, что это не самостоятельное расширение с собственным интерфейсом, а агентный рантайм, который подключается к IDE через стандартизированный протокол. Подробнее о нём — в отдельной статье.

Установка и базовая настройка

Cline

Установка:

Откройте VS Code и перейдите в Extensions (`Ctrl/Cmd + Shift + X`).
Введите в поиске Cline.
Установите расширение от `saoudrizwan` (ID: `saoudrizwan.claude-dev`).
После установки нажмите на иконку Cline в Activity Bar. Если её не видно, перезапустите VS Code полностью.

Подключение провайдера:

Откройте настройки Cline и выберите провайдера. Можно использовать Cline Provider (pay-as-you-go), ClinePass (подписка) или подключить собственный API-ключ от Anthropic, OpenAI, OpenRouter или любого OpenAI-совместимого сервиса.

Continue

Установка:

Откройте Extensions (`Ctrl/Cmd + Shift + X`).
Найдите Continue и установите расширение от `Continue.dev`.

Настройка:

При первом запуске Continue предложит мастер настройки. Конфигурация хранится в файле `~/.continue/config.yaml` (macOS/Linux) или `%USERPROFILE%\.continue\config.yaml` (Windows). Открыть его можно из панели Continue: нажмите на иконку шестерёнки рядом с выпадающим списком моделей.

Если у вас остался старый `config.json`, его можно мигрировать в YAML — при наличии `config.yaml` расширение загрузит именно его.

Настройка кастомной модели в Continue

Одно из главных преимуществ Continue — возможность подключить любую модель через OpenAI-совместимый API. Вот пример конфигурации для подключения модели через прокси-сервис:

name: My Config
version: 1.0.0
schema: v1

models:
  - name: GLM 5.3 Flash via Proxy
    provider: openai
    model: z-ai/glm-5.3-flash
    apiBase: https://your-proxy-host.example.com/v1
    apiKey: ${{ secrets.PROXY_API_KEY }}
    roles:
      - chat
      - edit
      - apply
    defaultCompletionOptions:
      temperature: 0.7
      maxTokens: 4096
    capabilities:
      - tool_use

Ключевые моменты:

`apiBase` должен заканчиваться на `/v1` — Continue автоматически добавит `/chat/completions`.
`apiKey: ${{ secrets.PROXY_API_KEY }}` — ссылка на переменную из файла `.env`, который должен лежать рядом с `config.yaml`. Никогда не вписывайте ключ напрямую в конфиг.
`capabilities: [tool_use]` — явно включает поддержку вызова инструментов, необходимую для работы Agent mode. Без этого кнопки Plan и Act будут неактивны.

Настройка MCP-серверов

MCP (Model Context Protocol) — это стандарт, позволяющий подключать к агенту внешние инструменты: базы данных, API, системы управления задачами. Оба инструмента поддерживают MCP, но конфигурируются по-разному.

Cline

Файл конфигурации: `cline_mcp_settings.json`. Открыть его можно через панель Cline: нажмите на иконку MCP Servers, перейдите на вкладку Configure и нажмите Configure MCP Servers.

Пример подключения локального MCP-сервера:

{
  "mcpServers": {
    "trino": {
      "command": "mcp-trino",
      "args": [],
      "env": {
        "TRINO_HOST": "192.168.3.81",
        "TRINO_PORT": "8080",
        "TRINO_USER": "trino",
        "TRINO_PASSWORD": "",
        "TRINO_CATALOG": "tpcds",
        "TRINO_SCHEMA": "sf10",
        "TRINO_SSL": "false",
        "TRINO_SCHEME": "http"
      },
      "disabled": false,
      "alwaysAllow": []
    }
  }
}

Для удалённых серверов используйте `“type”: “streamableHttp”` и поле `“url”`.

Continue

MCP-серверы добавляются в тот же `config.yaml`, где настраиваются модели, либо в отдельные файлы в папке `.continue/mcpServers/`.

Пример:

mcpServers:
  - name: Trino
    command: mcp-trino
    env:
      TRINO_HOST: "192.168.3.81"
      TRINO_PORT: "8080"
      TRINO_USER: "trino"
      TRINO_PASSWORD: ""
      TRINO_CATALOG: "tpcds"
      TRINO_SCHEMA: "sf10"
      TRINO_SSL: "false"
      TRINO_SCHEME: "http"

После сохранения конфигурации полностью перезапустите VS Code — оба расширения подхватывают MCP-серверы только при старте.

MCP-серверы для Trino: что выбрать

Trino — это распределённый SQL-движок для аналитических запросов к большим данным. Подключение MCP-сервера для Trino даёт AI-агенту возможность исследовать каталоги, выполнять запросы и анализировать планы выполнения прямо из чата. Для Trino существует несколько MCP-серверов, которые можно разделить на две категории: легковесные Python-серверы и высокопроизводительные Go-серверы.

Python-серверы (быстрый старт)

`trino-mcp` — самый функциональный и простой в настройке Python-сервер, который хорошо подходит для большинства задач. Поддерживает OAuth2 и Basic Auth, по умолчанию разрешает только `SELECT`-запросы (для записи нужно явно установить `ALLOW_WRITE_QUERIES=true`), автоматически добавляет комментарии в запросы с именем пользователя для аудита, а также умеет экспортировать результаты в JSON или CSV.

Установка через `uvx`:

uvx trino-mcp

Пример конфигурации для Continue:

mcpServers:
  - name: Trino
    command: uvx
    args:
      - "trino-mcp"
    env:
      TRINO_HOST: "your-trino-host"
      TRINO_PORT: "8080"
      TRINO_USER: "your-user"

`alaturqua/mcp-trino-python` — сервер, ориентированный на работу с Trino и Iceberg. Предоставляет расширенные возможности для исследования данных и обслуживания таблиц Iceberg, поддерживает три режима транспорта (`stdio`, `streamable-http`, `sse`) и имеет готовый `Dockerfile` для быстрого развёртывания.

Go-серверы (для продакшена)

`txn2/mcp-trino` — это, пожалуй, самый мощный и функциональный MCP-сервер для Trino. Он даёт AI-ассистентам безопасный, структурированный доступ к Trino и любым Trino-совместимым движкам. По умолчанию работает в режиме только для чтения, поддерживает ограничения на количество строк и таймауты запросов, а также имеет опциональный семантический слой для отображения бизнес-описаний, владельцев и маркеров чувствительности данных из DataHub или других каталогов метаданных.

Ключевые особенности:

Выполнение SQL-запросов — `SELECT`, `SHOW`, `DESCRIBE` с настраиваемыми лимитами и таймаутами.
Анализ планов выполнения — логические, распределённые и I/O-планы запросов.
Просмотр схем — навигация по каталогам, схемам и таблицам.
Описание таблиц — определения колонок с опциональными примерами данных.
Мультикластерность — запросы к нескольким серверам Trino из одной установки через `TRINO_ADDITIONAL_CONNECTIONS`.
Библиотека для Go — можно импортировать как Go-пакет и собрать собственный MCP-сервер с кастомной аутентификацией и аудитом.

Установка через Homebrew:

brew install txn2/tap/mcp-trino

Пример конфигурации для Cline:

{
  "mcpServers": {
    "trino": {
      "command": "mcp-trino",
      "args": [],
      "env": {
        "TRINO_HOST": "your-trino-host",
        "TRINO_PORT": "8080",
        "TRINO_USER": "trino",
        "TRINO_PASSWORD": "",
        "TRINO_CATALOG": "hive",
        "TRINO_SCHEMA": "default",
        "TRINO_SSL": "false",
        "TRINO_SCHEME": "http"
      },
      "disabled": false,
      "alwaysAllow": []
    }
  }
}

Пример конфигурации для Continue:

mcpServers:
  - name: Trino
    command: mcp-trino
    env:
      TRINO_HOST: "your-trino-host"
      TRINO_PORT: "8080"
      TRINO_USER: "trino"
      TRINO_PASSWORD: ""
      TRINO_CATALOG: "hive"
      TRINO_SCHEMA: "default"
      TRINO_SSL: "false"
      TRINO_SCHEME: "http"

Важные параметры `mcp-trino`:

Подключение: обязательные переменные — `TRINO_HOST`, `TRINO_USER`. Порт по умолчанию: `8080` для HTTP или `443` для HTTPS.
Режим только для чтения: включён по умолчанию. Для записи установите `TRINO_ALLOW_WRITE=true`.
SSL: если Trino работает по HTTP, обязательно установите `TRINO_SSL: “false”` и `TRINO_SCHEME: “http”`, иначе сервер попытается использовать HTTPS и выдаст ошибку `invalid URL escape “%2F”`.

Что выбрать?

Для быстрого старта: начните с `trino-mcp` (Python). Он легко устанавливается через `uvx` и имеет безопасные настройки по умолчанию.
Для работы с Iceberg: обратите внимание на `alaturqua/mcp-trino-python`, если ваша основная задача — исследование и обслуживание таблиц Iceberg.
Для продакшена: выбирайте `txn2/mcp-trino` (Go), если нужна высокая производительность, поддержка нескольких кластеров и возможность встраивания в собственные приложения.

Типичные проблемы и их решения

Модель не появляется в Continue после добавления в конфиг.
Проверьте, что файл `.env` существует и лежит в той же папке, что `config.yaml`. Имя переменной в `.env` должно точно совпадать с именем в `${{ secrets.ИМЯ }}`.

Кнопки Plan и Act неактивны.
Добавьте `capabilities: [tool_use]` в блок модели. Без этой способности Continue блокирует агентные режимы.

Ошибка `401 status code (no body)`.
Ключ API не распознан. Проверьте, что `apiBase` заканчивается на `/v1`, ключ действителен и имеет положительный баланс.

MCP-сервер не подключается с ошибкой `invalid URL escape “%2F”`.
Сервер пытается использовать HTTPS, хотя Trino работает по HTTP. Добавьте `TRINO_SSL: “false”` и `TRINO_SCHEME: “http”` в переменные окружения MCP-сервера.

Модель зависает после долгих раздумий в Agent mode.
Скорее всего, прокси-сервис не передаёт `tool_calls` в потоковом режиме. Проверьте это через `curl` с `“stream”: true` и имитацией вызова инструмента. Если `tool_calls` в потоке нет — попробуйте отключить стриминг через `config.json` или использовать модель с нативной поддержкой function calling.

Заключение

Cline и Continue решают разные задачи, и это их главное достоинство. Cline — это автономный агент, которому можно делегировать крупные задачи и вернуться к готовому результату. Continue — это ассистент, который помогает здесь и сейчас, не забирая контроль.

Оба инструмента бесплатны, оба поддерживают MCP и работают с любой моделью. С помощью MCP-серверов, таких как `txn2/mcp-trino`, вы можете подключить к агенту Trino и работать с данными прямо из чата — без переключения между окнами и ручного написания запросов.

Начните с того инструмента, который ближе к вашему стилю работы, — а когда освоитесь, попробуйте второй. Большинство разработчиков в итоге используют оба.

Действительно ли данные готовы к ИИ

Sat, 14 Mar 2026 00:19:28 +0300

Автор: Джейкоб Мэтсон

https://motherduck.com/blog/bird-bench-and-data-models

Несколько месяцев назад я писал о том, почему нам может не понадобиться семантический слой. Аргумент заключался в том, что ИИ может обнаруживать бизнес-логику из истории запросов, вместо того чтобы заставлять людей заранее определять каждую метрику. Я верил в это. Но у меня не было данных, чтобы это доказать.

Теперь они у меня есть.

Все началось с вопроса одного из наших инвесторов: *“Как различные модели справляются с BIRD при использовании MotherDuck MCP?”* Поэтому я провел эксперимент. Три передовые LLM модели (`Claude Opus 4.5`, `GPT-5.2` и `Gemini 3 Flash`), каждая из которых подключена к базе данных через сервер `MotherDuck MCP`, были запущены на наборе данных `BIRD Mini-Dev`.

Пояснение:

MCP (Model Context Protocol):** Стандарт, позволяющий ИИ-моделям безопасно и стандартизировано подключаться к внешним источникам данных и инструментам.

BIRD (BIg Bench for Large-scale Database Grounded Text-to-SQL):** Популярный и сложный бенчмарк (набор тестов) для оценки того, насколько хорошо нейросети умеют переводить естественный язык в SQL-запросы.

Mini-Dev:** Это официальная выборка из 500 вопросов для разработки из бенчмарка BIRD. Она охватывает 11 баз данных в сферах финансов, спорта, образования и здравоохранения.

Модели данных здесь простые. В среднем 7 таблиц на базу данных. Ни в одной нет больше 13 таблиц. Объединения (joins) в основном «один-ко-многим», максимальная глубина — два или три перехода, ноль отношений «многие-ко-многим». Это тот тип схемы, который можно понять за пять минут, прочитав `DDL`.

Пояснение: `DDL` (Data Definition Language) — это часть SQL, используемая для описания структуры базы данных (создание таблиц, колонок, связей).

Результат? 95% точности. Никакого семантического слоя. Никакой истории запросов. Никакого специального контекста. Только схема базы данных.

Но это число требует «звездочки» (примечания), и, честно говоря, эта звездочка — самая интересная часть.

Что на самом деле означают 95%

Вот что я измерял на самом деле.

Бенчмарк BIRD оценивает точность, используя Execution Accuracy (EX): запускается предсказанный SQL и «золотой» (эталонный) SQL, сравниваются наборы результатов, и ставится бинарная оценка «сдал/не сдал». При этих строгих правилах текущий уровень развития технологий (SOTA) составляет около 76. Мои модели набрали 64 на тренировочной выборке и 58 на тестовой.

Звучит плохо. Но у строгой оценки BIRD есть хорошо задокументированная проблема. В статье 2025 года, представляющей метрику `FLEX`, было обнаружено, что точность выполнения (execution accuracy) BIRD совпадает с оценками экспертов-людей только в 62% случаев. Почти 4 из 10 суждений ошибочны, в основном это ложноотрицательные результаты, когда бенчмарк отвергает ответы, которые люди бы приняли.

Эти 62 бросились мне в глаза, потому что они почти точно совпадают с моей смешанной точностью при строгой оценке в 60.5 (64 обучение / 58 тест). То же наблюдение, но с другой стороны. Метрика `FLEX` пришла к этому с помощью проверяющих людей. Я пришел к этому, ослабив условия тестирования.

Подумайте, что это значит для таблицы лидеров. Если бенчмарк согласен с людьми только в 62 случаев, то чтобы набрать выше 62 по строгим правилам, вы должны начать воспроизводить ошибки бенчмарка. Вы перестаете учиться писать правильный SQL. Вы начинаете учиться соответствовать специфической, иногда ошибочной интерпретации каждого вопроса в BIRD. Системы с рейтингом 76 закрепили эти ошибки суждения в своем обучении. Они получают более высокие баллы, становясь *хуже* в выполнении реальной задачи.

Поэтому я построил более реалистичную оценку. Я разделил 500 вопросов на тренировочный набор (151 вопрос) и тестовый набор (349 вопросов).

Я использовал тренировочный набор (train) для калибровки оценки: вручную пересматривал ошибки, создавал исправленные «платиновые» ответы там, где «золотой» SQL BIRD был ошибочным, и настраивал правила частичного совпадения. Тестовый набор (test) был контрольным.

Вот как выглядит точность, если смягчать критерии оценки уровень за уровнем:

Уровень оценки (Scoring Tier)	Train	Test	Что добавляется
Только совпадение с Gold (≈ офиц. BIRD)	64.0	58.2	Строгое равенство наборов результатов
+ Платиновые ответы	73.1	58.5	Исправляет известные ошибки в «золотом» SQL BIRD (см. примечание ниже)
+ Допуск форматирования	78.8	65.5	Различия в `DISTINCT`, лишние колонки, округление
+ Судья LLM	94.9	94.4	“Принял бы человек этот ответ?”

Примечание: «Платиновые» исправления существуют только для тренировочного набора, так как я вручную проверил эти 151 вопрос. Вот почему уровень «Платина» почти не меняется на тесте +0.3 pp против +9.1 pp на тренировке). Но посмотрите на уровень с судьей: 94.9 на тренировке и 94.4 на тесте. Разница всего в половину процентного пункта. Оценка держится на контрольной выборке даже без моих исправлений вручную.

Результаты тренировочной выборки (151 вопрос, все 3 модели):

Модель	STRICT (≈ BIRD EX)	REALISTIC	Общая стоимость	Вызовы инструментов (P5 / Median / P95)
`Gemini 3 Flash`	68.2	94.0	1.80	3 / 6 / 9
`Claude Opus 4.5`	64.9	95.4	26.37	4 / 6 / 9
`GPT-5.2`	58.9	95.4	6.87	4 / 7 / 12

Результаты тестовой выборки (349 вопросов, 2 модели):

Модель	STRICT (≈ BIRD EX)	REALISTIC	Общая стоимость	Вызовы инструментов (P5 / Median / P95)
`Gemini 3 Flash`	60.7	94.6	3.96	4 / 6 / 9
`GPT-5.2`	55.6	94.3	15.32	4 / 7 / 11

*Примечание: `Claude Opus` не запускался на тестовом наборе. После того как все три модели сошлись на ~95% на тренировке, тратить еще 60+, чтобы доказать то же самое на 349 вопросах, показалось нецелесообразным.*

Медианная модель делает 6-7 вызовов инструментов MCP на вопрос при лимите в 10 итераций. Типичный вопрос выглядит так: изучить схему, просмотреть некоторые колонки, набросать запрос, проверить результаты, уточнить, готово. Некоторые модели, такие как `GPT-5.2`, делают несколько вызовов инструментов за итерацию, поэтому его показатель P95, равный 12, превышает лимит итераций.

Все три модели достигают 94-95% при реалистичной оценке, независимо от того, где они начинают при строгой оценке. На тренировочной выборке разрыв между «лучшим» и «худшим» сокращается с 12.6 процентных пунктов до 1.4. На тесте — с 5.1 до 0.3. Берите любую передовую модель.

Бенчмарк иногда ошибается

BIRD — хороший бенчмарк. Но в нем есть баги. Только в тренировочном наборе (151 вопрос) я нашел 49 случаев, где «золотой» SQL явно неверен. Я не проверял вручную тестовый набор, поэтому реальное число для всех 500 вопросов, вероятно, выше.

Вот пример, который мне запомнился. Вопрос просит список школ, чей совокупный балл превышает 1500. «Золотой» SQL проверяет `count` (количество) студентов, набравших более 1500 баллов. Совершенно другой запрос, совершенно другой ответ. Вы читаете вопрос, читаете «правильный» ответ и думаете: подождите, но спрашивали-то не об этом.

Я создал исправленные «платиновые» ответы для этих случаев. В среднем около 14 из 151 вопроса тренировочной выборки для каждой модели совпали с платиновым ответом вместо золотого, добавив 9.1 процентных пунктов.

Людей не волнует форматирование

На тренировочной выборке еще +5.7 pp получается за счет принятия результатов, которые верны по существу, но не проходят проверку на строгое равенство:

Лишние колонки (30 случаев): Модель вернула запрошенные данные плюс дополнительный контекст. Человек сказал бы «спасибо, это полезно». Бенчмарк говорит «провал».
Несовпадения `DISTINCT` (41 случай): Модель использовала `SELECT DISTINCT`, когда в золотом ответе этого не было, или наоборот. Уникальные значения совпадают идеально. Человек бы даже не заметил.
Различия в округлении (3 случая): Золотой ответ 24.67, ответ модели 24.6667. То же число, разная точность.

Ни один из этих ответов не является неверным. Это различия в форматировании, которые важны только для функции сравнения строк.

Человек (LLM)-в-петле (The LLM-in-the-Loop)

Оставшийся разрыв (16 pp на тренировке, 29 pp на тесте) закрывается судьей LLM. Я использовал `Gemini 3 Flash` для проверки каждого «проваленного» ответа с вопросом: *действительно ли этот SQL отвечает на вопрос?*

На тестовой выборке судья выполняет больше тяжелой работы, потому что там нет «платиновых» исправлений для предварительного отлова багов бенчмарка. Что именно он спасал?

Причина	Кол-во	Что произошло
Больше отфильтровано (Missing rows)	57	Модель отфильтровала строже, чем золотой стандарт, но это обоснованно.
Лишние строки (Extra rows)	33	Модель интерпретировала вопрос более широко.
Близкие значения (Values close)	19	Числовые результаты в пределах допуска.
Пустой результат	14	Модель ничего не вернула, но логика была верной (данных нет).
Пропущенные колонки	11	Возвращено меньше колонок, но ответ на вопрос дан.

Это оценочные суждения. Должен ли запрос «перечислите все школы в районе» включать чартерные школы? Разумные люди могут не согласиться. Строгий бенчмарк выбирает одну интерпретацию и наказывает за все остальные. Судья просто спрашивает, можно ли обосновать интерпретацию модели.

Если вы создаете ИИ-аналитику, это важно. Никто не выпускает продукт text-to-SQL, где пользователь видит сырые результаты без этапа проверки. Всегда есть человек или LLM, проверяющий выходные данные. Эти 94-95% отражают то, как эти продукты работают на самом деле. 58-64% отражают то, как работают бенчмарки.

А как насчет контекста?

Вы могли бы ожидать, что дополнительный контекст поможет. Комментарии к колонкам, описания, подсказки о значении данных. Это интуиция, лежащая в основе семантических слоев и механизмов контекста.

Я протестировал это. Те же 500 вопросов, все модели, с комментариями к колонкам каждой таблицы и без них.

Схема	Train	Test
Без комментариев	94.9	94.4
С комментариями	96.0	94.6
Дельта	1.1 pp	0.2 pp

Один процентный пункт на тренировке, почти ничего на тесте. В большинстве вопросов правильность не изменилась.

Если разбить по базам данных, становится интересно. Чем сложнее схема, тем больше помогают комментарии (усредненно по train и test):

База данных	Базовая точность	Эффект комментариев
`debit_card_specializing`	85.5 (самая сложная)	8.7 pp
`european_football_2`	93.2	3.4 pp
`california_schools`	95.7 (самая легкая)	2.9 pp

Комментарии помогают, когда схема действительно запутанная. Таблица `debit_card_specializing` (попробуйте угадать, как выглядит эта схема) получила самый большой прирост. Но схемы с интуитивными названиями и очевидными связями? Там комментарии сделали только хуже. У моделей уже сформировалась правильная ментальная модель, а комментарии внесли шум.

Каждый разработчик знает это о комментариях в коде. Полезны при реальной неоднозначности. Вредны, когда констатируют очевидное. `// увеличить i на 1` еще никому не помогло.

Почему простые модели данных работают

Базы данных BIRD — это не корпоративные хранилища данных. Они простые:

7 таблиц в среднем.
9 внешних ключей в среднем, в основном «один-ко-многим».
Ноль связей «многие-ко-многим».
Глубина join макс. 2-3 перехода, нет глубоких иерархий.

LLM читают эти схемы так же, как опытный аналитик читает DDL. Они видят таблицу `schools` с колонками `school_name`, `district` и `enrollment`, и они знают, что делать. Внешний ключ от `schools` к `scores`? Они знают, как их соединить (join). Никому не нужен семантический слой, чтобы объяснить, что “enrollment” означает «количество студентов».

Хорошее моделирование данных — это и есть семантический слой. Когда ваши таблицы названы хорошо, а объединения прямолинейны, у LLM есть всё необходимое.

Во что я бы инвестировал в первую очередь

Каждая среда уникальна, но вот как бы я расставил приоритеты, основываясь на том, что увидел:

Начните с модели данных. Чистые таблицы, понятные названия, простые объединения. Если опытный аналитик может посмотреть на вашу схему и понять ее за несколько минут, то и LLM сможет.
Затем добавьте целевой контекст. Комментарии к колонкам и метаданные, но только там, где действительно существует путаница. Документируйте таблицы типа `debit_card_specializing`, а не `schools`.
История запросов идет следом. Она становится важнее по мере усложнения предметной области, особенно для обнаружения недокументированных бизнес-правил (вроде “abnormal GOT > 60”). Базы данных BIRD имеют простые правила. Но я работаю над (проектом) `DABstep`, у которого простая модель данных, но очень сложные правила предметной области. Тот вид знаний, который живет в головах людей, а не в названиях колонок. Там история запросов и подобранный контекст будут значить гораздо больше. Но даже тогда чистая модель данных стоит на первом месте.

Наконец, не беспокойтесь о формальном семантическом слое. Если ваша модель данных чиста, а контекст целенаправлен, это почти ничего не добавляет для сценариев использования ИИ. На самом деле, кажется, что это даже мешает, так как ИИ отлично пишет SQL, но менее хорош в работе с другими инструментами.

Начните сейчас

Планка для «данных, готовых к ИИ», ниже, чем вам говорит индустрия.

Вам не нужен “движок контекста”, семантический слой, годы истории запросов или специализированная платформа метаданных. Вам нужна чистая модель данных и LLM. Найдите домен, который готов к этому, и начните там.

Разрыв между «точностью бенчмарка» и «примет ли это человек?» составил 31 pp на тренировочной выборке и 36 pp на тестовой. Это огромный разрыв, и он закрывается в тот момент, когда вы включаете человека или LLM в цикл проверки. Именно так и работает любой продукт ИИ-аналитики.

Если ваша модель данных чиста, начните сегодня. Направьте LLM на вашу схему и задавайте вопросы. Если ваша модель данных не чиста, теперь вы знаете, с чего начать.

***

Итоги статьи

Проблема: Принято считать, что для работы ИИ с базами данных (Text-to-SQL) нужны сложные семантические слои, история запросов и контекст.
Эксперимент: Автор протестировал работу современных LLM (Claude, Gemini, GPT) на известном наборе данных BIRD.
Открытие 1: Формальные бенчмарки занижают качество работы ИИ. Они требуют строгого совпадения SQL-запросов, хотя люди принимают ответы с правильными данными, но другим форматированием (лишние колонки, другой порядок сортировки). Истинная (“реалистичная”) точность моделей достигает 95%, тогда как бенчмарк показывает около 60%.
Открытие 2: “Готовность данных к ИИ” сводится к понятной структуре базы данных. Чистые таблицы, внятные названия колонок и простые связи работают лучше, чем нагромождение комментариев.
Открытие 3: Дополнительные комментарии (контекст) нужны только для реально запутанных схем. В простых случаях они даже мешают, создавая шум.
Вывод: Не тратьте ресурсы на сложные семантические надстройки. Инвестируйте в чистоту модели данных (понятные имена таблиц и полей). Хорошая модель данных — это и есть лучший семантический слой для ИИ.