Когда система распределяет места, заявки или ограниченные ресурсы, вопрос «почему получился такой результат» должен иметь проверяемый ответ. Нужны исходные данные, действовавшие правила и последовательность решений. Убедительное объяснение, созданное после расчёта, не заменяет этих материалов.

В работе Владымцева и Могилевца 2025 года рассматривается оптимизация зачисления на примере автоматизированной системы БГУИР. Для других задач полезен более общий инженерный вопрос: как отделить утверждённые правила распределения от реализации и последующего объяснения.

Начать с формального описания правил

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

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

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

Небольшой учебный пример

Представим вымышленное распределение на два учебных направления, X и Y. На каждом одно место. Для примера заранее установлено: заявки рассматриваются по убыванию балла; кандидат получает первое доступное направление из своего списка. Реальные правила приёма могут быть устроены иначе.

Заявка Балл Предпочтения
A 98 X, затем Y
B 96 Только X
C 95 Только Y

При этих правилах A получает X, B остаётся без места, C получает Y. Можно вообразить другое распределение: A на Y и B на X. Оно тоже заполняет оба места, но лишает A первого выбора. Чтобы выбирать между такими вариантами, нужна заранее установленная цель и правило приоритета. Само заполнение всех мест ещё не определяет единственный правильный результат.

Если A изменит предпочтения на Y, затем X, результат станет другим: A получает Y, B — X, C остаётся без места. Поэтому версия списка предпочтений входит в исходные данные расчёта.

Если у A и B одинаковый балл, описанных условий недостаточно для определения порядка. Сначала нужно утверждённое правило разрешения равенства. Выбор по внутреннему идентификатору не становится допустимым только потому, что его легко воспроизвести.

Зафиксировать входной срез

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

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

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

Проверять свойства результата

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

Свойство Пример проверки
Ограничение ёмкости Число назначений не превышает доступные места
Единственность Одна заявка не получает несколько несовместимых назначений
Допустимость Назначенный вариант разрешён условиями заявки и правилами
Воспроизводимость Одинаковые версии входа и правил дают одинаковый результат
Независимость от случайного порядка Перестановка строк не меняет итог, если правила не используют этот порядок

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

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

Объяснять из следа расчёта

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

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

Официальное решение принимает уполномоченный процесс. Модель не должна изменять приоритеты или подменять основания красивым рассуждением.

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

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