Введение: когда поиск предков требует помощи ИИ

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

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

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

1. Архитектура решения: формирование «цифрового поискового отряда»

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

1.1. Командир отряда: лейтенант Боев

Лейтенант Боев, от же CaptainAgent – это мозг всей операции. Он выступает в роли главного координатора, который первым встречает запрос пользователя. Его задача – проанализировать текст, определить намерение (интент) пользователя (например, «расшифровать адрес» или «узнать, где воевала часть») и направить задачу соответствующему агенту-исполнителю в «отряде». Он же собирает результаты работы всех специалистов и формирует итоговый, осмысленный ответ для человека.

1.2. Специалисты на задании: ключевые агенты и их роли

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

Агент Основная задача
Расшифровщик (DecipherAgent) Извлечь из свободного текста пользователя канонический формат военного адреса.
Почтмейстер (PostmasterAgent) Найти по адресу в объединенных справочниках точное наименование воинской части или соединения.
Сокращатель (AcronymAgent) Корректно расшифровать и сопоставить военные аббревиатуры (например, мсб, сад), что является слабой стороной больших языковых моделей.
Перечень (RosterAgent) Проверить по архивным перечням, существовала ли такая часть, и определить даты ее нахождения в действующей армии.
Состав (SubordinationAgent) Восстановить цепочку подчиненности части на определенную дату (например, полк → дивизия → армия → фронт).

Однако, прежде чем этот «отряд» смог приступить к работе, его нужно было обучить общему языку с пользователем – а это оказалось настоящим полем битвы.

2. Битва за понимание: трудности обучения языковой модели

Первым и самым серьезным вызовом стала разработка «Расшифровщика». Люди, далекие от архивного дела, формулируют запросы самым непредсказуемым образом: путают термины «полевая почта» и «войсковая часть», пишут номера с пробелами или дефисами, допускают опечатки. Нужно было научить языковую модель (LLM) видеть структуру в этом хаосе. Здесь сильно пригодилась база из 6800 реальных поисковых запросов, по которым пользователи попадали на сайт «Боевой славы» из Яндекса.

2.1. От хаоса к структуре: эволюция промпта

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

  1. Начало: Первые промпты содержали простые инструкции, но они оказались неэффективными. Модель тонула в огромном разнообразии пользовательских запросов, путанице в терминах и исторических нюансах (например, разные типы адресации до и после 1943 года).
  2. Усложнение: Чтобы повысить точность, промпт начал разрастаться. В него добавлялись глоссарии, подробные описания каждого термина («полевая почтовая станция», «войсковая часть – полевая почта»), примеры реальных запросов и правила их интерпретации в зависимости от даты. В итоге объем промпта превысил 10 КБ текста.
  3. Прорыв: Качественный скачок произошел благодаря идее, предложенной Станиславом Рачинским (rkka.wiki). Вместо того чтобы пытаться сразу угадать, что имел в виду пользователь, модель последовательно проверяет запрос на соответствие каждому из четырех известных типов войсковых адресов. Модель анализирует запрос и для каждого типа выносит вердикт: «содержит», «вероятно содержит» или «не содержит» адрес данного типа. Это радикально повысило качество и предсказуемость распознавания.

2.2. Гарантия результата: как XML-разметка помогла «приручить» вывод модели

Даже с идеальным промптом оставалась проблема: языковая модель генерировала ответ в виде свободного текста с Markdown-разметкой. Такой формат был удобен для чтения, но совершенно ненадежен для программной обработки – малейшее изменение в форматировании ломало парсинг.

Решение оказалось простым и эффективным: заставить модель оборачивать результаты своей работы в XML-теги. Теперь ответ приходит в строго структурированном виде, например для запроса «п/п 2478 ч 425 как определить что за часть во время вов»:

<decipherResult>
  <analysis>
    <!-- Оценка соответствия запросу каждому типу адреса (0‑1‑2‑3) -->
    <type_0>0.05</type_0>
    <type_1>0.15</type_1>
    <type_2>0.95</type_2>
    <type_3>0.05</type_3>
  </analysis>
  <address>Тип 2: ппс 2478, часть 425</address>
  <comments>
    Запрос содержит обозначения «п/п 2478» (полевая почта = ппс) и «ч 425» (часть 425).        
    Это полностью соответствует формату типа 2 (ппс + условный номер части).
    Год «вов» (Великая Отечественная война) попадает в период использования типа 2 (октябрь 1942 – май 1943).
    Другие типы не удовлетворяют обязательному условию наличия слова «часть» и/или корректного формата ппс/вчпп.
  </comments>
</decipherResult>

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

3. Перебор моделей: путь проб, ошибок и неожиданных открытий

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

3.1. От идеала к реальности

Эксперименты начались с лучших мировых моделей, но реальность быстро внесла свои коррективы.

  • DeepSeek: На старте эта модель показала себя идеально. Она работала стабильно, предсказуемо и точно следовала инструкциям в промпте. Однако, когда дело дошло до развертывания, выяснилось, что ее API недоступно для оплаты из России, что сделало ее использование нецелесообразным.
  • Gemini: Следующим шагом стал переход на модель от Google (это произошло синхронно с переходом на Antigravity и фреймворк A2A). Это потребовало значительной переработки и доводки промптов, которые изначально были оптимизированы под DeepSeek. Несмотря на все усилия, качество распознавания адресов заметно деградировало по сравнению с первоначальным вариантом. Например, модель Gemini упорно утверждала, что мсб – это «медсанбат», хотя на самом деле это «мотострелковый батальон», а это критически подрывало доверие к результатам поиска.

3.2. Переход на отечественные модели и его последствия

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

  • Цензура («Толерастика»): модели Яндекса наотрез отказывались обрабатывать запросы, содержащие определенные «чувствительные» слова. Например, найденное для «ппс 1461» в справочнике соответствие «3 мсд ВВ НКВД» приводило к ответу в духе «Я не могу об этом говорить». Проблема доходила до абсурда: толерантная автоматика («толерастика») могла сработать даже на определенные имена пользователей в логах, что делало отладку и анализ работы системы крайне затруднительными. Для чат-бота, работающего с историческими военными документами, такая цензура делала его практически бесполезным.
  • Тайм-ауты API: GigaChat оказался лишён этого недостатка Яндекса, но следующим барьером стала связка двух отечественных гигантов: «Алиса» (Yandex) для расшифровки адреса и «GigaChat» (Сбер) для генерации финального ответа Капитаном. При обращении из инфраструктуры Yandex Cloud к API GigaChat постоянно происходили сбои по тайм-ауту на этапе авторизации. Это приводило к тому, что функция обработки запроса перезапускалась снова и снова, сжигая платные токены на повторном распознавании и так и не выдавая результат пользователю.

3.3. Прагматичный финал: выбор в пользу Open-Source

После череды неудач с коммерческими российскими моделями выбор пал на open-source модель gpt-oss-120b, развернутую в той же инфраструктуре Yandex Cloud. Этот выбор оказался проще, надёжнее и, как ни странно, дешевле. Но вскрылся очередной слой проблем. Например, получив от агента-почтмейстера точное название «1-й отдельный полк связи», оперсорсное творение OpenAI могло «сочинить» в итоговом ответе нечто вроде «отдельная полковая часть связи», искажая исходные данные. И уж конечно она, как и старшая коммерческая модель, постоянно пыжилась предложить пользователю следующий шаг, при этом совершенно не вдупляя, каким он на самом деле должен быть. Тем не менее, это решение стало прагматичным компромиссом.

Плюсы Минусы
Высокая скорость работы (~10 секунд на полный цикл) Плохое знание русских армейских сокращений
Низкая стоимость Склонность «фантазировать» и перевирать названия частей
Отсутствие цензуры и проблем с API Требует доработки промптов для подавления «вредных советов»

Недостатки GPT-OSS были не приговором, а инженерной задачей. Стало ясно, что для достижения исторической точности полагаться исключительно на LLM нельзя – нужно было ковать собственное «оружие». Первым на очереди стал инструмент для работы с военными аббревиатурами.

4. Акроним: создание словаря военных сокращений

Языковые модели, особенно open-source, плохо справляются с узкоспециализированными военными сокращениями. Они могут путать мсб (мотострелковый батальон) с «медсанбатом» или неверно интерпретировать гсд (не «гвардейская», а «горнострелковая» дивизия). Чтобы избежать фантазий модели, был создан агент «Сокращатель».

  • Задача: У этого агента была двойная функция. Во-первых, он должен был расшифровывать сокращения, встречающиеся в названиях частей (например, мд → моторизованная дивизия, а не миномётная и не механизированная!). Во-вторых, что не менее важно, он должен был выполнять обратную операцию – находить каноническое сокращение для полного наименования. Это было необходимо для создания единого идентификатора для каждой воинской части, который позволил бы надежно связывать данные о ней из разных архивных источников.
  • Решение: За основу был взят оцифрованный справочник армейских сокращений. Он был вручную очищен от дублей, обогащён справочниками rkka.wiki и скомпилирован в специальное «дерево сокращений». Оно позволяет обрабатывать сложные и неоднозначные случаи, когда одно и то же сокращение может иметь несколько значений в зависимости от контекста. Например, ад означает «артиллерийская дивизия», а ад ДД – «авиационная дивизия дальнего действия». Этот компонент стал решающим для повышения качества генерации ответа системой.

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

5. Запуск и первая обратная связь

Проект перешел на новый этап с началом закрытого бета-тестирования и формированием видения будущего развития. Тестирование началось 9 декабря, в День Героев Отечества. Одними из первых пользователей стали признанные эксперты в области военного поиска:

  • Игорь Иванович Ивлев, создатель сайта soldat.ru, с которого для многих начинался путь в военном поиске. Его справочниками ППС и ВЧПП мы пользуемся в боте. Справочники условных номеров полевых почт будут совместными усилиями оцифрованы и внесены в базу (пока для примера внесены условные номера Волховского фронта и 2-й Ударной армии)
  • Станислав Рачинский, создатель rkka.wiki, который оцифровал Составы и Перечни. Хотя на сайте выложено всего 7 перечней из 34, это уже 33000 войсковых формирований. Просто вдумайтесь в это. Его труд по оцифровке перечней будет продолжен и общими усилиями завершён
  • Михаил Дымшиц, член президиума Союза филателистов России, историк почты, десятки лет кропотливо исследующий тему военно-почтовых и в особенности военно-морских почтовых станций и военной цензуры. В боте используется собранный им Справочник учреждений военно-полевой почты РККА, 1939-1945 гг. (М. Дымшиц, Москва, 2025)

6. Текущие задачи и перспективы

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

6.1. Модель данных: темпоральные графы

Главное направление работы прямо сейчас – осмысление архитектуры данных, проектирование модели данных и разработка протоколов обмена данными. Видится плодотворной концепция темпоральных графов, идея которой – представлять историю каждого воинского формирования (полка, дивизии, армии) не как статичную запись, а как непрерывную временную линию его «судьбы».

Такой граф позволит отслеживать всю историю части:

  • Создание: когда и где она была сформирована.
  • Переименования: как менялось ее название (например, стала «армейской»)
  • Переформирования: как объединялась, как на базе неё формировались другие части, как становилась «гвардейской».
  • Переподчинения: как менялась ее принадлежность к более крупным соединениям.
  • Расформирование: когда она прекратила свое существование.

Вспомните недавно опубликованный дневник Державина (1-я часть, 2-я часть). Его 207-й артиллерийский полк сначала был корпусным, затем стал армейским, а потом стал гаубичным и вошел в состав артиллерийской бригады. С точки зрения непрерывности истории, это одна и та же боевая единица, но в разных справочниках она может фигурировать под разными именами и с разным подчинением. Темпоральный граф позволит связать все эти «состояния» в единую цепочку, восстанавливать «разрывы» в боевом пути и проверять поисковые гипотезы с очень высокой степенью доказуемости.

6.2. Примат доказуемости (The Primacy of Provenance)

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

Заключение: уроки, извлеченные из разработки

Путь создания чат-бота «Боевая слава» наглядно демонстрирует, что разработка сложного ИИ-продукта – это итеративный процесс, полный проб и ошибок. Он требует упорства для преодоления как ожидаемых технических трудностей, связанных с обучением моделей и обработкой данных, так и совершенно непредвиденных препятствий, будь то цензурные ограничения или межкорпоративные проблемы с API.

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