Как поддерживать корпоративную карту в рабочем состоянии, чтобы AI не начинал ошибаться

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Появляются финансовые риски. Когда устаревшая карта ведёт не туда, компания теряет не только время. Ошибки в маршруте к данным, документам или правилам могут влиять на сроки, качество решений, работу с клиентом, внутренние согласования и стоимость операций. Чем сложнее среда, тем дороже становится каждая такая неточность.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для нас это особенно важно ещё и по брендовой причине. Мы в «Первой Форме» исходим из того, что полезный 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 либо не даёт полезного эффекта, либо начинает создавать ложное ощущение надёжности.