Справочник Oper8 · Концепт
Корень шестерни «База знаний». Что именно закладываем в knowledge-слой.
Определение. Проектирование контекста (Context Engineering) — практика сборки и поддержки слоя знаний, на котором AI-агент принимает решения в вашем процессе.
TL;DR. Без проектирования контекста любой агент даёт усреднённые ответы — а ваш бизнес работает на исключениях. База знаний собирается из трёх слоёв: факты, правила, примеры, и каждый живёт по своему ритму. Чем богаче и живее этот слой, тем выше автономия агента и тем труднее его заменить чужим решением из коробки.
Проектирование контекста — это работа по сборке всего, что агент должен «знать» в момент принятия решения: фактов о компании, правил действий, типовых ситуаций и границ. Промпт — только один маленький фрагмент этой работы; сама модель — её движок. В крупных AI-программах за сборку и поддержку контекстного слоя отвечает выделенная функция, а не один разработчик в свободное время.
В методике Oper8 проектирование контекста — это корень шестерни «База знаний» маховика данных. Без неё агент работает в вакууме: технически выдаёт ответы, но не приземлён в вашу реальность — не знает вашего каталога, типов клиентов и того, как у вас принято обрабатывать исключения. Результат — галлюцинации в 30–50 % случаев и потолок автономии на уровне «AI подсказывает, человек решает».
Контекст — живая система: обновляется каждый месяц вместе с бизнесом, а не настраивается один раз перед запуском. Документация написана для человека, контекст — для агента, и форматы у них разные. Главное: модели меняются каждые полгода, контекстный слой остаётся. Через два года вы трижды поменяете движок, но если строили базу знаний с первого месяца — она с вами и продолжает накапливать ценность.
База знаний — это три слоя, у каждого свой ритм обновления и свой источник истины. Поверх них работают два режима подачи в агент: ориентир и ограничитель.
То, что верно для вашей компании и редко меняется: каталог продуктов, типы клиентов, условия работы с партнёрами, регуляторные ограничения.
В банке это лимиты по ролям, список запретных юрисдикций, нормативы по KYC. В дистрибуции — каталог SKU, минимальные заказы, сезонные ограничения. Источник — выгрузка из CRM, ERP, 1С. Обновление автоматическое, раз в квартал. Если факты устарели, агент уверенно работает по мёртвым данным — самый опасный режим из трёх.
Как принимать решения в типовых ситуациях. Каждое правило — это регламент, по которому действует агент.
Пример правил из дистрибуции: «Если клиент заказал три раза в месяц в последние полгода — даём скидку +5 %». «Если клиент новый, но точка заказывала похожий продукт — предлагаем бесплатный образец». «Если предложение отклонено — повтор только через 10 дней».
У одного из наших клиентов-дистрибьюторов на первой неделе консультант записал 15 правил. Через два месяца их стало 40. Это нормальный темп: правила собираются на интервью с владельцем процесса, потом уточняются на живых кейсах.
Главное свойство этого слоя: когда вы меняете правило вечером, агент уже работает по нему на следующий день — на всех клиентах сразу, без переподготовки модели.
Реальные ситуации с решением, обоснованием и результатом. Люди и агенты учатся на примерах эффективнее, чем на абстрактных правилах.
Ключевая особенность третьего слоя: он растёт сам через лог решений. Каждое решение агента плюс реакция клиента — новый пример в базе. По нашим наблюдениям, третий слой доходит до 300 примеров за 2–3 месяца без отдельной работы по наполнению — просто логирование делает свою работу.
Дальше эти примеры подставляются в контекст следующего запроса как обогащение примерами (few-shot), и качество растёт без дообучения модели.
Контекст работает в агенте двумя способами одновременно. Как ориентир — слои подставляются в запрос перед каждым решением, агент читает рамки и привязывается к реальности. Как ограничитель — слои задают границы: агент не может предложить цену ниже минимума, пообещать доставку без учёта ограничений, нарушить красную линию (см. свод правил). Оба режима вместе поднимают автономию с уровня A2 до уровня A3–A4 — от «AI подсказывает» до «AI действует в рамках, человек решает спорные случаи».
В федеральной торговой сети мы собирали базу знаний для контактного центра, где обрабатывают повторные обращения клиентов с продуктовой рекомендацией. До проектирования контекста агент по любому запросу давал универсальный ответ «уточните детали у менеджера» — это была A1 с долей вмешательств 70 %. После сборки трёх слоёв (4 недели работы, 25 правил, 180 примеров из истории чатов) агент стал распознавать тип клиента, повод обращения и подходящие сценарии — доля вмешательств упала до 22 %, конверсия в дополнительный заказ выросла в 1,8 раза.
В банке федерального уровня для первичного скоринга кредитных заявок контекстный слой включал лимиты по 14 продуктам, 60 правил отсечения и 400 размеченных кейсов из истории решений за полгода. Это вывело агента на уровень A3 (автономное решение по типовым заявкам с эскалацией спорных) с уверенностью 87 % — против 64 % у системы без структурированной базы знаний.
Сроки разные по сегментам. В Mid-market база знаний на одном процессе собирается за 4–6 недель и за 3–4 месяца через лог решений дозревает до уровня A3. В Enterprise обычно собирают на одном пилотном процессе за 6–8 недель, потом тиражируют шаблон трёх слоёв на 3–5 соседних процессов. Эффект накопительный: за первые 6 месяцев правил становится в 2–3 раза больше, примеров — в 10 раз. Этот контекстный слой, а не модель, превращается в актив, который конкурент не получит, даже если поставит ту же модель.
Первый шаг — четырёхчасовое интервью с владельцем процесса плюс выгрузка существующих регламентов из CRM/ERP. Не пишите 200-страничный документ — для агента он не работает. Соберите за один день первую версию из 10–15 ключевых правил, базового каталога фактов и 30–50 примеров из истории решений. Этого хватит, чтобы запустить пилот на уровне A2. Если такой день сложно выкроить силами одной команды — это типичный сценарий, ради которого мы делаем 2-дневный воркшоп Oper8: сидим в одной комнате с владельцем процесса и доменными экспертами и выходим с готовой первой версией.
Ведёт работу владелец процесса — человек, который отвечает за бизнес-результат и знает правила наизусть. Технический инженер настраивает инфраструктуру (где хранится база, как подставляется в запрос, как ведётся версионирование), но содержание правил всегда от владельца. Если базу собирает только инженер — она получится синтаксически правильной и бизнес-бесполезной.
Если владельца процесса в команде нет. Это самый частый блокер в Enterprise: процесс расщеплён между 3–4 функциями, у каждой свой кусок правил, никто не отвечает за результат целиком. В таких случаях мы начинаем не со сборки базы знаний, а с диагностики — за 30 минут определяем, есть ли у процесса хозяин и кто им может стать. Без этого шага база знаний получится «ничьей» и через 2 месяца превратится в мёртвую (см. следующий раздел).
Мёртвая база знаний — опаснее её отсутствия. Факты не проверялись три месяца, правила не обновлялись с прошлого квартала, примеры устарели. Агент уверенно работает по мёртвым данным — и компания узнаёт об этом только когда клиент жалуется на отказ по уже неактуальному условию. Когда правил нет вовсе, сотрудник это видит и идёт уточнять. Когда правила есть, но мёртвые — никто не идёт, пока не прилетает претензия. Лечение: раз в неделю владелец процесса сверяется с метриками качества и проверяет, не падает ли точность; если падает — первое место для поиска причины база знаний, а не модель.
Парализующий перегруз правилами. Команда пытается заранее описать все исключения: 200 правил, 50 условий, условия на условиях. Агент ломается на неоднозначности — для одного и того же кейса срабатывают три противоречивых правила, и он замирает. Лечение: оставить в правилах 10–15 ключевых, всё остальное переводить в примеры третьего слоя. Примеры терпимы к противоречиям — два разных решения для двух похожих ситуаций означают, что граница между ними нюансная и решается контекстом, а не правилом.
База знаний как документация для аудита, а не для агента. Самый частый режим отказа в больших организациях с сильной функцией compliance. Команда пишет 200-страничный регламент, отдаёт на согласование, через 4 месяца получает подписанный документ. Агент этот документ не читает: он не структурирован под автоматическую подстановку в контекст. Лечение: с первого дня писать базу знаний в формате, который реально подставляется агенту в запрос — структурированный markdown или JSON с понятной иерархией. Compliance-сверку делать отдельным проходом по уже работающей базе, не вместо неё.
Связанные статьи
Разберём вашу задачу, подберём формат и покажем, как AI может усилить ваши процессы.
50+
компаний прошли путь AI-трансформации с нами — от аудита до работающих решений.
© 2026 Кактус.AI — подразделение ScrumTrek
