Сверено с текущей реализацией 2026-09-30.
Контур запоминает явные решения владельца по вакансиям из очереди «Требуют решения». Он помогает сначала показать более подходящие вакансии и объясняет влияние прошлых решений. Контур не является вторым policy engine и не получает права отправлять, автоматически одобрять или блокировать отклики.
Каждое новое ручное решение создаёт ReviewFeedbackEvent со следующими данными:
approvedилиrejected;- структурированная причина отказа и необязательная заметка;
- связанные profile/application/evaluation/job;
- hashes профиля, предпочтений, резюме и содержимого вакансии;
- минимальный снимок признаков без описания вакансии, письма и текста резюме;
- признак пригодности для обучения и причина исключения.
Старые cancelled, sent, истёкшие вакансии и отсутствие действия не импортируются
как метки. Техническая ошибка или закрытая вакансия не превращается в отрицательное
предпочтение.
Отрицательная метка затрагивает только признаки, связанные с указанной причиной:
| Причина | Учитываемые признаки |
|---|---|
| Должность | категория и слова должности |
| Зарплата | нормализованное состояние зарплаты |
| График | нормализованный график |
| Место | город, район и формат рабочего места |
| Компания | нормализованное название компании |
| Требования | требуемый опыт |
| Проблема вакансии | не используется для обучения |
| Другое | сохраняется как решение, но не приписывается всем признакам |
Одобрение учитывает все структурированные признаки. Оно означает готовность рассмотреть вакансию, но никогда не подтверждает навык, язык, образование или опыт кандидата.
Каждое измерение имеет собственный причинный baseline. Например, признаки зарплаты сравниваются только с отказами по причине «Зарплата», а формат работы — только с отказами по причине «Место». Измерение начинает влиять на порядок и подсказки лишь после минимум шести связанных решений, включая не менее двух принятий и двух причинных отказов. Отказы по другой причине не могут искусственно превратить общий признак всех вакансий в положительное предпочтение.
До готовности хотя бы одного причинного измерения UI сообщает «собирает примеры». Затем сервис рассчитывает сглаженную персональную оценку по повторяющимся структурированным признакам. Для каждой карточки используется не более одного наиболее сильного сигнала на измерение, чтобы коррелирующие слова заголовка не получили непропорциональный вес.
Оценка применяется только к порядку pending_review и короткой объяснимой подсказке.
Переключатель на странице «Требуют решения» приостанавливает это влияние; сами явные
решения продолжают сохраняться. В интерфейсе нет отдельной страницы обучения.
Явное ограничение одним разрешённым городом считается жёсткой настройкой, а не
обучаемым предпочтением. Такой город не участвует в балле, подсказках и предложениях
обучения. Варианты Кишинёв, Кишинев, Chișinău и Chisinau канонизируются как
одно значение. Если разрешены два или более разных города, сравнительный сигнал по
городу снова может учитываться. Районы Rabota.md отделены от города и могут обучаться
как самостоятельное измерение только после причинных отказов по месту.
События review-v2 различают зарплату numeric, textual и missing; текст
Rabota.md Не указана больше не считается указанной зарплатой. Стандартные графики и
уровни опыта приводятся к устойчивым значениям, а свободный текст сохраняется в
нормализованном виде. Значение Удалённо не становится городом.
Старые события review-v1 остаются пригодны для совместимых измерений. Их зарплатный и
почти всегда пустой employment-признаки намеренно не переносятся в новую статистику,
потому что старый snapshot не позволяет восстановить их достоверно. Неизвестные версии
snapshot не смешиваются с текущей моделью.
Должность, категория и опыт ограничиваются категорией активного резюме. Долговременные признаки — компания, место, график и зарплата — могут сохранять влияние после обновления файла резюме. Если активно несколько резюме разных категорий, карточки получают контекстную статистику своего привязанного резюме.
Обучение не может изменить или обойти:
- scam/prompt-injection проверки;
- верификацию контакта, резюме и подтверждённых фактов;
- актуальность вакансии и health источника;
- global pause, deployment kill switch и дневной лимит;
- policy decision, отправку Gmail и idempotency доставки;
- данные профиля и
JobPreference.
Все решения и переключения влияния дополнительно фиксируются в AuditEvent. Работа
через MCP использует те же сервисы и ограничения, что административная панель.
Помимо счётчиков и подсказок, ночной таск train_learning_models строит на явных
метках владельца калиброванную интерпретируемую модель (L2-логистическая регрессия
- изотоническая калибровка вероятности) и сохраняет её версию в
learning_model_versionsвместе с time-series CV-метриками (AUC, log-loss, ECE).
Каждые 5 минут record_learning_shadow предсказывает P(одобрю) для заявок в
очереди «Требуют решения» и сохраняет learning_shadow_outcomes — что модель
сделала бы (approve / reject / abstain) и с какой уверенностью. Когда владелец
принимает явное решение, запись дополняется фактическим исходом и признаком
совпадения.
Shadow-режим не влияет на очередь, отправку или блокировку. Он собирает
доказательную базу: агрегированный scorecard виден в дневном отчёте и через MCP
get_learning_model_status. Автономные действия на основе этой модели —
последующие фазы (docs/superpowers/specs/2026-08-31-learning-autonomy-design.md).