Управление знаниями в эпоху ИИ: RAG, Memory Bank и корпоративная память для 1С

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

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

В этой статье разберем три связанных подхода:

• RAG — поиск релевантной информации перед формированием ответа;
• Memory Bank — внешнюю память агента о проекте, решениях и ограничениях;
• корпоративную память — общий контур, в котором документы, метаданные 1С, код, задачи и история решений становятся доступными людям и ИИ-агентам.

Данных много, знаний мало

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

Каждый слой отвечает только на часть вопросов. Метаданные показывают, что есть в системе. Код помогает понять, как она работает. Документация описывает ожидаемый процесс. История поддержки показывает, какие проблемы уже встречались. Эксперт может объяснить, почему решение устроено именно так и какие исключения нельзя забывать.

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

Например, разработчик спрашивает: «Как получить остатки по складам?» Модель, знающая 1С в целом, может предложить регистр ОстаткиТоваров. Название звучит правдоподобно, но в конкретной базе такого регистра нет. Там может использоваться ТоварыНаСкладах, отдельный регистр резервов и дополнительная обработка, меняющая логику для одного склада.

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

Поэтому ИИ в 1С должен работать не с абстрактным «миром 1С», а с конкретной рабочей реальностью проекта: настоящими именами объектов, действующими правилами, историей решений и известными исключениями.

Почему традиционная база знаний не всегда помогает

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

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

Для 1С есть дополнительная сложность: одинаковые слова могут обозначать разные сущности. «Заказ», «реализация», «клиент», «продажа» и «резерв» в разных конфигурациях имеют разную структуру и бизнес-смысл. Запрос «не закрывается заказ» может означать, что документ не проводится, статус не меняется, заказ не попадает в обмен или пользователь не видит нужную команду из-за прав.

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

Что такое RAG

RAG расшифровывается как Retrieval-Augmented Generation — генерация ответа с предварительным поиском по внешним источникам. Модель не пытается ответить только на основе своих общих знаний. Сначала система принимает вопрос, находит релевантные фрагменты в подключенной базе, передает их модели, а затем формирует ответ с учетом найденного контекста.

Процесс можно представить так:

1. Пользователь задает вопрос.
2. Система преобразует его в поисковый запрос.
3. Поиск находит подходящие документы, фрагменты кода, метаданные или решения.
4. Релевантные результаты передаются языковой модели.
5. Модель формирует ответ и, по возможности, указывает источники и ограничения.

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

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

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

Как RAG работает под капотом

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

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

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

Для 1С обычно нужен гибридный поиск. Семантический поиск хорошо понимает смысл пользовательского вопроса: «не списывается товар», «нет доступа», «не вижу отчет». Лексический поиск необходим для точных имен: Контрагент, ТоварыНаСкладах, ДатаОтгрузки, Документ.ЗаказКлиента.

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

Какие источники нужны для 1С

В 1С источником знаний является не только текстовый документ. В индекс могут входить:

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

Особенно полезен RAG по метаданным. Вместо общего описания «в 1С есть документы и регистры» модель получает схему конкретного объекта: его имя, синоним, реквизиты, табличные части, формы, команды, движения и связанные процедуры.

Например, для Документ.ЗаказКлиента индекс можно собрать из отдельных фрагментов:

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

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

Примеры RAG в поддержке и разработке

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

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

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

В разработке запрос может звучать так: «Как получить продажи по контрагенту за период?» RAG по метаданным находит документ реализации, регистр продаж, измерение Контрагент, ресурс Сумма и период. Модель отвечает уже по конкретной конфигурации, а не по наиболее распространенному примеру из обучающих данных.

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

Memory Bank: что агент должен помнить

RAG отвечает на вопрос: «Где найти факты?» Memory Bank отвечает на другой вопрос: «Что мы уже решили?»

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

В Memory Bank могут храниться:

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

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

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

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

Пример: отчет по маржинальности

Команда проектирует отчет и фиксирует в Memory Bank несколько решений:

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

Через две недели разработчик или агент может продолжить работу без повторного погружения в обсуждение. Главное — сохранено не только «что сделали», но и «почему именно так».

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

Корпоративная память: RAG и Memory Bank вместе

RAG и Memory Bank решают разные задачи. RAG поднимает сведения из источников. Memory Bank сохраняет историю и состояние проекта. Вместе они формируют корпоративную память — контур, в котором ИИ получает проверяемый контекст для текущей работы.

Такую систему удобно рассматривать как четыре слоя:

1. Источники знаний: документы, метаданные, код, обращения, задачи и решения.
2. Слой поиска: индексы, синонимы, гибридный поиск и rerank.
3. Слой памяти: Memory Bank, прогресс, ограничения и история решений.
4. Слой доступа: MCP или API, права, фильтры и аудит.

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

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

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

Коротко это можно сформулировать так: MCP дает агенту инструменты, а skill задает правила их безопасного применения.

Где корпоративная память полезна в 1С

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

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

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

Риски и роль человека

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

Для 1С особенно важны версии. Инструкция для одной версии ERP может быть почти применима к другой, но именно небольшое различие иногда меняет роль, движение регистра или доступность команды. Поэтому дата и версия — часть содержания знания, а не формальная служебная информация.

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

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

Как измерять качество

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

Для поиска используются метрики Precision@K, Recall@K, MRR, NDCG и Hit Rate. В прикладном смысле они отвечают на вопросы: попал ли нужный материал в выдачу, насколько высоко он оказался и не перегружены ли верхние результаты нерелевантными фрагментами.

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

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

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

Пилот: с чего начать

Практический запуск можно организовать в шесть шагов:

1. Выбрать узкий сценарий — например, вопросы первой линии или поиск по метаданным.
2. Собрать реальные вопросы из обращений и задач.
3. Подготовить актуальные источники, убрать явные дубли и архивы.
4. Настроить индексацию, синонимы и права доступа.
5. Завести минимальный Memory Bank с активными решениями и ограничениями.
6. Измерить качество и собрать обратную связь пользователей.

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

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

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

Выводы

Качество ИИ-ассистента в 1С складывается из нескольких компонентов:

Качество ассистента = Качество модели + качество источников + качество поиска + качество памяти + качество человеческой проверки

RAG дает модели актуальные фрагменты из корпоративных источников. Memory Bank сохраняет решения, ограничения и ход работы. MCP подключает инструменты и контролируемый доступ к метаданным и другим системам. Skills задают правила поведения агента. Человек проверяет критичные выводы и отвечает за качество самой памяти.

RAG не заменяет документацию. Он делает ее доступнее и одновременно показывает пробелы: на какие вопросы система не может ответить, где материалы устарели, какие термины используются непоследовательно. Memory Bank не должен хранить все подряд — его ценность в ясных, актуальных и объяснимых решениях.

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

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