Когда заказчик говорит «хотим добавить в продукт AI», в голове у него обычно одна коробка — модель. В любой системе, которая реально дошла до продакшена, модель — самая маленькая коробка на схеме. Вокруг неё стоит приложение, которое разговаривает с пользователем, данные, которые модели разрешено видеть, и инструменты, которые ей разрешено вызывать. Коммерческое предложение, где упомянута только модель, ничего не говорит о том, что на самом деле построят.
Эта глава называет детали своими именами — чтобы, когда на слайде подрядчика их окажется шесть, вы могли спросить, какие две из них проекту действительно нужны, а какие туда попали просто потому, что подрядчик умеет их продавать.
4.1 Форма
Под любым брендингом у AI-решения один и тот же скелет:
- Пользователь
- Приложение
- LLM
- Данные и инструменты отвечают обратно через LLM
Пользователь никогда не разговаривает с моделью напрямую. Приложение решает, что пользователю можно спросить, форматирует вопрос и решает, что делать с ответом. Модель, в свою очередь, не читает файлы компании и не дёргает её API сама по себе — она дотягивается только до тех данных и инструментов, которые приложение к ней подключило. Всё, что появляется дальше, — это одно из двух: то, что модели дали прочитать, или то, что ей разрешили сделать. Не путать эти две вещи — почти весь смысл этой главы.
4.2 Что модели разрешено читать
Три термина покрывают почти все заявления вида «AI знает наши данные», и решают они разные задачи.
Эмбеддинги — это превращение текста в набор чисел, расположенных так, что близкие по смыслу фразы оказываются рядом. Заказчик это не покупает как отдельный продукт — это механизм, с помощью которого система поиска находит «пункт про штрафы за просрочку поставки», даже если ни в вопросе, ни в документе нет этой формулировки дословно.
Векторная база — это место, где живут эти числа, когда документов миллионы и нужно находить ближайшие за миллисекунды. Это инфраструктура, а не интеллект: специализированный индекс, родственник обычного поиска, только заточенный не под «найди текст с этим словом», а под «найди похожее по смыслу».
База знаний — обычное человеческое название для самих документов: регламентов, обращений, инструкций, договоров, на которые система должна опираться. Обычно именно эта часть занимает больше всего времени, потому что это проблема качества данных, переодетая в AI: версии противоречат друг другу, ответственного нет, процесса обновления нет. Если подрядчик на встрече первым делом рассказывает про векторную базу и мельком — про базу знаний, у него перепутан порядок важности.
Что делает система, построенная поверх этих трёх вещей, — тема раздела 5; здесь мы только называем детали и не путаем их между собой на встрече.
4.3 Что модели разрешено делать
Tool calling — это когда модель просит приложение выполнить конкретное действие: посмотреть заказ, отправить письмо, создать заявку — и получает результат обратно, чтобы рассуждать дальше. «Function calling» — то же самое под старым названием; если подрядчик в одной презентации использует оба термина как будто это разные возможности, у него не две возможности, а нестыковка в документации.
Здесь проходит граница между ассистентом и агентом, и её стоит проводить точно: модель с доступом на чтение может сказать пользователю, что написано в правилах возврата. Модель с вызовом биллинговой системы может сама оформить возврат. Второе требует вопроса, которого первое никогда не поднимает: кто отвечает, если система один раз действует на основании неверных данных, — и этот вопрос должен появиться в коммерческом предложении, а не всплыть в продакшене.
4.4 Два протокола, и почему это не конкуренты
Сейчас на слайде почти любого подрядчика мелькают две аббревиатуры, и подаются они так, будто заказчику нужно выбрать одну: MCP и A2A. Это не альтернативы. Они решают две разные задачи связи, и обе иногда важны в одном и том же проекте.
MCP — про вертикальную связь на схеме выше: он стандартизирует, как приложение передаёт модели её инструменты и данные, чтобы инструмент, написанный один раз, можно было подключить к разным моделям и приложениям, не переписывая обвязку каждый раз заново.
A2A — про горизонтальную связь: он стандартизирует, как один агент — возможно, написанный другой командой, на другом стеке, внутри компании или за её пределами — обращается к другому агенту, чтобы, например, агент закупок заказчика и агент поставщика, отвечающий за отгрузку, могли обменяться запросом, не видя внутреннего устройства друг друга.
Не давайте слайду подрядчика превратить это в пункт чек-листа для галочки. Кто управляет каждой из этих спецификаций, на какой они версии и кто их уже принял — меняется быстрее, чем печатается презентация, и число со слайда полугодовой давности вполне может быть уже неверным; не повторяйте такое по памяти, а фразу вроде «полная поддержка A2A» в презентации подрядчика воспринимайте как вопрос для проверки, а не как факт для пересказа заказчику. Стабильна именно форма задачи, которую решает каждый протокол, — и именно про неё можно уверенно рассуждать на встрече, не открывая источник заранее.
4.5 Вопрос, ради которого написана эта глава
Не каждому проекту нужны все четыре коробки. Внутреннему ассистенту по частым вопросам сотрудников нужны приложение, модель и база знаний — без инструментов, без протоколов, без всего, что действует. Агенту закупок, который торгуется с системой поставщика, нужен tool calling и, вероятно, A2A, а векторная база может вообще не понадобиться, если искать нечего — весь смысл в переговорах, а не в поиске по документам.
Прежде чем принять схему, прогоните её в обратную сторону от запроса заказчика. Для каждой коробки на слайде задайте два вопроса: что из реальной задачи заказчика требует именно этого элемента, и заработает ли проект без него? Если ответ на второй вопрос «да», коробка попала на слайд потому, что она есть в продукте подрядчика, а не потому, что она нужна проекту, — и именно эта фраза превращает раздутое предложение в предложение по размеру задачи.