HUMAN-IN-THE-LOOP ПОДХОД К ПРОЕКТИРОВАНИЮ LLM-COPILOT СИСТЕМЫ ДЛЯ ИНТЕЛЛЕКТУАЛЬНОЙ ПОДДЕРЖКИ ОПЕРАТОРА БАНКА ПРИ ОБРАБОТКЕ ЗАПРОСОВ КЛИЕНТОВ

HUMAN-IN-THE-LOOP APPROACH TO DESIGNING AN LLM-COPILOT SYSTEM FOR INTELLIGENT SUPPORT OF A BANK OPERATOR IN PROCESSING CUSTOMER REQUESTS

Voznyuk Mikhail Vladimirovich

Student, Department of Applied Informatics, Russian State Agrarian University - Moscow Timiryazev Agricultural Academy,

Russia, Moscow

Zhukova Olga Yurievna,

Student, Department of Applied Informatics, Russian State Agrarian University - Moscow Timiryazev Agricultural Academy,

Russia, Moscow

Chudinova Polina Alexandrovna

Student, Department of Applied Informatics, Russian State Agrarian University - Moscow Timiryazev Agricultural Academy,

Russia, Moscow

Korableva Galina Vladimirovna

Scientific supervisor, PhD in Economics, Assoc. Prof., Russian State Agrarian University - Moscow Timiryazev Agricultural Academy,

Russia, Moscow

АННОТАЦИЯ

В статье рассматриваются вопросы проектирования LLM-copilot системы для поддержки оператора банка при обработке запросов клиентов, связанных с обслуживанием банковских карт. Обоснован human-in-the-loop подход, при котором модель не принимает решение автономно, а помогает анализировать обращение, искать регламенты, формировать подсказки и безопасный черновик ответа. Описаны RAG-контур, режимы ANALYZE, DRAFT, EXPLAIN, BFF/backend-слой, инструментальные действия, PII-маскирование, RBAC, policy-pack и аудит.

ABSTRACT

The article discusses the design of an LLM-copilot system to support a bank operator in processing customer requests related to bank card services. The system is designed as a human-in-the-loop support tool, not as an autonomous decision maker. The paper outlines the RAG subsystem, ANALYZE, DRAFT and EXPLAIN modes, trusted BFF/backend layer, tool calls, PII masking, RBAC, policy gating and audit logging.

Ключевые слова: LLM-copilot, обращения клиентов банка, RAG, оператор банка, human-in-the-loop, информационная безопасность, аудит, BFF.

Keywords: LLM-copilot, requests from the Bank's clients, RAG, bank operator, human-in-the-loop, information security, audit, BFF.

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

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

Особенность решаемой задачи состоит в том, что оператор не может действовать произвольно, а должен чётко следовать регламентам банка для ситуации, соответствующей обращению клиента. В коммуникации с клиентом недопустимы запросы ПИН-кода, CVV/CVC, одноразовых кодов подтверждения, полного номера карты и иных секретных данных. Также недопустимо обещать возврат средств до завершения проверки. Следовательно, автоматизация должна не заменять оператора, а поддерживать его работу и сохранять контроль человека над итоговым действием. Такой подход соответствует принципу human-in-the-loop [5].

Развитие больших языковых моделей создало предпосылки для появления систем операторской поддержки, которые анализируют текст обращения, выделяют намерение пользователя и формируют черновик ответа. Вместе с тем языковая модель не гарантирует фактическую точность без внешнего контекста и контроля [4]. Для банковского контура это означает, что LLM нельзя рассматривать как автономный источник истины. Ее вывод должен быть ограничен регламентом, структурой процесса и серверной валидацией.

Одним из применимых подходов является retrieval-augmented generation. В RAG-архитектуре генерация ответа дополняется поиском по базе знаний, что позволяет связывать подсказки с конкретными фрагментами документов и обновлять фактическую основу без переобучения модели [3]. Для обработки обращений клиентов, связанных с карточными операциями, это особенно важно: оператор должен видеть, на какие правила, скрипты и шаблоны опирается рекомендация.

Стандарты и практики управления AI-рисками подчеркивают необходимость явного определения назначения системы, управления доступом, мониторинга качества, документирования ограничений и анализа возможного вреда от её применения [5; 6]. Для LLM-приложений существенны prompt injection, раскрытие чувствительной информации, небезопасная обработка вывода и чрезмерное доверие пользователя к подсказке. Поэтому проектирование copilot-системы должно включать не только функции, но и технические ограничения поведения модели.

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

Для достижения поставленной цели на начальном этапе исследования выполнен анализ проблем, решаемых операторами банков при обращении клиентов по вопросам, связанным с обслуживанием банковских карт, затем сформулированы функциональные и нефункциональные требования к программному продукту, спроектирована микросервисная архитектура системы, определён механизм работы режимов ANALYZE, DRAFT и EXPLAIN, а также описаны меры управления рисками в процессе её эксплуатации: PII-маскирование, RBAC, policy-pack, allowlist инструментов, idempotency, модерацию и audit trail.

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

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

Архитектура MVP включает операторский веб-интерфейс, доверенный BFF/backend-слой, подсистему диалогов и кейсов, copilot-сервис, worker, RAG-контур, MCP/tool-сервис, audit-сервис и хранилища данных. Backend реализует HTTP API, проверку доступа, оркестрацию запросов, хранение сообщений, работу с кейсами и журналирование. Worker выполняет асинхронный конвейер: модерацию, маскирование персональных данных, анализ обращения, поиск документов, подготовку черновика и валидацию структуры ответа.

Ключевой архитектурный принцип - разделение доверенной и недоверенной зоны. Браузер и frontend не считаются доверенными компонентами, поэтому защищенные операции проходят через server-side BFF. Он проверяет пользовательскую сессию и передает во внутренний контур подписанный контекст субъекта. Такой подход снижает риск подмены роли пользователя, прямого вызова внутренних API из браузера и обхода ограничений доступа.

Режим ANALYZE запускается после запроса подсказки. Backend создает задачу, сохраняет ее метаданные в Redis и передает worker. Worker читает историю сообщений из PostgreSQL, выполняет модерацию входного контекста и маскирование чувствительных данных. Затем модель или stub-контур формирует структурированный анализ: intent обращения, фазу процесса, найденные факты, недостающие поля, уровень готовности кейса и ограничения. Ответ модели должен соответствовать заранее определенной JSON-схеме, иначе результат отклоняется или переводится в безопасный режим.

Режим DRAFT формирует проект ответа и элементы операторской подсказки. Черновик не должен обещать клиенту возврат средств, запрашивать секретные данные или предлагать действие, которое не подтверждено регламентом и текущим состоянием кейса. Режим EXPLAIN применяется после инструментального действия или изменения состояния кейса и объясняет оператору, что было выполнено, какой результат получен и какой следующий шаг допустим. При этом persisted state изменяет backend и специальный механизм состояния (deterministic state engine), а не LLM.

RAG-контур служит функциональной опорой системы. Элементы панели Copilot и RAG-контура представлены на рис. 1.

Рисунок 1. Элементы панели Copilot: быстрые подсказки, readiness, инструменты и источники RAG

В разработанном прототипе программного продукта предусмотрены: загрузка документов, переиндексация, разбиение на фрагменты, построение embeddings и поиск по внутренним регламентам. Исходные документы хранятся в MinIO, метаданные и фрагменты – в таблицах СУБД PostgreSQL, векторы - в pgvector. Такая организация позволяет обновлять базу знаний без изменения интерфейса и связывать каждую подсказку с поисковым запросом (retrieval snapshot).

Инструментальный контур отделен от LLM и frontend. Поддерживаемые действия MVP включают создание обращения, получение статуса кейса, демонстрационный список операций, имитацию блокировки, разблокировки и перевыпуска карты, получение и изменение лимитов. Доступность каждого инструмента определяется не кнопкой на frontend, а специальным механизмом (policy/state engine). На формируемой по клиентской ситуации решение влияют намерения (intent), фаза Collect, действия оператора (Act) или объяснения регламента (Explain), недостающие поля, подтвержденные факты, особенности реализации безопасного режима и результаты предыдущих действий.

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

Операторский интерфейс реализуется как рабочее место с тремя зонами (рисунок 2). Левая зона содержит список диалогов и статусы обращений, центральная зона отображает переписку с клиентом и поле ввода, правая зона содержит панель Copilot с рекомендациями, источниками, readiness, доступными инструментами и объяснениями.

В демонстрационном frontend-прототипе используется Next.js App Router, TypeScript, Tailwind CSS, Prisma и PostgreSQL для demo-auth. Все запросы к backend идут через BFF-обработчики, что соответствует выбранной модели доверия.

Рисунок 2. Операторская консоль с очередью обращений, текущим диалогом и панелью Copilot

Безопасность системы строится на нескольких уровнях. Первый уровень - ролевая модель и проверка доступа к объектам. Второй уровень - policy-pack, ограничивающий доступные действия. Третий уровень - PII-маскирование перед передачей контекста в модель. Четвертый уровень - модерация входа, найденных фрагментов и ответа модели. Пятый уровень - аудит, в котором фиксируются actor context, trace_id, event type, состояние до и после операции, retrieval snapshot, версия политики и информация о кэше.

Анализ рисков показывает, что наиболее значимыми являются устаревание регламентов в базе знаний, потеря истории диалогов и аудита, генерация некорректной рекомендации, быстрые инъекции (prompt injection), утечка персональных данных, обход RBAC и неподтвержденное выполнение инструментального действия. Эти риски нельзя устранить только выбором модели. Необходимы организационные владельцы контента, регулярная переиндексация базы знаний, тестовые сценарии, технические ограничения и приемочные критерии.

Практическая ценность разработанного прототипа программного продукта состоит в том, что система проектируется не как абстрактный чат с LLM, а как управляемый компонент операторского процесса. В рамках работы над прототипом LLM-copilot системы выполнено обследование объекта автоматизации, формирование требований, моделирование, проектирование архитектуры, разработка backend и frontend, создание RAG-контура, настройка безопасности, тестирование и подготовка демонстрационного стенда.

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

Предложенная архитектура включает доверенный BFF/backend-слой, асинхронный worker, RAG-контур, инструментальный сервис, audit-сервис и набор хранилищ данных. Ключевыми защитными механизмами являются запрет автономного изменения состояния моделью, серверная валидация JSON-ответов, PII-маскирование, модерация, RBAC, пакет политик (policy-pack), allowlist инструменты, ключ идентичности и полный аудит функций перечисленных механизмов.

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

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

Список литературы:

1. ГОСТ 34.602-2020. Информационные технологии. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы. Общие требования. - М.: Стандартинформ, 2022.
2. ГОСТ Р 7.0.100-2018. Система стандартов по информации, библиотечному и издательскому делу. Библиографическая запись. Библиографическое описание. Общие требования и правила составления. - М.: Стандартинформ, 2018.
3. Lewis P., Perez E., Piktus A., Petroni F., Karpukhin V., Goyal N. et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks // Advances in Neural Information Processing Systems. - 2020. - Vol. 33. - P. 9459-9474.
4. Brown T. B., Mann B., Ryder N., Subbiah M., Kaplan J. et al. Language Models are Few-Shot Learners // Advances in Neural Information Processing Systems. - 2020. - Vol. 33. - P. 1877-1901.
5. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0). - Gaithersburg: NIST, 2023. - DOI: 10.6028/NIST.AI.100-1.
6. ISO/IEC 42001:2023. Information technology - Artificial intelligence - Management system. - Geneva: International Organization for Standardization, 2023.