Введение: модель за сто миллионов параметров не знает, что такое «допуск посадки»
Я однажды наблюдал, как крупная производственная компания внедрила корпоративного ИИ-ассистента на базе одной из передовых языковых моделей. Инженеры-конструкторы задавали ему вопросы по допускам и посадкам, по шероховатости поверхностей, по выбору материалов для конкретных узлов. Модель уверенно генерировала ответы. Проблема в том, что примерно каждый третий ответ был технически бессмысленным. Не ошибочным в мелочах — именно бессмысленным. Модель путала систему отверстия с системой вала, предлагала допуски, которые физически не существуют в стандартах, смешивала метрическую и дюймовую системы там, где это категорически недопустимо.
При этом та же модель блестяще писала маркетинговые тексты, переводила статьи, суммаризировала документы. То есть проблема была не в «глупости» нейросети. Проблема была в том, что никто не потрудился объяснить ей, что такое предметная область машиностроительного допускового контроля, какие термины в ней значат что, какие сущности связаны между собой и где проходят границы компетенции.
Эта история — не исключение. Это правило. И оно повторяется в медицине, в юриспруденции, в финансах, в логистике, в фармацевтике. Везде, где LLM сталкивается с узкой профессиональной областью без предварительной доменной подготовки, результат одинаков: уверенная, гладкая, стилистически безупречная бессмыслица.
И вот тут на сцену выходит книга, написанная за двадцать лет до появления ChatGPT. Эрик Эванс в 2003 году опубликовал работу под названием Domain-Driven Design — «Предметно-ориентированное проектирование». Он решал задачу, которая тогда казалась чисто программистской: как строить сложные корпоративные системы так, чтобы разработчики не теряли связь с бизнес-логикой. Спустя два десятилетия оказалось, что его идеи ложатся на задачу обучения и применения больших языковых моделей почти идеально. Не как метафора. Не как красивая аналогия. А как рабочая инженерная методология.
Эта статья — подробный разбор того, почему понимание предметной области стало главным фактором качества LLM-систем в 2026 году и какие именно концепции Эванса помогают эту проблему решить. Я буду опираться на собственный опыт внедрения доменных знаний в ИИ-проекты, на наблюдения из инженерной практики и на идеи, которые до сих пор не получили должного внимания в русскоязычном профессиональном сообществе.
Информация в статье актуальна на сентябрь 2026 года.
Часть 1. Почему предметная область — узкое горлышко любой LLM
Что на самом деле умеет языковая модель
Большая языковая модель — это, если отбросить маркетинг, статистическая машина предсказания следующего токена. Она обучалась на огромном корпусе текстов и выучила вероятностные связи между словами и фрагментами слов. Когда модель генерирует ответ, она не «думает» в человеческом смысле. Она выбирает следующий токен на основе распределения вероятностей, сформированного в процессе обучения.
Это означает фундаментальную вещь: модель не обладает пониманием. Она обладает корреляцией. Для бытовых задач — написать письмо, пересказать статью, придумать идею для блога — этой корреляции достаточно. Но как только задача требует точного оперирования терминами, понимания причинно-следственных связей внутри конкретной дисциплины, знания нормативных документов или технологических процессов, статистическая корреляция начинает давать сбои.
Поясню на простом примере. В юриспруденции термины «неустойка», «штраф», «пеня» и «проценты за пользование чужими денежными средствами» — это разные правовые конструкции с разными основаниями начисления, разными процессуальными последствиями и разной судебной практикой. Для обывателя это синонимы. Для юриста — принципиально разные инструменты. Языковая модель, обученная на общем корпусе, где эти слова часто употребляются как взаимозаменяемые, будет путать их с высокой уверенностью. И чем увереннее она это делает, тем опаснее результат.
Эффект «гладкой ошибки»
Одно из самых опасных свойств LLM в доменном контексте — это то, что я называю эффектом гладкой ошибки. Модель не говорит «я не знаю». Она генерирует текст, который выглядит профессионально, использует правильную стилистику, выстраивает логичную на вид структуру. Но содержательно этот текст может быть полностью неверным.
В медицине это выглядит так: модель описывает схему лечения, которая звучит убедительно, использует корректную медицинскую лексику, но рекомендует сочетание препаратов, вызывающее опасное взаимодействие. В инженерии — рассчитывает нагрузку по формуле, которая существует, но применима к другому типу конструкции. В финансах — ссылается на нормативный акт или статью налогового кодекса, которые были отменены или изменены три года назад.
Проблема не в том, что модель глупая. Проблема в том, что ей не задали границы предметной области. Не объяснили, какие сущности существуют, как они связаны, какие правила действуют, а какие — нет. Не показали, где проходит граница между «я могу ответить компетентно» и «здесь нужна проверка экспертом».
Масштаб модели не решает доменную проблему
Есть распространённое заблуждение: если взять модель побольше, с большим числом параметров, обучить на большем объёме данных, то доменные ошибки исчезнут. Это не так. Я видел, как в компании переходили от модели с семью миллиардами параметров к модели с семьюдесятью миллиардами, а затем к модели с сотнями миллиардов — и доля доменных ошибок снижалась незначительно. Потому что проблема не в ёмкости модели. Проблема в том, что в обучающем корпусе узкоспециальные знания представлены фрагментарно, противоречиво и без явной структуры.
Увеличение модели помогает с общими рассуждениями, с пониманием контекста, с многоязычностью. Но для точной работы внутри конкретной предметной области нужен другой инструмент: явное описание этой области, её языка, её правил и её границ. И вот тут начинается территория, которую Эрик Эванс описал двадцать лет назад.
Три уровня доменного непонимания
Из практики я выделил три уровня, на которых LLM «не понимает» предметную область:
Первый уровень: терминологический. Модель путает термины, использует их неточно, подменяет близкие по звучанию или по общему значению понятия. Пример: в бухгалтерском и финансовом учёте небольшая модель путает «дебиторскую задолженность» и «кредиторскую задолженность» в контексте, где разница критична.
Второй уровень: структурный. Модель не видит связей между сущностями внутри области. Не понимает, что в логистической цепочке «заказ» порождает «отгрузку», которая порождает «транспортную накладную», которая связана с «актом приёмки» определённым образом. Генерирует ответы, где эти связи перепутаны или отсутствуют, из бизнес процесса может выпасть связующий процесс, который специалист просто подразумевает.
Третий уровень: нормативный. Модель не знает правил, ограничений, нормативных рамок, действующих в конкретной области. Или знает устаревшие версии этих правил. В юриспруденции, в налоговом учёте, в фармацевтике, в строительстве это особенно болезненно, потому что нормативная база меняется часто, а обучающий корпус модели имеет дату среза.
Все три уровня решаются не «улучшением модели», а явным описанием предметной области. И Эрик Эванс предложил для такого описания точный и практичный аппарат.
Часть 2. Эрик Эванс и книга, которая опередила время на двадцать лет
Кто такой Эрик Эванс и зачем он написал эту книгу
Эрик Эванс — американский программист и консультант, который в конце девяностых и начале двухтысячных годов работал над крупными корпоративными проектами. Он видел одну и ту же картину: команда разработчиков строит сложную систему, тратит месяцы на архитектуру, на инфраструктуру, на базы данных — а в итоге система не решает бизнес-задачу. Потому что разработчики не поняли, как работает бизнес. Не разобрались в терминах, которые используют заказчики. Не уловили нюансы процессов. Построили технически безупречную конструкцию, которая не соответствует реальности.
Книга Domain-Driven Design: Tackling Complexity in the Heart of Software вышла в 2003 году в издательстве Addison-Wesley. Она стала ответом на эту боль. Эванс предложил методологию, в которой центральное место занимает не технология, не фреймворк, не паттерн проектирования, а предметная область — та реальность, которую программа должна моделировать.
Малоизвестный факт: Эванс изначально не планировал писать книгу. Он вёл внутренние семинары для консультантов своей компании и для клиентов, и материал копился годами. Книга выросла из практических заметок и рабочих тетрадей. Именно поэтому она местами неровная, местами повторяется, местами уходит в длинные примеры. Но именно поэтому она содержит то, чего нет в «гладких» учебниках: живой опыт ошибок, реальные ситуации, честный разбор того, что не сработало.
Почему книга не устарела
За двадцать три года, прошедших с момента публикации, технологии изменились радикально. Появились облачные вычисления, микросервисы, контейнеризация, машинное обучение, большие языковые модели. Но одна вещь не изменилась: любая система, которая претендует на полезность, должна корректно моделировать ту область реальности, для которой она создана. Будь то учётная система для аптечной сети, навигационный алгоритм для беспилотного автомобиля или промпт для медицинского чат-бота — без точного описания предметной области результат будет некорректным.
Эванс сформулировал принципы, которые оказались инвариантными к технологическому стеку. И когда в 2023 году мир начал массово внедрять LLM в бизнес-процессы, выяснилось, что старые принципы работают лучше новых. Потому что новые подходы — «просто засуньте всё в промпт», «просто подключите RAG», «просто сделайте файнтюнинг» — разбиваются о ту же стену, о которую разбивались проекты двухтысячных: без понимания домена ничего не работает.
Что именно взял Эванс из практики
Одна из ключевых идей Эванса, которую он вынес из проектов, звучит так: самая дорогая ошибка в разработке — это не баг в коде. Это неверная модель предметной области. Если вы неправильно поняли, как работает бизнес-процесс, если перепутали сущности, если не увидели скрытое правило, то сколько бы усилий вы ни вложили в код, система будет делать не то.
Перенесите эту мысль на LLM. Если вы неправильно описали предметную область в системном промпте, если перепутали термины в базе знаний для RAG, если не задали границы компетенции модели, то сколько бы вы ни тюнили параметры, результат будет неверным. Та же самая ошибка. Тот же самый корень. Только масштаб последствий другой: в 2003 году неверная модель приводила к тому, что программа выдавала неправильный отчёт. В 2026 году неверная доменная модель в LLM-системе может привести к тому, что ИИ-ассистент даст пациенту опасную рекомендацию или юристу — ссылку на несуществующую норму права.
Часть 3. Ключевые концепции DDD в проекции на LLM
Это центральная часть статьи. Я разберу семь ключевых концепций из книги Эванса и покажу, как каждая из них работает в контексте больших языковых моделей. Не как абстрактная аналогия, а как конкретный инженерный инструмент.
3.1. Убиквитарный язык: как терминология формирует качество ответов
Что пишет Эванс. Убиквитарный язык, или единый язык команды, — это центральная концепция DDD. Эванс настаивает: все участники проекта — разработчики, аналитики, заказчики, тестировщики — должны использовать один и тот же набор терминов для описания предметной области. Не «примерно те же слова», а строго зафиксированный глоссарий, где каждый термин имеет единственное значение. Если в бизнесе говорят «заявка», значит в коде, в документации, в тестах, в разговорах — везде «заявка», а не «запрос», не «обращение», не «тикет». Так юристы делают в договорах, термины и определения, что-бы не было разночтений.
Проекция на LLM. Эта концепция напрямую ложится на то, как мы формулируем промпты и как строим базы знаний для RAG-систем. Языковая модель работает с токенами, и выбор конкретных слов в промпте определяет, какие паттерны активируются в весах модели. Если вы пишете в системном промпте «клиент», а в базе знаний тот же объект называется «контрагент», а в нормативных документах — «заказчик», модель будет путаться. Она будет генерировать ответы, где эти термины смешаны, где логика, применимая к «клиенту», переносится на «контрагента», хотя в конкретной предметной области это разные сущности с разными правами и обязанностями.
Практический пример. Я работал с проектом, где LLM-ассистент помогал кадровикам крупной компании. В компании исторически использовали слово «сотрудник» для штатных работников и «исполнитель» для тех, кто работает по гражданско-правовому договору. В системном промпте эти термины не были разведены. Модель периодически выдавала рекомендации по трудовому кодексу для исполнителей на ГПХ и наоборот. Кадровики тратили время на проверку каждого ответа. После того как мы ввели жёсткий глоссарий в системный промпт и в базу знаний, доля таких ошибок упала, по моим оценкам, на порядок.
Что делать. Составьте глоссарий предметной области. Каждый термин — одно определение. Никаких синонимов без явной пометки. Этот глоссарий должен быть включён в системный промпт или в метаинформацию базы знаний. И он должен быть единым: один и тот же список терминов для промптов, для документов, для обучения пользователей.
3.2. Ограниченный контекст: границы компетенции модели
Что пишет Эванс. Ограниченный контекст, или bounded context, — это идея о том, что одна и та же модель не может быть универсальной. В разных частях бизнеса одно и то же слово может означать разные вещи. «Товар» в контексте склада — это позиция с количеством, местом хранения и сроком годности. «Товар» в контексте маркетинга — это карточка с описанием, фотографиями и ценой. «Товар» в контексте бухгалтерии — это объект учёта с себестоимостью и амортизацией. Попытка создать единую модель «товара» для всех контекстов приводит к монстру, который не работает ни в одном из них. Соответственно у «товара» довольно много измерений, которые где-то универсальны, где-то специфичны и необходимы в различных задачах.
Проекция на LLM. Это, возможно, самая важная концепция Эванса для проектирования LLM-систем. Одна модель не может быть экспертом во всём. И попытки сделать «универсального ассистента», который одинаково хорошо отвечает на вопросы по налоговому праву, по сопромату и по детской психологии, обречены на посредственный результат в каждой из этих областей.
В 2026 году зрелые LLM-архитектуры строятся по принципу ограниченных контекстов. Это выражается в нескольких практических решениях:
Во-первых, мультиагентные системы, где каждый агент работает в своём домене. Один агент — бухгалтерия, другой — логистика, третий — юридические вопросы. У каждого свой системный промпт, своя база знаний, свой набор правил. Маршрутизатор направляет запрос к нужному агенту.
Во-вторых, сегментация RAG-базы. Вместо одной огромной базы документов — несколько тематических баз, каждая со своим контекстом. Поиск идёт сначала по определению контекста запроса, а затем внутри соответствующей базы.
В-третьих, явное указание границ в промпте. «Ты отвечаешь только на вопросы, связанные с кадровым учётом. Если вопрос выходит за эти рамки, скажи, что не можешь помочь, и предложи обратиться к профильному специалисту.»
Практический пример. В одном из проектов, где я участвовал как консультант, компания пыталась построить единого корпоративного чат-бота на базе LLM для всех подразделений. Бот путался между внутренними регламентами разных отделов, смешивал процедуры, выдавал инструкции из одного контекста в другой, особенно на большом контексте, забывал что в середине документов. После разделения на пять ограниченных контекстов — финансы, кадры, ИТ-поддержка, закупки, безопасность — качество ответов выросло настолько, что внутренняя служба поддержки зафиксировала снижение обращений к живым операторам.
3.3. Модель предметной области: как структурировать знания для ИИ
Что пишет Эванс. Модель предметной области — это упрощённое, но точное представление реальных процессов и сущностей, с которыми работает система. Эванс подчёркивает: модель — это не база данных и не диаграмма классов. Это совместное понимание того, как устроена предметная область, зафиксированное в явном виде. Модель должна быть достаточно богатой, чтобы отражать существенные связи, и достаточно простой, чтобы команда могла её обсуждать и изменять.
Проекция на LLM. Когда мы говорим о доменной адаптации языковой модели, мы по сути строим модель предметной области и передаём её модели. Вопрос только в форме передачи. Это может быть:
— Структурированный системный промпт, где описаны ключевые сущности, их атрибуты, связи между ними и правила поведения.
— База знаний для RAG, где документы организованы не хаотично, а по логике предметной модели: сущности, процессы, правила, исключения.
— Онтология или таксономия, которая задаёт иерархию понятий и отношения между ними.
— Набор примеров «вопрос — правильный ответ», которые демонстрируют модели ожидаемый способ рассуждения в рамках данной области.
Ключевой принцип Эванса здесь: модель должна быть явной. Не подразумеваться. Не «ну, модель сама разберётся из контекста». А быть записанной, задокументированной, согласованной с экспертами предметной области.
Что делать. Перед тем как настраивать LLM для конкретной задачи, сядьте с экспертом и нарисуйте модель предметной области. Какие сущности существуют? Какие у них атрибуты? Как они связаны? Какие процессы в них происходят? Какие правила и ограничения действуют? Где границы? Запишите это. Этот документ станет основой для всего: для промптов, для базы знаний, для тестовых сценариев.
3.4. Агрегаты и управление контекстным окном
Что пишет Эванс. Агрегат в DDD — это группа связанных объектов, которые рассматриваются как единое целое для целей изменения данных. У агрегата есть корень — главная сущность, через которую осуществляется доступ ко всей группе. Например, агрегат «Заказ» включает в себя строки заказа, данные доставки, историю изменений. Вы не меняете строку заказа напрямую — вы работаете через корень агрегата. Это обеспечивает целостность и непротиворечивость данных.
Проекция на LLM. Контекстное окно языковой модели — это ограниченный ресурс. Даже в 2026 году, когда контекстные окна достигают сотен тысяч и миллиона токенов, бесконечно засовывать информацию в контекст нельзя. И дело не только в стоимости и скорости. Дело в том, что при очень длинном контексте модель начинает «терять» информацию, расположенную в середине. Это явление, которое в исследовательской литературе называют «потерей в середине», было описано в работах нескольких групп в 2023–2024 годах и остаётся актуальным.
Принцип агрегата помогает структурировать контекст. Вместо того чтобы загружать в контекст все документы подряд, мы группируем информацию в логические блоки-агрегаты. Каждый агрегат содержит связанную информацию по одной теме или одной сущности. И в контекст попадает не всё, а только тот агрегат, который релевантен текущему запросу.
Практический пример. В RAG-системе для юридической фирмы мы организовали базу знаний по принципу агрегатов. Каждый агрегат — это конкретный нормативный акт со всеми его статьями, комментариями и судебной практикой, которая к нему относится. Когда пользователь задаёт вопрос, система определяет, какой агрегат или какие агрегаты релевантны, и подгружает их в контекст целиком. Это работает значительно лучше, чем нарезка документов на произвольные фрагменты по пятьсот токенов, потому что сохраняется смысловая целостность.
3.5. Сущности и объекты-значения: как модель должна различать данные
Что пишет Эванс. Эванс проводит чёткое различие между сущностями и объектами-значениями. Сущность — это объект, который имеет идентичность, продолжающуюся во времени. Клиент с идентификатором (ID) 4711 — это одна и та же сущность, даже если он сменил адрес, телефон и фамилию. Объект-значение — это объект, определяемый своими атрибутами. Адрес «Москва, улица Ленина, дом 5» — это объект-значение. Два одинаковых адреса — это один и тот же объект-значение. Но два разных клиента с одинаковыми адресами — это разные сущности.
Проекция на LLM. Это различие критично для того, как мы организуем информацию, которую подаём модели. Когда мы строим базу знаний или формируем промпт, мы должны явно различать:
— Сущности, которые имеют идентичность и историю: конкретный пациент, конкретный договор, конкретный проект. Модель должна понимать, что речь идёт об одном и том же объекте, даже если некоторые его атрибуты изменились.
— Объекты-значения, которые определяются набором характеристик: диагноз по МКБ, категория риска, тип договора. Здесь важна не идентичность, а содержание.
Если это различие не задано, модель начинает путать уровни. Привязывает свойства объекта-значения к сущности, к которой они не относятся. Или наоборот, теряет идентичность сущности, когда меняются её атрибуты.
Практический пример. В медицинском приложении, где LLM помогала врачам анализировать истории болезней, явно прописали в промпте: «Пациент — это сущность с уникальным идентификатором. Диагноз — это объект-значение, определяемый кодом МКБ и описанием. Один пациент может иметь несколько диагнозов в разное время. Диагноз не привязан к пациенту навсегда.» Без этого уточнения модель иногда «склеивала» диагнозы разных пациентов или теряла историю изменений диагноза у одного пациента.
3.6. Антикоррупционный слой: защита модели от «грязных» данных
Что пишет Эванс. Антикоррупционный слой, или Anti-Corruption Layer, — это паттерн, при котором между вашей системой и внешней системой ставится промежуточный слой, который транслирует данные из внешнего формата во внутренний. Если ваша система работает с определённой моделью предметной области, а внешняя система использует другую терминологию и другую структуру, антикоррупционный слой преобразует данные так, чтобы ваша модель не «загрязнялась» чужими концепциями.
Проекция на LLM. В контексте LLM этот паттерн приобретает огромное значение. Модели обучались на огромных массивах текста, где одни и те же концепции описаны по-разному, где термины используются неточно, где устаревшие данные смешаны с актуальными. Когда мы подключаем к модели внешние источники данных через RAG, мы рискуем «заразить» её некорректной информацией.
Антикоррупционный слой в LLM-системе — это:
— Валидация и нормализация данных перед загрузкой в базу знаний. Проверка, что термины соответствуют глоссарию, что данные актуальны, что формат единообразен.
— Фильтрация результатов модели перед выдачей пользователю. Проверка, что ответ не содержит терминов из соседних контекстов, что числа и даты корректны, что рекомендации не противоречат заданным правилам.
— Преобразование запросов пользователя в формат, понятный модели. Если пользователь говорит на бытовом языке, а модель настроена на профессиональную терминологию, промежуточный слой транслирует запрос.
Практический пример. В финансовой организации, где LLM анализировала нормативные документы Центрального банка, мы поставили антикоррупционный слой между базой нормативных актов и моделью. Этот слой проверял, не отменён ли документ, не изменён ли он, актуальна ли редакция. Без этого слоя модель периодически ссылалась на отменённые положения, потому что они присутствовали в обучающем корпусе и в базе знаний без пометки об отмене.
3.7. Стратегическое проектирование: как решать, что моделировать
Что пишет Эванс. В последних главах книги Эванс переходит от тактических паттернов к стратегии. Он вводит понятия основного домена, вспомогательного домена и универсального домена. Основной домен — это то, что отличает ваш бизнес от конкурентов. Вспомогательный домен — то, что нужно, но не является конкурентным преимуществом. Универсальный домен — то, что одинаково у всех: бухгалтерия, аутентификация, уведомления. Эванс рекомендует вкладывать основные усилия в моделирование основного домена, а универсальные домены решать типовыми средствами.
Проекция на LLM. Эта идея напрямую применима к расстановке приоритетов при внедрении ИИ. Не каждая задача в организации требует глубокой доменной адаптации модели. Если задача типовая — суммаризация писем, перевод, написание черновиков — достаточно общей модели с минимальной настройкой. Но если задача касается основного домена — того, что составляет суть бизнеса и конкурентное преимущество, — здесь нужна глубокая, детальная проработка предметной области.
Я видел компании, которые тратили месяцы на доменную адаптацию LLM для задач, которые прекрасно решаются общей моделью. И наоборот, пыталась решать ключевые бизнес-задачи «из коробки», без какой-либо доменной подготовки. И то и другое — пустая трата ресурсов. Стратегическое проектирование по Эвансу учит расставлять приоритеты.
Часть 4. Практическое применение: как предметная область меняет качество ответов ИИ
4.1. Промпт-инжиниринг через призму DDD
Промпт-инжиниринг в 2026 году — это не просто «написать красивый текст для модели». Это проектирование модели предметной области в формате, который модель способна интерпретировать. Когда я составляю системный промпт для доменного ассистента, я фактически реализую миниатюрный DDD:
Шаг первый: определяю ограниченный контекст. Чётко фиксирую, в какой области и кем работает ассистент. Не «ты помогаешь с вопросами», а «ты работаешь директором по кадрам и исключительно в контексте кадрового делопроизводства российской компании с численностью более пятисот человек, работающей по Трудовому кодексу Российской Федерации в редакции, актуальной на текущий момент».
Шаг второй: задаю убиквитарный язык. Перечисляю ключевые термины и их определения. Не предполагаю, что модель «поймёт из контекста». Явно пишу: «В данной предметной области используются следующие термины: работник — физическое лицо, состоящее в трудовых отношениях с работодателем на основании трудового договора; работодатель — юридическое лицо; кадровое делопроизводство — совокупность процедур оформления, учёта и хранения документов, связанных с трудовыми отношениями…»
Шаг третий: описываю сущности и их связи. Какие объекты существуют в предметной области, какие у них атрибуты, как они связаны друг с другом. Это помогает модели рассуждать структурированно, а не генерировать свободный текст.
Шаг четвёртый: задаю правила и ограничения. Что модель должна делать, чего не должна, где проходят границы компетенции. «Если вопрос касается не кадрового делопроизводства, а, например, налогового учёта, сообщи, что это выходит за рамки твоей компетенции.»
Шаг пятый: указываю формат ответа. Как именно модель должна структурировать ответ, какие разделы включать, на что ссылаться.
Такой промпт получается длинным — иногда две-три тысячи слов. Но он работает. Качество ответов возрастает кратно по сравнению с промптом в два-три предложения.
4.2. RAG-системы и сегментация знаний
Технология RAG — retrieval-augmented generation, генерация с дополненным поиском — стала стандартом для подключения внешних знаний к LLM. Принцип простой: когда пользователь задаёт вопрос, система ищет релевантные фрагменты в базе знаний и подставляет их в контекст модели вместе с вопросом. Модель генерирует ответ, опираясь на найденные фрагменты.
Проблема в том, как организована база знаний. Если документы нарезаны произвольно, если нет логической структуры, если термины не нормализованы, то поиск возвращает нерелевантные или противоречивые фрагменты, и модель генерирует некорректный ответ.
Здесь принципы Эванса работают напрямую:
Убиквитарный язык в RAG. Перед загрузкой документов в базу знаний нужно нормализовать терминологию. Если в одном документе объект называется «заказ», в другом — «заявка», в третьем — «обращение», нужно привести к единому термину или явно указать, что это разные объекты.
Ограниченные контексты в RAG. База знаний должна быть сегментирована по контекстам. Не одна большая куча документов, а тематические разделы, каждый со своим контекстом. Поиск должен учитывать контекст запроса.
Агрегаты в RAG. Документы должны быть сгруппированы в логические блоки. Не отдельные абзацы, а целостные смысловые единицы: статья закона со всеми частями и примечаниями, раздел регламента со всеми процедурами, описание процесса от начала до конца.
Антикоррупционный слой в RAG. Перед загрузкой в базу документы должны проходить проверку: актуальность, полнота, непротиворечивость, соответствие глоссарию.
4.3. Мультиагентные архитектуры как реализация ограниченных контекстов
В 2025–2026 годах мультиагентные системы перестали быть экзотикой и стали рабочим инструментом. Суть архитектуры: вместо одного «всезнающего» агента создаётся набор специализированных агентов, каждый из которых работает в своём ограниченном контексте. Координирующий агент, или маршрутизатор, определяет, к какому специалисту направить запрос.
Это прямая реализация стратегического проектирования Эванса. Каждый агент — это отдельный ограниченный контекст со своей моделью предметной области, своим глоссарием, своими правилами. Агенты не смешивают контексты. Если вопрос на стыке двух контекстов, координатор разбивает его на подзапросы и отправляет каждому агенту свою часть.
Я наблюдал, как такая архитектура решила проблему, которую не удавалось закрыть одним агентом. В страховой компании один агент обрабатывал вопросы по полисам, второй — по страховым случаям, третий — по нормативному регулированию. Каждый имел свою базу знаний, свой промпт, свой набор правил. Результат: точность ответов выросла, количество жалоб от пользователей снизилось.
4.4. Файнтюнинг и доменная адаптация
Дообучение модели на доменных данных — это ещё один способ передать модели знания предметной области. Но и здесь принципы Эванса помогают избежать типичных ошибок.
Главная ошибка при файнтюнинге: скармливать модели сырые документы без предварительной обработки. Модель учится на данных, и если данные противоречивы, если терминология непоследовательна, если в документах есть устаревшие нормы рядом с актуальными, модель выучит эту кашу и будет воспроизводить её в ответах.
Правильный подход через призму DDD:
— Нормализовать терминологию в обучающих данных. Убиквитарный язык.
— Разметить данные по ограниченным контекстам. Модель должна понимать, к какому контексту относится каждый пример.
— Проверить данные на непротиворечивость. Антикоррупционный слой.
— Включить в обучающие данные не только «что», но и «почему». Модель должна видеть не просто утверждения, но и логику, которая за ними стоит. Это элементы модели предметной области.
4.5. Оценка качества: как понять, что доменная адаптация сработала
Эванс в своей книге много пишет о том, что модель предметной области должна быть проверяемой. Нельзя построить модель и надеяться, что она работает. Нужно проверять её на реальных сценариях.
Для LLM-систем это означает необходимость доменного тестирования. Не общего бенчмарка, а тестов, составленных экспертами предметной области. Тестов, которые проверяют:
— Корректность использования терминов. Модель использует термины в соответствии с глоссарием.
— Понимание связей между сущностями. Модель правильно определяет, как объекты связаны друг с другом.
— Соблюдение правил и ограничений. Модель не выходит за рамки допустимого.
— Корректность в пограничных случаях. Модель справляется с нестандартными ситуациями, с исключениями, с конфликтами правил.
— Умение сказать «не знаю». Модель не выдумывает ответ, когда информация выходит за пределы её компетенции.
Я рекомендую формировать тестовый набор из ста — трёхсот вопросов, составленных экспертами предметной области, и прогонять модель через него после каждого изменения промпта, базы знаний или файнтюнинга. Это аналог модульного тестирования в разработке программного обеспечения, только для доменных знаний.
Часть 5. Типичные ошибки при внедрении доменных знаний в LLM-системы
За пару лет работы с LLM-проектами я выделил семь антипаттернов, которые встречаются снова и снова. Они прямо противоречат принципам Эванса, и каждый из них приводит к предсказуемо плохому результату.
Антипаттерн 1: «Модель сама разберётся»
Команда загружает в RAG-систему несколько тысяч документов, пишет промпт в три предложения и ожидает, что модель «поймёт» предметную область из контекста. Это не работает. Модель не обладает способностью извлекать структуру из хаоса. Ей нужно явно задать структуру: термины, связи, правила, границы.
Антипаттерн 2: Единый промпт на все случаи жизни
Попытка написать один универсальный системный промпт, который покрывает все задачи организации. «Ты — корпоративный ассистент компании. Помогай сотрудникам с любыми вопросами.» В результате модель не знает, в каком контексте она работает, путает термины из разных отделов, выдаёт общие ответы вместо конкретных. Эванс бы сказал: вы пытаетесь построить единую модель предметной области для всего бизнеса. Это невозможно.
Антипаттерн 3: Отсутствие глоссария
Документы в базе знаний написаны разными авторами в разное время. Терминология плавает. Один автор пишет «клиент», другой «заказчик», третий «потребитель». Модель не может определить, один ли это объект или три разных. Результат: путаница в ответах, галлюцинации, противоречия.
Антипаттерн 4: Игнорирование границ компетенции
Модели не объяснили, где проходит граница её знаний. Она отвечает на вопросы из смежных областей с той же уверенностью, что и на вопросы из своей. Пользователь не понимает, где ответ экспертный, а где модель импровизирует. Эванс решает это через ограниченные контексты: каждый контекст имеет чёткие границы.
Антипаттерн 5: Устаревшие данные без пометки
В базе знаний лежат документы разных лет. Нормативный акт 2019 года соседствует с его обновлённой редакцией 2025 года. Модель не знает, какой из них актуален, и может сослаться на устаревший. Антикоррупционный слой решает эту проблему: каждый документ получает метку актуальности, устаревшие документы либо удаляются, либо явно помечаются как недействующие.
Антипаттерн 6: Промпт без модели предметной области
Промпт описывает желаемый стиль ответа, но не описывает предметную область. «Отвечай профессионально, структурированно, используй маркированные списки.» Но не говорит, какие сущности существуют, как они связаны, какие правила действуют. Модель генерирует красиво оформленный текст, который может быть содержательно неверным.
Антипаттерн 7: Отсутствие обратной связи от экспертов
Систему построили, запустили, но эксперты предметной области не проверяют ответы. Нет цикла обратной связи. Ошибки накапливаются, пользователи теряют доверие. Эванс настаивает: модель предметной области — это живой документ, который нужно постоянно пересматривать и уточнять совместно с экспертами. Для LLM-систем это означает регулярный аудит ответов, обновление базы знаний, корректировку промптов.
Часть 6. Как выстроить предметную модель для ИИ-проекта: пошаговая методология
Этот раздел я построил как практическое руководство. Если вам нужно внедрить LLM в конкретной предметной области, вот последовательность действий, которая, по моему опыту, даёт наилучший результат.
Шаг 1. Определите ограниченный контекст
Ответьте на вопрос: какую конкретно задачу будет решать модель? Не «помогать бизнесу», а конкретно: анализировать договоры на предмет рисков, отвечать на вопросы сотрудников по кадровому учёту, помогать инженерам с подбором компонентов. Чем уже контекст, тем выше качество.
Запишите границы контекста: что входит, что не входит. Например: «Ассистент работает с вопросами по трудовому праву Российской Федерации. Вопросы по гражданско-правовым договорам, по налоговому праву, по уголовному праву не входят в контекст.»
Шаг 2. Проведите интервью с экспертами предметной области
Это самый важный и самый недооценённый шаг. Поговорите с людьми, которые работают в этой области каждый день. Не с руководителями, а с практиками. Задайте вопросы:
— Какие ключевые термины вы используете? Что каждый из них означает?
— Какие объекты и сущности существуют в вашей работе? Какие у них атрибуты?
— Как эти объекты связаны друг с другом?
— Какие процессы и процедуры вы выполняете? В какой последовательности?
— Какие правила и ограничения действуют? Какие исключения бывают?
— Какие типичные ошибки совершают новички? Где чаще всего путаются?
— Какие вопросы вам задают чаще всего?
Запишите всё. Не фильтруйте на этапе записи. Фильтровать будете позже.
Шаг 3. Составьте глоссарий
На основе интервью и документов составьте глоссарий предметной области. Каждый термин — одно чёткое определение. Если есть близкие термины, которые можно перепутать, явно укажите различие. Глоссарий должен быть согласован с экспертами. Не с одним — с двумя-тремя, чтобы убедиться, что определения не отражают мнение одного человека/эксперта.
Шаг 4. Нарисуйте модель предметной области
Схематично изобразите ключевые сущности, их атрибуты и связи между ними. Не обязательно использовать формальный UML. Достаточно понятной диаграммы, которая показывает: вот эти объекты существуют, вот так они связаны, вот такие правила действуют. Эта диаграмма станет основой для системного промпта и для организации базы знаний.
Шаг 5. Определите правила и ограничения
Запишите явные и неявные правила предметной области. Явные — те, что записаны в нормативных документах, регламентах, стандартах. Неявные — те, что существуют в практике, но нигде не зафиксированы. Например: «В нашей компании при оформлении отпуска без сохранения заработной платы более чем на четырнадцать дней требуется согласование с непосредственным руководителем и с руководителем подразделения.» Этого может не быть в Трудовом кодексе, но это правило действует в конкретной организации и описано в регламентах бизнес процесса компании.
Шаг 6. Спроектируйте системный промпт
На основе глоссария, модели и правил напишите системный промпт. Структура промпта:
— Роль и контекст: кто модель, в какой области работает.
— Глоссарий: ключевые термины и определения.
— Модель предметной области: сущности, связи, процессы.
— Правила и ограничения: что модель должна и не должна делать.
— Границы компетенции: что делать, если вопрос выходит за рамки.
— Формат ответа: как структурировать ответ, на что ссылаться.
— Примеры: два-три примера корректного ответа на типичные вопросы.
Шаг 7. Организуйте базу знаний
Если используете RAG, организуйте документы по принципам, описанным выше: сегментация по контекстам, группировка в агрегаты, нормализация терминологии, проверка актуальности. Каждый документ должен быть проиндексирован с указанием контекста, даты актуальности и типа информации.
Шаг 8. Протестируйте на реальных сценариях
Составьте набор тестовых вопросов. Включите простые вопросы, сложные вопросы, пограничные случаи, вопросы на стыке контекстов, вопросы, на которые модель должна ответить «не знаю». Прогоните модель через этот набор. Привлеките экспертов для оценки ответов. Зафиксируйте ошибки.
Шаг 9. Итерируйте
Исправьте промпт, обновите базу знаний, уточните глоссарий. Прогоните тесты снова. Повторяйте до тех пор, пока качество не станет приемлемым. Эванс называет это итеративным уточнением модели предметной области. Модель никогда не бывает идеальной с первого раза. Она уточняется в процессе работы.
Шаг 10. Запустите цикл обратной связи
После запуска системы организуйте сбор обратной связи. Пользователи должны иметь возможность отметить некорректный ответ. Эксперты должны регулярно просматривать выборку ответов. База знаний должна обновляться. Глоссарий должен пересматриваться. Модель предметной области — живой организм.
Часть 7. Малоизвестные факты и неочевидные наблюдения
В этом разделе я собрал несколько фактов и наблюдений, которые редко всплывают в публичных обсуждениях, но которые, на мой взгляд, важны для понимания связи между предметным моделированием и LLM.
Факт первый. Термин «предметно-ориентированное проектирование» в русскоязычной практике часто переводят и используют в контексте разработки программного обеспечения. Но Эванс в интервью и на конференциях неоднократно подчёркивал, что DDD — это не про код. Это про коммуникацию между людьми, которые понимают бизнес, и людьми, которые строят систему. Код — лишь побочный продукт этой коммуникации. В контексте LLM это означает: промпт и база знаний — это побочный продукт коммуникации между экспертом предметной области и инженером, который настраивает модель. Если коммуникация не состоялась, промпт будет пустым.
Факт второй. Концепция языка Эванса имеет глубокий когнитивный корень. Исследования в области лингвистической относительности, в частности работы, восходящие к гипотезе Сепира — Уорфа, показывают, что язык, на котором мы формулируем задачу, влияет на то, как мы её решаем. Для LLM это не метафора, а техническая реальность: выбор конкретных слов в промпте активирует разные паттерны в весах модели. Разные слова для одного и того же понятия могут давать существенно разные результаты. Это не просто «стилистический выбор». Это выбор, который определяет, какие знания модель извлечёт из своих параметров.
Факт третий. Книга Эванса содержит раздел, который часто пропускают: обсуждение того, когда DDD не нужен. Эванс прямо пишет, что для простых систем, для типовых задач, для задач без сложной бизнес-логики предметно-ориентированное проектирование избыточно. Это важно и для LLM: не каждой задаче нужна глубокая доменная адаптация. Если задача тривиальна, достаточно общей модели с минимальным промптом. Стратегическое проектирование по Эвансу — это в том числе умение сказать: «Здесь предметное моделирование не требуется.»
Факт четвёртый. В 2024 году несколько крупных проектов по внедрению корпоративных ИИ-ассистентов были приостановлены не из-за технических проблем с моделью, а из-за того, что внутри организации не удалось согласовать единую терминологию. Разные департаменты использовали разные термины для одних и тех же объектов, и ни один департамент не хотел уступать. Модель не могла работать в условиях терминологического хаоса. Это прямое подтверждение тезиса Эванса: убиквитарный язык — это не техническое требование, а организационное. И он часто оказывается самым сложным элементом проекта.
Факт пятый. Эванс в своей книге рекомендует для моделирования предметной области использовать не только текст и диаграммы, но и «глубокие метафоры» — аналогии, которые помогают команде интуитивно понять структуру области. В контексте LLM этот приём тоже работает. Когда я объясняю модели предметную область через метафору, качество ответов часто улучшается. Например, для логистической системы метафора «конвейер», где каждый этап — это стадия обработки груза, помогает модели лучше понимать последовательность и зависимости между этапами, чем сухое перечисление процедур. Это не магия. Это способ активировать в модели более структурированные паттерны рассуждения.
Часть 8. Чек-лист: предметная область для вашего LLM-проекта
Используйте этот список как рабочую шпаргалку. Каждый пункт — конкретное действие.
Подготовка:
Определён ограниченный контекст: чётко записано, что входит в область, а что нет.
Проведены интервью минимум с двумя экспертами предметной области.
Записаны ключевые термины, определения, связи, правила, исключения.
Глоссарий:
Составлен глоссарий с однозначными определениями каждого термина.
Близкие термины явно разведены с указанием различий.
Глоссарий согласован с экспертами.
Модель предметной области:
Определены ключевые сущности и их атрибуты.
Описаны связи между сущностями.
Зафиксированы процессы и последовательности действий.
Определены правила, ограничения и исключения.
Указаны границы: что модель знает и чего не знает.
Системный промпт:
Промпт содержит описание роли и контекста.
Промпт включает глоссарий или ссылку на него.
Промпт описывает модель предметной области.
Промпт задаёт правила и ограничения.
Промпт указывает, что делать при выходе за границы компетенции.
Промпт задаёт формат ответа.
Промпт содержит два-три примера корректного ответа.
База знаний (если используется RAG):
Документы сегментированы по контекстам.
Терминология нормализована.
Документы сгруппированы в логические блоки-агрегаты.
Проверена актуальность каждого документа.
Устаревшие документы помечены или удалены.
Настроен антикоррупционный слой: валидация данных перед загрузкой.
Тестирование:
Составлен набор из ста и более тестовых вопросов.
Включены простые, сложные и пограничные случаи.
Включены вопросы, на которые модель должна ответить «не знаю».
Тесты проверены экспертами предметной области.
Проведено тестирование, зафиксированы ошибки.
Эксплуатация:
Настроен сбор обратной связи от пользователей.
Определён цикл пересмотра базы знаний и промптов.
Назначен ответственный за актуализацию предметной модели.
Эксперты регулярно просматривают выборку ответов.
Часть 9. FAQ: десять вопросов и прямых ответов
Вопрос 1. Нужно ли понимать предметную область, чтобы просто пользоваться LLM для бытовых задач?
Нет. Для бытовых задач — написать письмо, перевести текст, придумать идею — достаточно общей модели без доменной настройки. Предметная область становится критичной, когда вы используете LLM для профессиональных задач, где точность терминологии и корректность фактов важны.
Вопрос 2. Книга Эванса написана для программистов. Мне, не программисту, она будет полезна?
Да. Эванс пишет не только о коде. Значительная часть книги посвящена коммуникации, моделированию, работе с экспертами предметной области. Эти разделы полезны аналитикам, продуктовому менеджерам, руководителям проектов, всем, кто участвует в постановке задач для ИИ-систем. Программистские разделы можно пропустить.
Вопрос 3. Если я напишу длинный и подробный системный промпт, этого достаточно для доменной адаптации?
Нет. Промпт — это один из инструментов. Для серьёзных задач нужна также база знаний, глоссарий, тестирование, цикл обратной связи. Промпт задаёт рамки, но не может вместить все знания предметной области. RAG-система, файнтюнинг, мультиагентная архитектура — это дополнительные инструменты, которые дополняют промпт.
Вопрос 4. Как понять, что модель «не понимает» предметную область?
Признаки: модель путает термины, которые в данной области различаются; генерирует ответы, которые звучат профессионально, но содержат фактические ошибки; не видит связей между объектами; не знает правил и ограничений; не может сказать «не знаю» и выдумывает ответ. Если вы видите хотя бы два из этих признаков, доменная адаптация недостаточна.
Вопрос 5. Можно ли обойтись без экспертов предметной области при настройке LLM?
Технически можно, но результат будет некорректным. Эксперты нужны для составления глоссария, для определения правил и ограничений, для проверки ответов. Без эксперта вы будете полагаться на общие знания модели, которые в узкой области часто недостаточны или неверны или имеют разнонаправленное толкование.
Вопрос 6. Сколько времени занимает построение предметной модели для LLM-проекта?
Зависит от сложности области. Для узкой задачи в рамках одного отдела — от двух недель до месяца. Для сложного домена с множеством подпроцессов — от двух до шести месяцев. И это не разовое действие, а непрерывный процесс уточнения, обратная связь желательна и она приводит к постоянному улучшению и эволюции работы модели.
Вопрос 7. Актуальна ли книга Эванса в 2026 году, или есть более современные работы?
Книга Эванса остаётся фундаментальной работой по предметному моделированию. Появились дополнительные работы, которые развивают и дополняют его идеи: например, книга Вона Вернона Implementing Domain-Driven Design 2013 года, которая переводит идеи Эванса в более практическую плоскость. Книга Скотта Власина, Матье Хёса и других авторов по проектированию доменных моделей также полезна. Но именно Эванс заложил концептуальный фундамент, и его идеи не устарели.
Вопрос 8. Применяются ли принципы DDD к мультимодальным моделям, которые работают с изображениями, звуком, видео?
Да, и даже в большей степени. Мультимодальные модели ещё сильнее зависят от контекста. Когда модель анализирует медицинское изображение, ей нужно понимать, что именно она ищет, какие структуры на снимке значимы, какие нормы существуют. Это чистая предметная область. Без доменного контекста мультимодальная модель будет «видеть» пиксели, но не будет «понимать», что на них изображено в профессиональном смысле.
Вопрос 9. Может ли LLM сама помочь в построении предметной модели?
Частично да. Модель может помочь структурировать информацию, предложить варианты глоссария, набросать черновик модели. Но финальную валидацию должен делать эксперт предметной области. Модель не может сама определить, какие правила действуют в конкретной организации, какие термины используются в конкретной профессиональной среде, какие исключения существуют в конкретной практике. Это знания, которые находились вне обучающего корпуса модели.
Вопрос 10. Что делать, если предметная область быстро меняется, например в регулировании или в технологиях?
Заложить в архитектуру системы механизм обновления. База знаний должна обновляться регулярно. Глоссарий должен пересматриваться при каждом изменении нормативной базы. Промпт должен содержать указание на дату актуальности знаний. И главное: должен быть назначен ответственный за актуализацию предметной модели. Эванс пишет, что модель предметной области — это не артефакт, а процесс. Для быстро меняющихся областей этот процесс должен быть непрерывным.
Часть 10. Сильные и слабые стороны разных подходов к доменной адаптации
Поскольку тема допускает дискуссии, приведу честное сравнение основных подходов к передаче предметных знаний языковой модели. У каждого есть сильные стороны и ограничения.
Подход 1: Только системный промпт
Сильные стороны. Быстро внедряется. Не требует инфраструктуры. Легко корректировать. Подходит для узких задач с ограниченным набором правил.
Слабые стороны. Ограничен объёмом контекстного окна. Не подходит для областей с большим объёмом знаний. Не масштабируется. При изменении правил нужно каждый раз переписывать промпт вручную или создать пул шаблонов и уже из них выбирать необходимый в зависимости от контекста.
Когда использовать. Небольшие проекты, узкие задачи, прототипирование, когда нужно быстро проверить гипотезу.
Подход 2: RAG с базой знаний
Сильные стороны. Масштабируется на большие объёмы документов. Позволяет обновлять знания без переобучения модели. Поддерживает ссылку на источники.
Слабые стороны. Качество зависит от организации базы знаний. Требует инфраструктуры для хранения, индексации и поиска. Плохо работает, если документы не структурированы по принципам предметной модели. Не передаёт модели правила и ограничения, которые не записаны в документах.
Когда использовать. Средние и крупные проекты, где объём знаний превышает возможности контекстного окна. Когда знания часто обновляются.
Подход 3: Файнтюнинг на доменных данных
Сильные стороны. Модель глубоко усваивает доменную специфику. Не нужно каждый раз передавать контекст. Работает быстрее, чем RAG, потому что не требует поиска.
Слабые стороны. Дорого и долго. Требует большого объёма качественных размеченных данных. Сложно обновить знания: нужно переобучать модель. Риск «запоминания» некорректных данных. Не подходит для быстро меняющихся областей.
Когда использовать. Стабильные предметные области с большим объёмом данных. Когда скорость ответа критична. Когда бюджет позволяет.
Подход 4: Мультиагентная система
Сильные стороны. Каждый агент работает в своём контексте. Чёткое разделение ответственности. Масштабируется на сложные организации с множеством доменов.
Слабые стороны. Сложная архитектура. Требует координации между агентами. Дороже в разработке и эксплуатации. Растёт число точек отказа.
Когда использовать. Крупные организации с множеством предметных областей. Задачи, где один контекст не покрывает все потребности. Когда нужна высокая точность в каждом домене.
Подход 5: Комбинированный
Сильные стороны. Берёт лучшее из каждого подхода. Системный промпт задаёт контекст и правила. RAG обеспечивает доступ к актуальным знаниям. Файнтюнинг углубляет понимание домена. Мультиагентная архитектура разделяет контексты.
Слабые стороны. Максимальная сложность. Требует зрелой инженерной команды. Дорого.
Когда использовать. Критичные проекты, где ошибка модели недопустима: медицина, авиация, финансы, юриспруденция.
Ни один подход не является универсально лучшим. Выбор зависит от задачи, бюджета, сроков и критичности ошибок. Но во всех случаях фундамент один: предметная модель, глоссарий, правила, границы. Без них не работает ни один подход.
Часть 11. Что изменилось к 2026 году и почему книга Эванса стала ещё актуальнее
Три года назад, в 2023 году, мир переживал первую волну массового внедрения LLM. Компании торопились «прикрутить» чат-бота к своим продуктам, как и я лично на этом своем сайте прикрутил модного чат бота. Подход был простым: взять готовую модель, написать короткий промпт, запустить. Это работало для демо и для маркетинговых презентаций. Но не работало в реальной эксплуатации.
К 2026 году ситуация изменилась. Рынок повзрослел. Пользователи перестали восхищаться тем, что модель «вообще отвечает». Им нужен точный, корректный, надёжный ответ в конкретной профессиональной задаче. И тут выяснилось, что без предметного моделирования не обойтись.
Параллельно произошло несколько технологических сдвигов:
Контекстные окна моделей выросли до миллиона токенов. Это не решило проблему доменного понимания, но изменило подход к организации контекста. Теперь можно загружать в контекст целые агрегаты знаний, а не отдельные фрагменты. Принцип агрегата Эванса стал ещё более практичным.
Мультиагентные фреймворки стали зрелыми и доступными. То, что в 2024 году было исследовательским прототипом, в 2026 году стало стандартным инструментом. Ограниченные контексты Эванса получили технологическую реализацию.
Инструменты для построения RAG-систем стали более гибкими. Появились возможности для семантической сегментации документов, для учёта контекста при поиске, для версионирования базы знаний. Это позволяет реализовать принципы убиквитарного языка и антикоррупционного слоя на уровне инфраструктуры.
Регуляторное давление усилилось. В ряде отраслей — медицина, финансы, юриспруденция — использование ИИ без доменного контроля становится не просто нежелательным, а юридически рискованным. Предметная модель становится не только инструментом качества, но и инструментом комплаенса.
Всё это делает идеи Эванса не просто актуальными, а необходимыми. Книга 2003 года стала тем, чем она и должна была стать: методологическим фундаментом для работы со сложными системами. Просто теперь «сложная система» — это не корпоративная ERP, а LLM-ассистент, который принимает решения, влияющие на жизнь людей.
Часть 12. Неочевидная связь: DDD и проблема «выравнивания» ИИ
Есть ещё один аспект, который редко обсуждают в контексте DDD и LLM, но который, на мой взгляд, заслуживает внимания.
Проблема выравнивания, или alignment, — это задача сделать так, чтобы поведение ИИ-системы соответствовало намерениям и ценностям людей, которые её используют. Обычно эту проблему обсуждают в философском или этическом ключе. Но на практике выравнивание в корпоративных системах — это в значительной степени задача предметного моделирования.
Когда мы говорим модели: «Ты работаешь в контексте кадрового учёта, следуешь Трудовому кодексу, не выходишь за границы компетенции, не даёшь рекомендаций по вопросам, не относящимся к кадрам», — мы занимаемся выравниванием. Мы задаём модели рамки поведения, которые соответствуют ценностям и правилам конкретной организации.
Эванс в своей книге много пишет о том, что модель предметной области — это не только технический артефакт, но и социальный контракт. Команда договаривается о том, как она понимает бизнес, и фиксирует это понимание в модели. Для LLM-систем этот социальный контракт приобретает особое значение: мы договариваемся с моделью о том, как она должна себя вести в рамках конкретного контекста. И этот договор должен быть явным, записанным, проверяемым.
Без такого договора модель ведёт себя непредсказуемо. Она не «злонамеренна» и в принципе она вообще не умеет думать. Она просто не знает правил. И это, пожалуй, самая точная аналогия между DDD и LLM: и там и там главная проблема — не в технологии, а в том, что правила не были явно сформулированы и доведены до исполнителя.
Часть 13. Практический разбор: как я применяю принципы Эванса в конкретном проекте
Чтобы не оставаться на уровне абстракций, расскажу обобщённый пример из практики.
Задача: построить ИИ-ассистента для отдела закупок производственной компании. Ассистент должен отвечать на вопросы сотрудников по процедурам закупок, помогать заполнять заявки, подсказывать, какие документы нужны для конкретных видов закупок, ориентировать в нормативных требованиях.
Что было сделано.
Первым делом я провёл три интервью с ведущими специалистами отдела закупок. Записал всё: термины, процедуры, исключения, типичные ошибки. Выяснилось, что в компании используется собственная терминология, которая отличается от общепринятой. Например, то, что в законе называется «конкурсная процедура», внутри компании называется «тендерный комитет». А «запрос котировок» внутри компании называется «быстрая закупка».
На основе интервью я составил глоссарий из сорока трёх терминов. Для каждого термина — определение, синонимы, которые используются внутри компании, и явное указание, чем этот термин отличается от близких терминов.
Затем я нарисовал модель предметной области. Ключевые сущности: потребность, заявка на закупку, лот, поставщик, договор, спецификация, акт приёмки. Связи между ними. Процессы: от возникновения потребности до закрытия договора. Правила: пороги сумм, при которых меняются процедуры; перечень документов для каждого типа закупки; сроки согласования.
Определил ограниченный контекст: ассистент работает только с внутренними процедурами закупок данной компании. Вопросы по гражданскому праву, по налогообложению, по трудовым отношениям не входят в контекст. Вопросы по закупкам других компаний тоже не входят, даже если они регулируются тем же законом.
Написал системный промпт объёмом около тысячи восьмисот слов. Включил в него глоссарий, описание сущностей и связей, ключевые правила, границы компетенции, формат ответа. Добавил три примера: простой вопрос, сложный вопрос с исключением, вопрос, выходящий за границы контекста.
Организовал базу знаний для RAG. Внутренние регламенты закупок, шаблоны документов, нормативные акты, на которые ссылаются регламенты. Сегментировал по типам закупок. Нормализовал терминологию. Пометил устаревшие редакции.
Составил тестовый набор из ста двадцати вопросов. Прогнал модель. Эксперты отдела закупок оценили ответы. Выявили одиннадцать ошибок. Исправил промпт и базу знаний. Прогнал снова. Осталось три ошибки в пограничных случаях. Доработал. Запустил.
Результат: через месяц после запуска ассистент обрабатывал около сорока процентов типовых вопросов, которые раньше сотрудники задавали живым коллегам. Время на рутинные консультации сократилось. При этом эксперты отметили, что качество ответов ассистента по внутренним процедурам выше, чем у новых сотрудников, потому что ассистент не путается в терминах и не забывает про исключения.
Этот проект занял примерно шесть недель от первого интервью до запуска. Без предметного моделирования, по оценкам команды, он занял бы вдвое больше времени и дал бы вдвое худший результат.
Часть 14. Что почитать по теме: авторитетные работы
Помимо книги Эрика Эванса Domain-Driven Design: Tackling Complexity in the Heart of Software 2003 года, которую я рекомендую как отправную точку, есть несколько работ, заслуживающих внимания.
Вон Вернон, Implementing Domain-Driven Design, 2013 год. Практическое руководство по применению идей Эванса. Более прикладное, более современное, с примерами на конкретных технологиях. Если книга Эванса — это «зачем и что», то книга Вернона — это «как именно».
Скотт Власин, Матьё Хёс и соавторы, Domain Modeling Made Functional, 2018 год. Интересный взгляд на предметное моделирование через призму функционального программирования. Полезна для тех, кто хочет увидеть альтернативный способ структурирования доменных знаний.
В контексте LLM и предметного моделирования полезны работы по промпт-инжинирингу и по проектированию RAG-систем, которые появились в 2024–2026 годах. Конкретные названия быстро устаревают, поэтому я рекомендую ориентироваться на материалы профильных конференций по инженерии машинного обучения и по обработке естественного языка, где эти темы обсуждаются с практической точки зрения.
Также стоит обратить внимание на работы по онтологическому инжинирингу и по управлению знаниями в организациях. Эти дисциплины старше, чем LLM, но содержат огромный опыт структурирования предметных знаний, который напрямую применим к задаче доменной адаптации ИИ.
Часть 15. Роль предметного эксперта в эпоху ИИ
Отдельно хочу сказать о роли эксперта предметной области. В 2026 году, когда ИИ-системы проникают во все отрасли, роль эксперта не уменьшается. Она трансформируется.
Раньше эксперт был нужен для того, чтобы выполнять работу: ставить диагнозы, составлять договоры, рассчитывать конструкции. Теперь часть этой работы берёт на себя ИИ. Но эксперт нужен для того, чтобы объяснить ИИ, как эта работа устроена и контролировать результат. Чтобы составить глоссарий. Чтобы определить правила. Чтобы проверить ответы. Чтобы обновить знания, когда нормативная база меняется.
Это означает, что предметный эксперт становится своего рода «учителем» для ИИ-системы. Его знания, которые раньше существовали в голове и передавались устно от наставника к ученику, теперь нужно фиксировать в явном виде: в глоссариях, в моделях, в правилах, в примерах. Это непривычно. Многие эксперты сопротивляются, потому что их знания в значительной степени неявные, интуитивные, основанные на опыте. Формализовать их — это отдельная работа.
Но именно эта работа определяет качество ИИ-системы. Не размер модели. Не объём обучающих данных. А то, насколько точно и полно эксперт смог передать свои знания предметной области в формате, который модель способна усвоить.
Эванс в своей книге описывает этот процесс как «совместное моделирование»: разработчик и эксперт предметной области сидят вместе и строят модель. Для LLM-проектов это совместное моделирование становится центральным процессом. Инженер, который настраивает модель, и эксперт, который знает предметную область, должны работать в тесном контакте. Без этого контакта результат будет поверхностным.
Вывод: три конкретных шага
Подведу итог. Понимание предметной области — это не дополнение к работе с LLM. Это фундамент. Без него любая, даже самая мощная языковая модель остаётся генератором гладких, уверенных и потенциально опасных ошибок.
Книга Эрика Эванса Domain-Driven Design, написанная в 2003 году, содержит концептуальный аппарат, который идеально ложится на задачу доменной адаптации LLM. Убиквитарный язык, ограниченные контексты, модель предметной области, агрегаты, сущности и объекты-значения, антикоррупционный слой, стратегическое проектирование — все эти концепции работают не как метафоры, а как практические инструменты.
Если вы хотите улучшить качество своей LLM-системы, вот три шага, которые я рекомендую сделать прямо сейчас.
Первый шаг. Возьмите лист бумаги или откройте пустой документ. Напишите название предметной области, в которой работает ваша модель. Под ним запишите десять ключевых терминов этой области и дайте каждому одно чёткое определение. Если не можете дать определение — это сигнал, что вы сами не до конца понимаете область, и нужно идти к эксперту.
Второй шаг. Напишите три предложения, которые описывают границы компетенции вашей модели. Что она знает. Чего она не знает. Что она должна делать, когда вопрос выходит за границы. Включите эти три предложения в системный промпт.
Третий шаг. Составьте двадцать вопросов, на которые ваша модель должна отвечать корректно, и десять вопросов, на которые она должна сказать «не знаю». Прогоните модель через этот набор. Посмотрите, где она ошибается. Это покажет вам, какие элементы предметной модели нужно доработать.
Эти три шага не требуют больших ресурсов. Но они закладывают тот фундамент, без которого всё остальное — файнтюнинг, RAG, мультиагентные архитектуры — будет строиться на песке.
Предметная область — это то место, где заканчивается магия ИИ и начинается инженерия. И Эрик Эванс дал нам для этой инженерии лучший инструмент из всех, что существуют. Надо только им воспользоваться.
Добавить комментарий