Основная задача большой языковой модели (Large Language Model, LLM) — формировать ответы на основе доступного контекста. При этом у LLM есть важная особенность — высокая контекстная зависимость.

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

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

При этом корпоративному ИИ-агенту недостаточно просто работать с текстом. Он должен взаимодействовать с реальными источниками информации:

• таблицами;
• аналитическими витринами;
• отчетами;
• CRM-системами;
• внутренними базами данных.

Само подключение ИИ-агента к данным технически уже не является сложной задачей. Для этого используются различные механизмы интеграции, включая MCP-серверы (Model Context Protocol), которые предоставляют модели стандартизированный доступ к внешним инструментам и источникам информации.

Однако MCP решает только задачу доступа к данным. Он не объясняет модели, что означают эти данные, какие показатели являются корректными и какие бизнес-правила необходимо учитывать.

Иными словами, наличие доступа к информации еще не означает наличие понимания.

В корпоративных системах часто встречаются исторически сложившиеся структуры:

• поля с непонятными названиями вроде SUMMA_NEW, SUMMA2 или CLIENT_TYPE;
• внутренние коды вместо понятных значений;
• разные справочники в нескольких системах;
• неполностью заполненные данные;
• отсутствие описания бизнес-логики.

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

Для ИИ-агента эти данные сами по себе не содержат необходимого смысла.
Например, подразделение может храниться в системе как значение «104». Сотрудник знает, что это конкретный филиал или отдел. Но без дополнительного описания модель не сможет определить, что означает этот код и как его использовать при подготовке ответа.

Еще одна распространенная проблема — отсутствие единого понимания показателей.
В базе могут одновременно существовать несколько полей:

• первоначальная сумма заказа;
• сумма после скидки;
• итоговая стоимость;
• сумма с учетом дополнительных условий.

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

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

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

Каталог данных — это структурированное описание корпоративной информации, которое помогает сделать данные понятными как для сотрудников, так и для автоматизированных систем.

В современной архитектуре корпоративных ИИ-решений каталог данных становится не просто справочником таблиц и полей, а частью системы управления метаданными (metadata management). Он фиксирует не только технические характеристики данных, но и их бизнес-смысл: назначение показателей, владельцев данных, источники информации, правила использования и связи между объектами.

Его задача заключается не только в хранении списка таблиц и полей. Каталог фиксирует:

• что означает конкретный показатель;
• из каких источников он формируется;
• как связан с другими объектами данных;
• в каких бизнес-сценариях используется;
• какие ограничения необходимо учитывать при работе с ним.

В зависимости от уровня зрелости компании каталог данных может включать:

• описание таблиц и отдельных полей;
• бизнес-глоссарий;
• описание физической, логической и концептуальной моделей данных;
• информацию об источниках данных;
• связи между объектами;
• правила преобразования информации;
• описание аналитических витрин;
• владельцев данных и ответственных за их качество;
• информацию о происхождении данных (data lineage).

Data lineage позволяет отслеживать полный путь информации: от момента появления в исходной системе до использования в отчетах, аналитических моделях или ИИ-агентах.

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

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

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

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

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

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

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

Для ИИ-агента такой уровень описания становится дополнительным контекстом. Вместо самостоятельной попытки определить назначение каждого поля модель получает структурированное объяснение и может использовать информацию более точно.

При этом компании не обязательно сразу создавать сложную корпоративную платформу управления данными.

На начальном этапе достаточно описать те источники и объекты, с которыми будет работать конкретный ИИ-агент.

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

Однако одного каталога данных недостаточно.

Он отвечает на вопрос: что представляют собой данные и где они находятся.

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

Именно эту задачу решает семантический слой.

В корпоративной среде сотрудники редко формулируют задачи техническим языком.
Например, руководитель отдела продаж может сказать сотруднику:

«Посмотри, что зависло по региону».

Опытный специалист понимает, что требуется сделать:

• открыть CRM;
• найти заказы определенного подразделения;
• проверить их статусы;
• определить причины задержки;
• подготовить дальнейшие действия.

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

Новый сотрудник может попросить уточнить задачу.

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

Такая же проблема возникает у ИИ-агента.

Он может найти в базе информацию о заказах, но не сможет самостоятельно определить:

• какие заказы считать «зависшими»;
• какие статусы учитывать;
• что именно означает название региона;
• какие показатели использовать;
• нужно ли просто показать список объектов или подготовить рекомендации по дальнейшим действиям.

Ответы на эти вопросы находятся не в структуре базы данных.
Они являются частью бизнес-знаний компании.

Именно поэтому одного каталога данных недостаточно. Он описывает структуру информации, но не всегда объясняет, как эта информация используется в конкретных бизнес-сценариях.

Эту задачу решает семантический слой.

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

Семантический слой представляет собой описание предметной области компании: ее терминов, процессов, правил и способов работы с информацией.

Он связывает привычный для сотрудников язык с конкретными объектами в корпоративных системах.

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

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

В одной компании это заявки со статусом «Ожидает подтверждения».
В другой — заказы, по которым нарушены сроки выполнения.
В третьей — обращения, где отсутствуют необходимые параметры для запуска производства.

Человек, работающий внутри компании, понимает эти различия благодаря опыту.

Для ИИ-агента такие знания необходимо заранее формализовать.

В семантический слой могут входить:

• описание типовых пользовательских запросов;
• корпоративные термины и сокращения;
• внутренний сленг;
• правила интерпретации показателей;
• описание бизнес-процессов;
• допустимые сценарии использования данных;
• требования к формату ответа;
• связи между бизнес-терминами и физическими объектами данных.

Фактически семантический слой превращает экспертизу сотрудников в структурированное знание, которым может пользоваться ИИ-агент.

Например, сотрудники компании используют выражение «зависшие заявки».

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

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

Максимальный эффект эти инструменты дают при совместном использовании.
Каталог данных и семантический слой выполняют разные, но взаимодополняющие функции.

Каталог данных помогает ИИ-агенту определить:

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

Семантический слой помогает:

• понять смысл запроса пользователя;
• определить бизнес-контекст задачи;
• выбрать подходящую логику обработки;
• сопоставить пользовательские термины с объектами данных;
• сформировать результат в понятном для сотрудника виде.

Рассмотрим пример.

Сотрудник задает вопрос:

«Какие клиенты принесли больше всего прибыли в третьем квартале?»
На первый взгляд запрос выглядит простым. Однако для ИИ-агента это сложная аналитическая задача.

Чтобы подготовить корректный ответ, система должна выполнить несколько последовательных действий:

1. Определить, что именно означает показатель «прибыль» в конкретной компании.
2. Понять, учитываются ли при расчете возвраты, скидки, расходы и другие параметры.
3. Найти данные о клиентах и финансовых результатах.
4. Выбрать подходящую аналитическую витрину.
5. Сформировать запрос к данным, например через SQL.
6. Выполнить необходимые расчеты.
7. Проверить корректность результата.
8. Подготовить ответ в нужном формате.

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

При этом модель может корректно сформировать SQL-синтаксис, но обратиться не к тем таблицам или использовать неверную бизнес-метрику, если у нее нет информации о внутренней логике компании.

Пользователь видит только итоговый результат, однако внутри системы агент выполняет несколько этапов обработки информации.

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

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

Это комплексная система, в которой LLM работает вместе с дополнительными уровнями знаний, описывающими данные, бизнес-правила и контекст организации.

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

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

Один из подходов — использование архитектуры с несколькими агентами.
Например, один агент выполняет роль аналитика, а второй — роль критика.

Агент-аналитик:

• ищет необходимую информацию;
• анализирует данные;
• формирует решение;
• готовит итоговый ответ.

Агент-критик:

• проверяет логику рассуждений;
• оценивает соответствие результата бизнес-правилам;
• проверяет синтаксис сгенерированного кода (например, SQL) до его выполнения;
• выявляет возможные ошибки;
• предлагает исправления.

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

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

Даже несколько агентов не смогут надежно решить задачу, если исходная информация не имеет описания, бизнес-правила не зафиксированы, а показатели трактуются по-разному.

Поэтому качество работы ИИ-агента зависит не только от возможностей модели, но и от зрелости процессов управления данными (data governance).

Сюда входят:

• контроль качества данных;
• управление изменениями;
• описание источников;
• согласование бизнес-терминов;
• назначение владельцев данных.

Одна из распространенных ошибок при создании корпоративных ИИ-решений — попытка предоставить агенту доступ ко всему массиву информации компании.

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

Однако на практике избыточный контекст может снизить качество работы ИИ-агента.
Каталог данных и семантический слой крупной организации со временем становятся объемными.

Они могут включать информацию о:

• финансовых процессах;
• продажах;
• производстве;
• логистике;
• кадровых системах;
• внутренних регламентах.

При этом конкретный запрос пользователя обычно относится только к одной предметной области.

Например:

«Какие клиенты были наиболее прибыльными в третьем квартале?»
относится к финансовому анализу.

Для ответа агенту необходимы данные о:

• клиентах;
• продажах;
• доходах;
• расходах;
• финансовых показателях.

Информация о производственных процессах или кадровых системах в данном случае не нужна.

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

Агенту становится сложнее определить, какие знания действительно относятся к текущей задаче.

В результате повышается риск ошибок:

• модель может смешивать разные понятия;
• использовать нерелевантные данные;
• выбирать неподходящие показатели;
• формировать неточные выводы.

Поэтому современные архитектуры ИИ-агентов предполагают работу с релевантной частью знаний.

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

Такой подход позволяет:

• снизить объем передаваемого контекста;
• повысить скорость обработки;
• уменьшить вероятность ошибок;
• сделать поведение агента более стабильным.

Еще один важный фактор успешного внедрения ИИ-агентов — качество самих источников информации.

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

В них могут содержаться:

• сложные связи между таблицами;
• технические идентификаторы;
• дублирующиеся справочники;
• исторические поля;
• данные, предназначенные только для внутренних операций системы;
• неактуальные или неполные значения.

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

Например, вместо ответа на вопрос о продажах агенту приходится самостоятельно выяснять:

• какая таблица является актуальной;
• какой идентификатор соответствует конкретному объекту;
• какое поле содержит итоговое значение;
• какие данные необходимо исключить из расчета.

Для решения подобных задач используются аналитические витрины данных.
Они создаются специально для анализа и позволяют представить информацию в более удобном для бизнеса виде.

Еще более эффективный подход — использование семантических витрин данных.
Это подготовленные структуры, в которых:

• технические поля заменены понятными бизнес-терминами;
• аналитические признаки заранее рассчитаны;
• связанные данные объединены;
• сложные преобразования выполнены заранее;
• показатели представлены в согласованном формате.

Такие витрины становятся дополнительным уровнем абстракции между сложными корпоративными системами и ИИ-агентом.

Например, вместо внутреннего кода подразделения «104» агент получает понятное значение:

«Отдел продаж Москва».

Вместо технического идентификатора товара — название категории или продукта.

Вместо нескольких разрозненных полей с суммами — готовый показатель «итоговая выручка после учета возвратов».

Такая подготовка данных позволяет ИИ-агенту быстрее и точнее выполнять операции:

• поиска;
• фильтрации;
• группировки;
• расчета показателей;
• формирования аналитических выводов.

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

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

При создании семантического слоя важно учитывать реальные сценарии использования.

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

Например, разные пользователи могут использовать разные выражения для одной и той же задачи:

• «просроченные заявки»;
• «зависшие обращения»;
• «проблемные лиды»;
• «клиенты на удержании».

Для человека такие формулировки могут быть очевидно связанными.

Для ИИ-агента эти соответствия необходимо явно определить.

Также в семантический слой стоит включать:

• корпоративные сокращения;
• профессиональный сленг;
• типовые запросы сотрудников;
• правила расчета показателей;
• допустимые источники данных;
• ограничения доступа;
• требования к форме и детализации ответа.

Например, одному сотруднику нужен краткий ответ с ключевыми цифрами.

Другому — подробный аналитический отчет с объяснением причин, динамикой изменений и рекомендациями.

Эти сценарии также могут быть заложены в логику работы ИИ-агента.

Таким образом, семантический слой становится не просто описанием терминов, а механизмом передачи корпоративной экспертизы в цифровую систему.

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

Их внедрение требовало значительных усилий:

• необходимо было описывать источники;
• согласовывать определения показателей;
• управлять качеством данных;
• выстраивать процессы data governance.

С появлением ИИ-агентов роль этих инструментов становится еще более значимой.
Теперь качество подготовки данных напрямую влияет на скорость внедрения интеллектуальных решений.

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

Это сокращает путь от подготовки данных до получения практического результата.

Компания постепенно формирует единый слой знаний, который позволяет ИИ-агентам:

• понимать бизнес-процессы;
• учитывать изменения в структуре данных;
• использовать единые определения показателей;
• работать в рамках конкретной корпоративной среды.

В перспективе именно наличие такого слоя знаний станет одним из ключевых факторов масштабирования корпоративного ИИ.

Главное отличие корпоративного ИИ-агента от обычного чат-бота заключается в способности работать не только с текстом, но и с внутренними системами компании.

Такой агент может:

• анализировать информацию;
• находить необходимые данные;
• выполнять операции;
• запускать процессы;
• помогать сотрудникам принимать решения.

Однако для этого недостаточно просто подключить языковую модель к корпоративным источникам информации.

ИИ-агент должен понимать:

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

Фактически цель корпоративного ИИ-агента — стать не просто инструментом генерации ответов, а цифровым участником бизнес-процессов.

Но для этого ему требуется не человеческое понимание в привычном смысле, а формализованное представление бизнес-контекста:

• правил;
• ограничений;
• связей между объектами данных;
• сценариев использования информации.

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

Без описания данных и бизнес-контекста даже самая современная языковая модель остается универсальным инструментом, который может допускать ошибки.

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

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

Успешное внедрение ИИ-агентов зависит не только от выбора языковой модели или технологической платформы.

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

Современный корпоративный ИИ-агент должен работать не только с текстом, но и с формализованными знаниями организации.

Каталог данных помогает разобраться в структуре корпоративной информации:

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

Семантический слой дополняет эту информацию бизнес-контекстом:

• объясняет корпоративные термины;
• связывает пользовательские запросы с объектами данных;
• описывает правила расчета показателей;
• фиксирует особенности бизнес-процессов.

Совместное использование этих инструментов позволяет создать единый слой знаний (knowledge layer), который связывает возможности больших языковых моделей с реальной структурой бизнеса.

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

По мере того как компании будут расширять применение ИИ-агентов, именно качество подготовки данных станет одним из ключевых факторов успеха.

Развитие корпоративного ИИ будет связано не только с совершенствованием языковых моделей, но и с развитием процессов управления данными (data governance), включая контроль качества информации, управление метаданными и формирование единого понимания бизнес-показателей.

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

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