Capella iQ - это AI-ассистент, встроенный в облачную базу данных Couchbase Capella. Он превращает вопросы на естественном языке в готовые SQL++ запросы, помогает проектировать схему данных и ведёт многошаговые диалоги. Ключевое архитектурное решение: ассистент построен как мультимодельная система на Amazon Bedrock с использованием моделей Anthropic Claude (Haiku, Sonnet, Opus) и кросс-региональным инференсом. Точность генерации SQL++ по методологии BIRD достигла 76%. Это не эксперимент, а продакшен-система с провайдер-агностическим слоем, маршрутизацией запросов и планами на Custom Model Import.
Мультимодельный подход означает, что за разными этапами обработки закреплены разные модели. Лёгкая и быстрая Claude Haiku обрабатывает простые диалоговые реплики, Claude Sonnet берёт на себя генерацию кода средней сложности, а Claude Opus подключается для сложных многотабличных JOIN и неоднозначных формулировок. Такой ансамбль решает три задачи: снижает задержку для типовых запросов, повышает точность на сложных кейсах и оптимизирует затраты на инференс.
В этом разборе - детали архитектуры, которые команда Couchbase раскрыла в технических публикациях: как устроен маршрутизатор запросов, почему кросс-региональный инференс критичен для SaaS-продукта, как работает диалоговый менеджер и какие уроки можно применить в собственных AI-проектах.
Почему Couchbase выбрала мультимодельный подход для Capella iQ
Изначально Capella iQ тестировали на одной модели. Результаты показали системную проблему: универсальная LLM не справлялась одновременно с генерацией точного SQL++, поддержанием контекста диалога и пониманием схемы конкретной базы данных. Модель, хорошо писавшая код, проваливалась на уточняющих вопросах. Модель с сильным диалоговым навыком галлюцинировала в JOIN-ах. Жёсткое ограничение: продукт должен работать в реальном времени, а не в режиме пакетной обработки.
Couchbase рассматривала три альтернативы: файнтюнинг одной модели под все задачи, RAG с векторным поиском по документации и мультимодельный ансамбль. Файнтюнинг отпал из-за стоимости поддержки и быстрой деградации при обновлении схемы БД. RAG хорошо работает для поиска по документации, но не решает проблему точной генерации кода. Мультимодельный подход позволил разделить зоны ответственности и независимо оптимизировать каждый компонент.
От монолита к ансамблю: когда одной модели недостаточно
Конкретный пример из практики Couchbase. Пользователь спрашивает: «Покажи заказы клиентов из Берлина за последний квартал, которые не были оплачены». Одна модель должна одновременно: распознать географический фильтр по полю city, вычислить дату «последний квартал» относительно текущей, построить JOIN между таблицами customers, orders и payments, добавить условие NOT EXISTS для неоплаченных. Claude Opus на этом запросе давал 89% точности, но задержка составляла 3-4 секунды. Claude Haiku отвечала за 800 мс, но точность падала до 62%.
Мультимодельный роутер решает это так: классификатор оценивает сложность запроса по числу сущностей, наличию вложенных условий и JOIN. Если complexity score выше порога - запрос уходит на Opus. Если ниже - на Haiku. Результат: 89% точности на сложных запросах и 800 мс на простых. Пользователь не видит разницы в интерфейсе, но получает оптимальный баланс скорости и качества.
Второй сценарий - это переключение между языками. Capella iQ обслуживает пользователей, которые могут начать диалог на английском, затем перейти на немецкий, а схема БД при этом описана на японском. Модели Claude показали лучшие результаты в кросс-языковых сценариях по сравнению с альтернативами, доступными на Bedrock на момент проектирования. Это повлияло на выбор семейства Claude как основного.
Ядро архитектуры: кросс-региональный инференс и маршрутизация запросов
Архитектурно Capella iQ состоит из четырёх слоёв: API Gateway, Router, Model Selector и слой инференса на Amazon Bedrock. Запрос пользователя проходит через Gateway, где происходит аутентификация и проверка прав доступа к конкретной базе данных. Дальше в работу вступает Router - это компонент, который определяет, что делать с запросом: нужна ли генерация SQL++, это уточняющий диалог или общий вопрос по документации.
Model Selector получает от Router-а классифицированный интент и метаданные: идентификатор БД, схему таблиц, историю диалога. На основе этих данных и текущих метрик (задержка по регионам, доступные квоты, сложность запроса) выбирается конкретная модель и регион для инференса. Вызов уходит на Amazon Bedrock, ответ постобрабатывается (валидация SQL++, экранирование, форматирование) и возвращается пользователю.
Маршрутизатор запросов: как ассистент понимает, какую модель вызвать
Router в Capella iQ - это не отдельная нейросеть, а композит правил и классификатора на базе Claude Haiku. Первый этап - быстрая проверка по ключевым словам и паттернам. Если запрос содержит SELECT, FROM, WHERE - это вероятная доработка существующего SQL, а не генерация с нуля. Если запрос начинается с «почему», «как работает», «что такое» - это документационный интент.
Второй этап - классификация через Haiku. Модель получает промпт: «Определи тип запроса: SQL_GENERATION, DIALOG_CLARIFICATION, DOCS_QUESTION, SCHEMA_DESIGN. Контекст: [история диалога]. Запрос: [текст пользователя]. Ответь только типом». Haiku выполняет эту задачу за 200-300 мс, что не добавляет существенной задержки.
Для SQL_GENERATION запускается оценка сложности. Подсчитывается число упомянутых сущностей, наличие JOIN, GROUP BY, подзапросов, агрегатных функций. Если complexity score > 7 - запрос идёт на Claude Opus. От 3 до 7 - Sonnet. Меньше 3 - Haiku. Пороги подбирались эмпирически на внутреннем датасете из 10 000 реальных пользовательских запросов.
Кросс-региональный инференс на Amazon Bedrock: гарантия доступности
Capella - это SaaS-продукт с клиентами в десятках регионов. Для AI-ассистента задержка в 5 секунд означает потерю пользователя. Couchbase настроила Bedrock в трёх регионах AWS: us-east-1, eu-west-1 и ap-northeast-1. Model Selector при каждом вызове проверяет latency до каждого региона и выбирает наименьшую. Если в регионе заканчиваются квоты на вызовы модели (throttling), запрос автоматически уходит в следующий по задержке.
Мониторинг построен на метриках CloudWatch: p50, p95 и p99 задержки по каждой модели в каждом регионе, количество throttling-ошибок, процент успешных ответов. При падении доступности ниже 99.5% регион временно исключается из ротации. Это позволило держать SLA на уровне 99.9% доступности AI-функций даже в периоды пиковых нагрузок на Bedrock.
Data residency решается на уровне конфигурации: клиенты из ЕС могут ограничить инференс регионом eu-west-1. Это важно для соответствия GDPR, поскольку промпты могут содержать данные из базы (имена полей, примеры значений).
Обработка многошаговых диалогов и генерация SQL++ запросов
Диалоговый менеджер Capella iQ решает задачу, знакомую каждому, кто строил AI-ассистентов: как помнить контекст, уточнять неоднозначности и не терять нить разговора при переключении между генерацией кода и общими вопросами. Couchbase реализовала это через комбинацию скользящего окна диалога, слот-филлинга и компактного summary.
Диалоговый менеджер: как ассистент помнит контекст и уточняет детали
Контекстное окно формируется динамически. Полная история диалога не помещается в лимиты модели (даже с учётом 200K токенов Claude), поэтому применяется двухуровневая компрессия. Первый уровень: последние N сообщений сохраняются как есть. Второй уровень: все предыдущие сообщения сжимаются через суммаризацию Haiku в структурированный JSON с полями intent, entities, sql_generated, errors.
Слот-филлинг работает для параметров запроса. Если пользователь говорит «покажи продажи за прошлый месяц», система заполняет слот date_range = last_month. Если затем следует «а теперь по категории электроника», слот product_category заполняется значением electronics, а date_range сохраняется из контекста. Это позволяет строить запросы итеративно, без повторения всех параметров.
Когда система не может однозначно определить параметр, она генерирует уточняющий вопрос. Например: «В базе есть поля shipping_date и order_date. По какой дате считать прошлый месяц?» Этот вопрос формирует Claude Haiku, что дёшево и быстро. Основная модель не тратит ресурсы на уточнения.
От вопроса к SQL++: промпт-инжиниринг и валидация
Промпт для генерации SQL++ включает четыре обязательных блока. Первый - DDL всех релевантных таблиц (система выбирает таблицы, которые упоминались в диалоге или имеют семантическую близость к запросу). Второй - 3-5 few-shot примеров пар «вопрос → SQL++», релевантных к текущей схеме. Третий - правила диалекта SQL++ (отличия от стандартного SQL: работа с JSON-полями, синтаксис UNNEST, специфика индексов). Четвёртый - сам запрос пользователя и инструкция «верни только SQL без пояснений».
Постобработка проходит в три шага. Шаг 1: парсинг ответа модели, извлечение SQL-блока. Шаг 2: проверка синтаксиса через EXPLAIN (без фактического исполнения). Если EXPLAIN возвращает ошибку, запрос отправляется на повторную генерацию с сообщением об ошибке. Шаг 3: проверка на инъекции - запрещены DDL-команды (CREATE, DROP, ALTER), вызов функций с побочными эффектами, обращение к системным таблицам. Только после трёх шагов SQL++ показывается пользователю или исполняется.
Пример трансформации. Вопрос: «Клиенты, которые купили больше трёх товаров в январе и не возвращали их». Генерируется SQL++ с подзапросом: подсчёт заказов через COUNT, JOIN с returns, условие HAVING COUNT > 3 и NOT EXISTS для возвратов. Система автоматически определяет, что «январь» относится к текущему году, если не указано иное.
Бенчмаркинг и точность: 76% по BIRD-методологии - что это значит
BIRD (Big Bench for Relational Databases) - это академический бенчмарк для оценки способности систем генерировать SQL по текстовым описаниям. Он содержит 12 751 вопрос-запрос по 95 базам данных разного размера и сложности. Ключевая метрика - Execution Accuracy (EX): SQL считается правильным, если результат его исполнения совпадает с эталонным. Это жёстче, чем Exact Set Match, где сравнивается текст запроса.
Capella iQ показала 76% EX на подмножестве BIRD, релевантном для документо-ориентированных баз данных (основной профиль Couchbase). Это означает: из 100 вопросов ассистент генерирует корректный SQL++ для 76. Для контекста: GPT-4 на момент тестирования показывал 54-58% на том же подмножестве, специализированные SQL-модели вроде DAIL-SQL - 68-72%.
Как проводилось тестирование: методология и датасет
Couchbase адаптировала BIRD под свой диалект SQL++. Из 95 баз выбрали 23, релевантных по структуре (документные и смешанные модели данных). Каждый вопрос прогонялся через Capella iQ трижды для оценки стабильности. Фиксировались три метрики: Execution Accuracy (совпадение результатов), Valid SQL Rate (процент синтаксически корректных запросов) и Average Latency. Тесты проводились на изолированном инстансе Capella с предварительно загруженными датасетами BIRD.
Из 76% успешных: 58% запросов были сгенерированы с первой попытки, 18% потребовали одной итерации исправления после ошибки EXPLAIN. Оставшиеся 24% распределились так: 12% - синтаксически верный SQL, но неверный результат (логические ошибки в JOIN или фильтрах), 8% - синтаксические ошибки после трёх попыток, 4% - отказ системы (запрос признан небезопасным или нерелевантным).
Интерпретация 76%: сильные стороны и зоны роста
Сильные стороны: простые SELECT с WHERE (точность 94%), запросы с агрегацией GROUP BY (82%), JOIN двух таблиц (78%). Зоны роста: JOIN трёх и более таблиц (61%), вложенные подзапросы с корреляцией (55%), запросы с UNION и INTERSECT (48%). Это коррелирует с общей статистикой по индустрии: даже специализированные модели испытывают трудности с многотабличными конструкциями.
Команда Couchbase обозначила три направления улучшения. Первое: расширение few-shot примеров для сложных JOIN. Второе: декомпозиция сложного запроса на цепочку простых с промежуточной валидацией (аналог Chain-of-Thought для SQL). Третье: файнтюнинг модели специально под SQL++ диалект через Custom Model Import в Bedrock. Это должно поднять точность на сложных запросах до 80-82%.
Провайдер-агностическая архитектура и управление нагрузкой
Couchbase с самого начала проектировала Capella iQ с расчётом на смену провайдера или модели без переписывания кодовой базы. Это решение оправдало себя: за время разработки на Bedrock появились новые модели, и команда смогла добавить их в ротацию за несколько дней.
Абстракционный слой: как оставаться независимым от конкретного провайдера
Абстракционный слой построен на интерфейсе ModelAdapter с тремя методами: generate(prompt, config), stream(prompt, config), embed(text). Каждая модель (Claude Haiku, Sonnet, Opus) реализует этот интерфейс. Конфигурация вынесена в декларативный YAML-файл, где для каждой модели указаны: идентификатор в Bedrock, регионы доступности, лимиты по токенам, таймауты, стоимость за 1000 токенов.
При добавлении новой модели достаточно реализовать адаптер и добавить запись в конфиг. Роутер и Model Selector работают с абстрактным интерфейсом и не зависят от конкретного провайдера. Это позволяет в будущем переключиться с Bedrock на другой сервис или использовать гибридную схему (часть моделей на Bedrock, часть - на собственных GPU).
Управление нагрузкой включает три механизма. Rate limiting: на уровне пользователя (не более 30 запросов в минуту) и на уровне модели (не более 500 запросов в минуту на аккаунт Bedrock). Приоритезация: запросы на генерацию SQL получают приоритет над документационными вопросами. Кэширование: если идентичный запрос (с той же схемой БД) поступает в течение 5 минут, возвращается кэшированный ответ без вызова модели. Это экономит до 15% затрат на инференс.
Custom Model Import: зачем Couchbase планирует запускать свои модели
Custom Model Import в Amazon Bedrock позволяет загружать собственные fine-tuned модели и использовать их через тот же API, что и базовые. Couchbase анонсировала планы по файнтюнингу Claude Haiku на корпусе из 50 000 пар «вопрос → SQL++», собранных из реальных пользовательских сессий (обезличенных). Цели: снизить задержку на простых запросах до 300 мс (против 800 мс у базовой Haiku), поднять точность на специфичных для Couchbase паттернах (работа с JSON-полями, UNNEST, работа с массивами).
Экономическая модель: кастомная Haiku будет использоваться для 70% всех запросов (простые и средние). Базовая Sonnet останется для сложных. Opus - только для самых тяжёлых случаев (около 5% трафика). При текущих объёмах это сокращает затраты на инференс на 30-40% без потери точности. Запуск запланирован после достижения точности кастомной модели > 80% на внутреннем бенчмарке.
Практические выводы и уроки от команды Couchbase
Первый вывод: мультимодельный роутинг окупается даже при двух моделях. Команда начинала с пары Haiku + Sonnet и получила 20% улучшение соотношения latency/accuracy по сравнению с одной Sonnet. Не нужно сразу строить сложный ансамбль - достаточно разделить простые и сложные запросы.
Второй вывод: бенчмаркинг на синтетических датасетах вроде BIRD полезен для старта, но реальную точность показывают только пользовательские данные. Couchbase обнаружила, что 30% ошибок в проде связаны с нестандартными именами полей (креативный нейминг разработчиков) и устаревшей схемой в промпте. Решение: автоматическое обновление DDL в промпте при каждой смене схемы и валидация имён полей через системный каталог.
Третий вывод: валидация SQL - это не опция, а обязательный компонент. Без неё Capella iQ генерировала синтаксически неверный SQL в 8% случаев. С трёхшаговой валидацией этот показатель снизился до 1.2%. Инвестиции в постобработку окупаются быстрее, чем попытки улучшить промпт.
Четвёртый вывод: кросс-региональный инференс на Bedrock требует мониторинга квот. В пиковые часы Bedrock может возвращать throttling-ошибки даже при формально достаточных квотах. Couchbase добавила упреждающее переключение региона при достижении 70% лимита - это снизило количество отказов на 90%.
Пятый вывод: провайдер-агностическая архитектура окупается с первого дня. Когда Bedrock добавил поддержку Claude 3, команда интегрировала новые модели за три дня и сразу получила прирост точности на 5%. Без абстракционного слоя это заняло бы недели.
Неожиданная сложность: пользователи ожидают, что ассистент понимает контекст их бизнеса, а не только схему БД. Запрос «покажи моих VIP-клиентов» требует знания, что VIP определяется по полю customer_tier = 'platinum', а это бизнес-логика, отсутствующая в DDL. Couchbase решает это через кастомный слой метаданных, который пользователь может заполнить в интерфейсе Capella.
Эти выводы коррелируют с более широкими трендами в построении корпоративных AI-систем. В материале о корпоративной ИИ-архитектуре мы разбирали аналогичные паттерны: разделение ответственности между моделями, обязательную валидацию выходных данных и построение провайдер-агностического слоя как стандарт для enterprise-внедрений. Архитектурные принципы, заложенные в Capella iQ, применимы к любому проекту, где AI-ассистент работает с базами данных и не может позволить себе галлюцинации.
Методология A.L.F.R.E.D., разобранная в отдельной статье, предлагает альтернативный подход к той же проблеме: дистилляция шаблонов и адаптивный роутинг позволяют малым моделям на 2B параметров достигать точности 35B-моделей для повторяющихся запросов. Couchbase пока не использует дистилляцию, но их планы на Custom Model Import движутся в том же направлении - запуск лёгкой специализированной модели для массовых запросов и тяжёлой универсальной для сложных случаев.
Для тех, кто проектирует собственного AI-ассистента с интеграцией Bedrock, практическое руководство по Amazon Bedrock Managed Knowledge Base даёт пошаговую настройку базы знаний с кодом на Python и сравнение прямого и агентного поиска. Это дополнит понимание того, как Couchbase могла бы расширить Capella iQ поиском по документации.