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

Однако быстро стало ясно: построить карту один раз — недостаточно.

Компания постоянно меняется. Меняются процессы, документы, код, настройки, роли, рабочие привычки. То, что раньше было правильным маршрутом к ответу, со временем может вести к неполной или вовсе ложной информации. Это особенно опасно: если у компании нет карты, она честно признаёт, что ответа нет. Но если карта устарела, она уверенно даёт неверный ответ — и в это легче поверить.

Меня зовут Денис Селезнёв, я генеральный директор «Первой Формы». В этой статье — о том, как не допустить, чтобы карта превратилась в красивый, но мёртвый артефакт.

Почему карта начинает врать

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

На деле карта устаревает сразу по нескольким направлениям.

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

Во-вторых, меняются данные и их источники. Ответ на управленческий вопрос редко живёт в одной системе. Часть сигнала — в CRM, часть — в проектах, часть — в документах, часть — в истории задач. Появляются новые отчёты, справочники, категории, интеграции. Карта должна это учитывать.

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

В-четвёртых, меняется язык компании. Появляются новые инструменты с собственной терминологией, приходят новые контрагенты с новыми формулировками. Пока карта знает эти соответствия, она помогает. Когда перестаёт — начинает путать сущности или терять маршруты.

К чему приводит устаревание корпоративной карты

Устаревание почти никогда не проявляется как громкая авария. Оно происходит тихо — и в этом главный риск. Вот к чему это ведёт:

• Растёт число ошибок. Система опирается на связи, которые уже не соответствуют реальности: изменились роли, процессы, код, документы, договорённости. Пользователь получает не пустой ответ, а правдоподобный, но неверный. Это самый опасный тип ошибки — он выглядит убедительно.
• Появляются финансовые риски. Ошибки в маршрутах к данным, документам или правилам влияют на сроки, качество решений, работу с клиентами, согласования и стоимость операций. В сложной среде каждая неточность обходится дороже.
• Сотрудники тратят больше ресурсов на перепроверку. Если навигатор требует ручной валидации, обещание ускорения теряется. Люди снова открывают системы, сверяют документы, уточняют у коллег. Инструмент есть, но выгода съедается постоянной подстраховкой.
• Снижается доверие к системе. Даже сильный инструмент теряет ценность, если пользователь сталкивается с уверенным, но неполным ответом. Люди либо возвращаются к ручному поиску, либо используют навигатор только как подсказку. В корпоративной среде это критично: недоверие убивает эффект.
• ИИ начинает создавать дополнительную работу. Вместо сокращения пути система удлиняет его: даёт версию ответа, требует проверки, заставляет искать подтверждение вручную. Проблема уже не в модели и не в интерфейсе — а в том, что навигационная основа не соответствует живой среде.

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

Опыт «Первой Формы»: как мы обновляем карту для стабильной работы

Первый контур: автоматическое обновление из цифрового следа

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

У нас таких сигналов несколько.

1. Структурные изменения конфигурации. «Первая Форма» — конфигурируемая платформа. У каждой площадки своя структура: категории, параметры, связи, маршруты, отчёты. Если карта не подтягивает эти изменения, она стареет сразу после настройки. Поэтому у нас есть механизм автоматической генерации документации по конфигурации. Из живой структуры собираются слои карты: сущности, процессы, аналитика, автоматизации, интеграции, связи, типовые вопросы и навигаторы.

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

1. Цифровой след рабочих вопросов. Мы заметили, что знания о предметной области живут не в регламентах, а в вопросах, которые люди задают друг другу. Если сотрудники регулярно спрашивают об одном и том же — это либо важный маршрут, либо пробел в карте. Поэтому у нас есть слой анализа Q&A-потока: система отслеживает, какие вопросы повторяются, на что есть устойчивые ответы, а где навигация слаба или отсутствует.

Этот поток фиксирует не абстрактную онтологию, а живую потребность: не «что может существовать», а «что реально заставляет искать помощь».

1. Автоматический контур через инвентаризацию карт и коробок. Когда предметных областей много, карта не может быть единым монолитом. Мы описываем их коробками и слоями: сущности, процессы, аналитика, автоматизации, маршруты. Это делает обновление управляемым — можно пересобрать не всю карту, а только нужный фрагмент.

Ещё один элемент — маршрутизация по слоям. Мы не хотим, чтобы каждый вопрос уходил в семантический поиск по всему массиву. Сначала система ищет надёжный и дешёвый путь: нормативная база, готовый дашборд, документация, структурированный поиск. Только потом — более свободные формы поиска.

Это не просто вопрос производительности, а защита от семантического размывания. Если ответ уже существует в виде визуализации или формализованного маршрута, системе не нужно «осознавать» всё поле целиком.

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

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

Автоматический контур хорошо собирает факты изменений. Но он не понимает смысла. Он не отвечает на вопрос: соответствует ли обновлённая карта реальной логике работы.

Автоматическое обновление может сделать карту богаче, но не обязательно лучше.

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

Второй контур: экспертная проверка смысла

Если первый контур отвечает на вопрос «Что изменилось?», то второй — на вопрос «Что это значит для карты? Как теперь должна выглядеть правильная навигация?».

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

Экспертная валидация нужна как минимум в четырёх случаях:

1. Когда нужно подтвердить маршрут. Автоматика может показать, что вопрос часто возникает. Но только эксперт знает, какой путь считается правильным. Например, вопрос о просадке воронки может вести в CRM, в отчёты по активности или в обсуждение сделки. Только эксперт определит, куда вести пользователя.

1. Когда нужно разрешить терминологию. Для машины совпадение терминов — задача сопоставления. Для человека — ещё и контекст. Слово «БА» в одной команде означает бизнес-аналитика, в другой — что-то другое. Без валидации карта начнёт уверенно вести не туда.

1. Когда нужно отделить устойчивую практику от временного шума. В компании всегда есть локальные обходные сценарии, ручные исключения, временные костыли. Если переносить всё это в карту, она начнёт описывать не нормальную навигацию, а коллекцию отклонений.

1. Когда нужно зафиксировать пробел. Иногда правильное решение — не добавить маршрут, а честно признать, что карта не покрывает потребность. Это важно: пробел можно поставить в очередь, документировать, разобрать, закрыть. Гораздо хуже, когда карта делает вид, что знает ответ, хотя знание не оформлено.

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

Для нас это особенно важно. Мы исходим из того, что полезный ИИ возникает не сам по себе, а внутри рабочей архитектуры: с ясными процессами, понятными ролями, маршрутами и ответственностью. Поэтому экспертная валидация — не «ручной довесок», а обязательная часть системы.

Как устроены два контура обновления: техническая механика

Чтобы двойной контур не выглядел абстракцией, расскажем, как он работает у нас — на уровне пайплайнов, инструментов и процедур.

Техническое устройство первого контура

Первый контур опирается на три источника сигналов, у каждого — свой пайплайн.

1. Конфигурация площадки и инструмент extract-config

«Первая Форма» — конфигурируемая платформа. У каждой площадки своя структура. Если карта не подтягивает изменения, она стареет сразу после настройки.

Мы создали инструмент extract-config. Он подключается к живой площадке через API, забирает снимок конфигурации и сохраняет его в единый нормализованный raw JSON. Из одной площадки — сотни категорий и тысячи параметров.

Дальше включается автоматический классификатор. Он раскладывает конфигурацию по предметным областям, используя словарь из 25 доменов — от CRM и проектного управления до HR и финансов. Каждый раздел попадает в одну из трёх корзин: бизнес-процесс, системная инфраструктура или нераспознанное.

В последнюю группу попадают:

• Локальные или кастомные разделы с неочевидным назначением.
• Технически бедно описанные разделы: мало связей, маршрутов, данных об использовании.
• Смешанные случаи: где в одном разделе перепутаны признаки процесса и инфраструктуры.
• Временные, экспериментальные, устаревающие или полузаброшенные разделы с противоречивым следом.

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

Бизнес-разделы группируются в коробки — замкнутые предметные области с фиксированной структурой знаний. Для каждой коробки запускается семь универсальных генераторов, каждый создаёт свой слой описания:

1. Сущности и параметры: какие объекты существуют и как связаны.
2. Процессы и маршруты: по каким шагам и состояниям движется работа.
3. Аналитика: какие дашборды, отчёты и порталы уже собраны.
4. Автоматизации: какие правила и скрипты срабатывают без участия человека.
5. Связи между коробками: где одна область ссылается на другую.
6. Интеграции: какие внешние системы подключены и как обмениваются данными.
7. Типовые вопросы с маршрутами к ответам: какие вопросы задают и где искать ответ.

Все генераторы универсальны — они не знают специфики области и работают с любым набором категорий. Это принципиально: мы не описываем каждую область вручную, а даём системе механизм, который умеет описывать любую. На десятках клиентских площадок таким образом описаны сотни коробок с покрытием более 99% параметров.

2. Цифровой след рабочих вопросов и пайплайн QA Mining

Второй источник — вопросы, которые люди задают в задачах. В «Первой Форме» вопрос в комментариях можно пометить как требующий ответа. Система фиксирует: кто спросил, кого, когда был ответ, была ли дискуссия. За год — десятки тысяч таких пар, почти все получают ответ.

Мы собрали контур анализа Q&A-потока, который последовательно выделяет сигналы, оценивает, классифицирует и передаёт на валидацию.

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

Второй этап — скоринг. Каждой паре присваивается оценка по длине ответа, типу вопроса, глубине обсуждения. Самые ценные — вопросы вида «как настроить», «можно ли», «почему так работает». Это не уточнения, а запросы на знание: конфигурационные рецепты, границы возможностей, архитектурные объяснения.

Третий этап — классификация. Каждая пара раскладывается по предметным областям и типам знания: конфигурационный рецепт, бизнес-правило, инструкция, ограничение платформы. Это позволяет понять, какое знание люди ищут.

Четвёртый этап — валидация. Мы сопоставляем найденные вопросы с существующей документацией. На своём примере обнаружили, что около 40% вопросов уже покрыты картой — проблема была не в отсутствии контента, а в том, что люди не находили к нему дорогу. Без этого этапа мы бы создавали дубли вместо улучшения маршрутизации.

Инвентаризация и маршрутизация — как карта организует себя

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

• Слой 0 — нормативная база: регламенты, политики, SLA. Если ответ зафиксирован как правило — искать дальше не нужно.
• Слой 1 — готовые визуализации: дашборды и отчёты, где ответ уже собран.
• Слой 2 — документация, в которой ответ есть, но его нужно прочитать.
• Слой 3 — поиск по данным: найти конкретную задачу, договор, сделку, запись.
• Слой 4 — гэп или человек: когда автоматического ответа нет и нужна живая экспертиза.

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

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

Техническое устройство второго контура

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

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

Система превращает его в объект разбора с фиксированными параметрами:

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

Эксперт не переписывает карту с нуля. Его задача — принять ограниченное, но содержательное решение в точке неопределённости: подтвердить маршрут, разрешить терминологию, решить, нужно ли создавать новый слой или дополнить существующий.

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

Вместо вывода: что это меняет для бизнеса на длинной дистанции

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

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

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

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

Компания меняется постоянно. Меняются процессы, документы, код, настройки, роли, рабочие привычки. То, что ещё недавно было правильным маршрутом к ответу, через некоторое время начинает вести только к части ответа или вовсе в неправильную сторону. Это уже опасно: если у компании нет карты, она честно признаёт, что ответа быстро не получить, но если карта устарела, она начинает отвечать уверенно — и именно поэтому ей легче поверить.

Меня зовут Денис Селезнёв, я генеральный директор «Первой Формы». В этой статье я расскажу, как работать с картой дальше, чтобы она не превращалась в красивый, но мёртвый артефакт.

Почему карта начинает врать

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

На деле карта начинает устаревать сразу по нескольким линиям.

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

Во-вторых, меняются данные и места их возникновения.Ответ на управленческий вопрос редко живёт в одной системе. Сегодня часть сигнала лежит в CRM, часть — в проектном контуре, часть — в документах, часть — в истории задач. Завтра появляется новый отчёт, справочник, категория или интеграция, и карта должна это знать.

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

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

К чему приводит устаревание корпоративной карты

Устаревание карты почти никогда не выглядит как громкая авария. Оно происходит тихо — и в этом главный риск. Вот к чему может привести этот незаметный процесс:

• Растёт число ошибок.Система может опираться на связи, которые когда-то были правильными, но уже не соответствуют реальной среде: изменились роли, процессы, код, конфигурация, набор документов, сами рабочие договорённости. В результате пользователь получает не пустой ответ, а правдоподобный, но уже частично неверный. Это самый опасный тип ошибки, потому что он выглядит убедительно.
• Появляются финансовые риски.Когда устаревшая карта ведёт не туда, компания теряет не только время. Ошибки в маршруте к данным, документам или правилам могут влиять на сроки, качество решений, работу с клиентом, внутренние согласования и стоимость операций. Чем сложнее среда, тем дороже становится каждая такая неточность.
• Сотрудники начинают тратить всё больше ресурсов на перепроверку.Если навигатор регулярно требует ручной валидации, обещание ускорения перестаёт работать. Люди снова идут по знакомому пути: открывают несколько систем, сверяют документы, уточняют у коллег, проверяют, не изменилось ли что-то в коде или настройках. Формально инструмент есть, но значимая часть выгоды съедается постоянной подстраховкой.
• Снижается доверие к системе в целом.Даже полезный инструмент быстро теряет ценность, если пользователь несколько раз сталкивается с уверенным, но неполным ответом. После этого люди либо возвращаются к ручному поиску, либо используют навигатор только как черновую подсказку. Для корпоративной среды это критично: недоверие убивает эффект даже там, где технология сама по себе сильная.
• AI перестаёт быть частью удобного процесса и начинает создавать дополнительную работу.Это один из самых неприятных сценариев. Вместо того чтобы сокращать путь к ответу, система удлиняет его: сначала даёт версию, потом требует проверки, потом заставляет искать подтверждение вручную. В такой конфигурации проблема уже не в модели и не в интерфейсе, а в том, что сама навигационная основа перестала соответствовать живой среде.

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

Опыт «Первой Формы»: как мы обновляем своего картографа для стабильной работы

Первый контур: автоматическое обновление карты из цифрового следа

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

В нашем случае таких сигналов несколько.

1. Структурные изменения конфигурации.

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

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

1. Цифровой след рабочих вопросов.

Мы довольно рано увидели, что огромное количество знаний о предметной области живёт не в регламентах, а в самих вопросах, которые люди задают друг другу в задачах и переписке. Если сотрудники регулярно спрашивают об одном и том же, значит, это либо важный маршрут, либо пробел в существующей карте. Поэтому отдельный слой автоматического обновления у нас связан с анализом Q&A-потока: система смотрит, какие вопросы возникают, какие повторяются, на что уже есть устойчивые ответы, а где навигация срабатывает слабо или вовсе отсутствует.

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

1. Автоматический контур, который работает через инвентаризацию карт и коробок.

Когда предметных областей много, карта не может существовать как единый сплошной монолит. Мы описываем их коробками и слоями: где сущности, где процессы, где аналитика, где автоматизации, где типовые маршруты. Это делает обновление технически управляемым — можно не «перепридумывать знание о компании целиком», а точечно пересобрать нужный фрагмент.

Ещё один важный элемент этого контура — маршрутизация по слоям. Мы не хотим, чтобы каждый вопрос сразу уходил в семантический поиск по всему массиву. Поэтому карта сначала пытается найти более надёжный и дешёвый путь: нормативная база, готовый дашборд, документация, структурированный поиск по данным — и только потом более свободные формы поиска. Это не просто вопрос производительности, а защита от семантического размывания. Если ответ уже существует в виде готовой визуализации или формализованного маршрута, системе не нужно снова «осознавать» всё поле целиком.

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

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

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

Автоматический контур хорошо собирает факты изменения. Но он не понимает всего того, что человек осознаёт в предметной области почти интуитивно. Он не отвечает на вопрос, соответствует ли обновлённая карта смыслу работы.

Автоматическое обновление легко может сделать карту богаче, но не обязательно лучше.

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

Второй контур: экспертная проверка смысла

Если первый контур отвечает на вопрос «Что изменилось?», то второй — на вопрос «Что это значит для карты и как теперь должна выглядеть правильная навигация?».

Это уже работа не алгоритма, а владельца предметной области, аналитика, методолога, продуктового эксперта — того, кто понимает не только структуру системы, но и смысл происходящего внутри неё.

На практике экспертная валидация нужна как минимум в четырёх случаях:

1. Когда нужно подтвердить маршрут.Автоматический контур может показать, что вопрос регулярно возникает в одном и том же виде. Вопрос о причинах просадки воронки может формально вести и в CRM-аналитику, и в отчёты по активности, и в обсуждение конкретной сделки, но только эксперт понимает, какой из этих путей в компании считается правильной точкой входа для такого разбора.

1. Когда нужно разрешить терминологию.Для машины совпадение терминов — это задача сопоставления. Для человека — ещё и задача контекста. Слово «БА» в одной команде означает бизнес-аналитика пресейла, а в другой может читаться иначе, и без экспертной валидации карта начнёт уверенно вести человека не к той роли и не к тому процессу.

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

1. Когда нужно зафиксировать пробел.Иногда правильное экспертное решение — не добавить ещё один маршрут, а честно признать, что карта здесь не покрывает потребность и нужно доработать процесс на уровне команды. Для системы это очень важный жест. Он превращает неясность в управляемый объект: пробел можно поставить в очередь, документировать, разобрать, закрыть. Намного хуже, когда карта делает вид, что знает ответ, хотя на самом деле знание не оформлено.

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

Для нас это особенно важно ещё и по брендовой причине. Мы в «Первой Форме» исходим из того, что полезный AI возникает не сам по себе, а внутри рабочей архитектуры: где уже есть ясные процессы, понятные роли, маршруты и носители ответственности. Поэтому экспертная валидация здесь не «ручной довесок к автоматизации», а обязательная часть самой системы.

Как устроены два контура обновления: техническая механика

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

Техническое устройство первого контура

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

1. Конфигурация площадки и инструмент extract-config.

«Первая Форма» — конфигурируемая платформа. У каждой площадки своя структура: разделы, категории, дополнительные параметры с типами и связями, маршруты с шагами и состояниями, порталы, отчёты, автоматизации, интеграции. Если карта не умеет подтягивать изменения конфигурации, она начинает стареть почти сразу после любой серьёзной настройки.

Поэтому мы построили отдельный инструмент — extract-config. Он подключается к живой площадке через API, забирает полный снимок конфигурации и сохраняет его в единый нормализованный raw JSON. Из одной площадки это могут быть сотни категорий и тысячи параметров.

Дальше в дело вступает автоматический классификатор. Он предварительно раскладывает конфигурацию по предметным областям, используя словарь из 25 предметных доменов — от CRM и проектного управления до HR и финансов. Каждый раздел площадки попадает в одну из трёх корзин: бизнес-процесс, системная инфраструктура или нераспознанное. Последняя группа — это не мусорные сущности, в неё попадают:

• Локальные или кастомные разделы с неочевидным назначением. Например, внутренний раздел с названием, понятным только конкретной команде.
• Технически бедно описанные разделы: по ним мало связей, мало маршрутов, мало данных о реальном использовании, и автоматике просто не на что опереться.
• Смешанные случаи, где в одном разделе перепутаны признаки процесса и инфраструктуры. Например, раздел выглядит как рабочая сущность, но фактически обслуживает только внутреннюю технику учёта или настройки.
• Временные, экспериментальные, устаревающие или полузаброшенные разделы, по которым цифровой след противоречивый.

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

Бизнес-разделы группируются в коробки — замкнутые предметные области с фиксированной структурой знаний. Для каждой коробки запускается набор из семи генераторов, и каждый создаёт свой слой описания

1. Сущности и параметры: какие объекты существуют и как они связаны.
2. Процессы и маршруты: по каким шагам и состояниям движется работа.
3. Аналитика: какие дашборды, отчёты и порталы уже собраны.
4. Автоматизации: какие правила и скрипты срабатывают без участия человека.
5. Связи между коробками: где одна область ссылается на другую через типизированные параметры.
6. Интеграции: какие внешние системы подключены и как обмениваются данными.
7. Типовые вопросы с маршрутами к ответам: какие вопросы в этой области задают и где искать ответ.

Все семь генераторов полностью универсальны — они не знают специфики конкретной области и работают с любым набором категорий. Это принципиально: мы не описываем каждую предметную область вручную, а даём системе механизм, который умеет описывать любую. На десятках клиентских площадок таким образом описаны сотни коробок с покрытием более 99% параметров.

2. Цифровой след рабочих вопросов и пайплайн QA Mining.

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

Мы собрали контур анализа Q&A-потока, в котором последовательно выделяем сигналы, оцениваем их, классифицируем и передаём на валидацию.

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

Второй — скоринг.Каждой паре присваивается оценка по нескольким факторам: длина и подробность ответа, тип вопроса, глубина обсуждения. Самые ценные — вопросы вида «как настроить», «можно ли», «почему так работает», «как это сделано». Это не операционные уточнения, а запросы на знание: конфигурационные рецепты, границы возможностей, архитектурные объяснения. Такие вопросы составляют небольшую долю потока, но именно они показывают, какого типа знание люди ищут.

Третий — классификация.Каждая пара раскладывается по предметным областям и типам знания: конфигурационный рецепт, граница возможностей, бизнес-правило, инструкция, ограничение платформы. Это позволяет понять не просто «о чём спрашивают», а какое именно знание люди пытаются получить.

Четвёртый — валидация.И это, пожалуй, самый важный этап. Мы сопоставляем найденные вопросы с уже существующей документацией. Когда мы запустили этот процесс у себя, обнаружили, что около 40% вопросов уже покрыты картой — проблема была не в отсутствии контента, а в том, что люди не находили к нему дорогу. Без этого этапа мы бы создавали дубли вместо того, чтобы улучшать маршрутизацию.

Инвентаризация и маршрутизация — как карта организует себя

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

Слой ноль — нормативная база: регламенты, политики, SLA. Если ответ зафиксирован как правило — искать дальше не нужно. Слой первый — готовые визуализации: дашборды и отчёты, где ответ уже собран. Слой второй — документация, в которой ответ есть, но его нужно прочитать. Слой третий — поиск по данным: когда нужно найти конкретную задачу, договор, сделку, запись. Слой четвёртый — гэп или человек: когда автоматического ответа не существует и нужна живая экспертиза.

Это не просто вопрос производительности — это защита от семантического размывания. Если ответ уже существует в виде готового дашборда или формализованного маршрута, системе не нужно снова «осознавать» всё поле целиком. Навигатор направляет к самому надёжному и дешёвому пути.

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

Техническое устройство второго контура

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

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

Система превращает его в объект разбора с фиксированными параметрами:

• Тип: не хватает карты или навигатора, документации, возможности инструмента, нет дашборда или источника данных.
• Контекст — из какого вопроса возник пробел.
• Ответственный — тот, кто может его закрыть.

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

После экспертного решения меняется не только текущий ответ на конкретный вопрос, но и сама структура знания. За счёт этого второй контур работает как механизм управляемого дообучения системы на предметных расхождениях. Он не подменяет автоматику, а ограничивает её в тех местах, где уверенность без смысла была бы опаснее, чем отсутствие ответа. Поэтому живая карта поддерживается не только потоком обновлений снизу, но и серией точечных экспертных решений сверху.

Вместо вывода: что это меняет для бизнеса на длинной дистанции

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

Поэтому двойной контур — это не техническое украшение карты. Это способ сохранить полезность системы на длинной дистанции. Вот почему для нас тема AI всегда вторична по отношению к архитектуре процесса. Если в компании нет живой навигации, AI либо не даёт полезного эффекта, либо начинает создавать ложное ощущение надёжности.