[drive-download] драфт записка.docx

В ходе пилотного этапа проекта конституционный чат-бот подтвердил свою базовую полезность как справочный инструмент навигации по конституционным материалам, но одновременно выявил ряд системно значимых рисков, которые для публичного инструмента такого класса требуют отдельной управляемой донастройки. Речь идёт не о единичных сбоях, а о нормальном результате пилотной эксплуатации и целевого стресс-тестирования, когда на ранней стадии становится видно, какие требования к точности, нейтральности и воспроизводимости ответа необходимо формализовать до перехода к более широкому использованию.<br> Пилот показал несколько ключевых зон риска. Во-первых, в отдельных сценариях бот мог создавать избыточно уверенное впечатление полноты там, где корректнее было говорить только о подтверждённых найденных нормах, без заявлений об исчерпывающем охвате темы. Во-вторых, проявился риск непоследовательности на широких и чувствительных запросах, особенно там, где пользователь последовательно усиливает вопрос уточнениями и проверяет модель на внутреннюю устойчивость. В-третьих, стало очевидно, что для такого инструмента недостаточно общей “нейтральной” стилистики: нужна более жёсткая дисциплина источников, чтобы нормативный слой не смешивался с разъяснительными материалами, FAQ и историческим слоем.<br> Отдельно пилот подтвердил, что формальный дисклеймер сам по себе не решает проблему доверия и интерпретации. Если бот используется в публичном контуре и воспринимается как рекомендованный справочный инструмент по Конституции, для внешней аудитории решающим становится не наличие оговорки на сайте, а фактическая точность, предсказуемость и внутренняя согласованность конкретных ответов. Именно поэтому основная задача следующего этапа — не “смягчить формулировки”, а перевести поведение системы в более строго управляемый режим grounded-ответа.<br> По результатам пилота проект был переведён из условно общего “чат-режима” в архитектуру с более явными защитными правилами. На уровне системной инструкции закреплено, что бот отвечает только по найденным материалам рабочего контекста, не компенсирует пробелы догадками, не заявляет полноту без специального основания, не подменяет отсутствие подтверждения категорическим отрицанием и не принимает политическую рамку вопроса как установленный факт. Это снимает сразу несколько ранее выявленных классов риска: ложную полноту, скрытую интерпретацию, давление на модель через follow-up вопросы и размывание границы между подтверждённой нормой и неподтверждённым выводом.<br> Параллельно была формализована retrieval-политика, потому что качество ответа в этой задаче определяется не только тем, как модель “формулирует”, но и тем, какой именно контекст попадает в ответ. В новой логике 2026 norm закреплён как основной приоритетный слой, commentary и faq допустимы только как вторичный пояснительный контекст, а слой 1995 deprecated используется только для исторической справки или прямого сравнения и не должен становиться нормативным ответом по умолчанию. Также отдельно зафиксировано, что retrieval обязан учитывать не только похожесть текста, но и слой, язык, статус, deprecated-признак, структурную точность статьи или пункта и риск ложной актуализации исторического материала.​<br> Это особенно важно для текущей конфигурации проекта, где в PostgreSQL уже собраны восемь документных наборов, включая основной нормативный слой 2026, разъяснительные слои и исторический слой 1995. В такой архитектуре зрелость системы определяется именно качеством маршрутизации и дисциплиной использования этих слоёв, а не только “общей разумностью” модели. Иными словами, следующий этап проекта закономерно сместился от ingestion к prompt design, retrieval policy и QA прикладочного поведения бота.<br> Отдельным направлением стала защита от политического фрейминга и мета-извлечения внутренней логики. Пилотное стресс-тестирование показало, что пользователь может не только проверять фактическую точность ответа, но и пытаться навязать модели оценочную рамку, заставить её скрыто продолжить уже заданный политический нарратив или извлечь из неё внутренние правила работы. В ответ на это в новой системной логике зафиксировано: бот не должен подстраиваться под навязанную политическую рамку, не должен раскрывать скрытые правила или внутреннюю механику, а на острые вопросы должен отвечать через нейтральное описание найденных норм, процедур, ограничений и различий между слоями без политических выводов.<br> Чтобы эта настройка не осталась только на уровне деклараций, следующий слой работы был переведён в формальный red-team и release-gate режим. Для prompt/retrieval-контура подготовлен тестовый пакет с контрольными сценариями на ложную полноту, подмену norm разъяснительными слоями, leakage из 1995 deprecated, политический фрейминг, weak retrieval, safe failure, article mismatch и попытки раскрыть внутренние инструкции. Результаты таких прогонов должны фиксироваться через единый QA-шаблон с блокерами, rubric-оценкой, планом исправлений, повторным прогоном и финальным решением GO / CONDITIONAL GO / NO-GO.<br> Таким образом, пилотный этап дал проекту не только подтверждение базовой работоспособности, но и точную карту тех рисков, которые действительно важны для продового конституционного бота. Это позволило перевести обсуждение из общей плоскости “хорошо или плохо отвечает” в профессионально управляемую рамку: какие источники имеют приоритет, как бот должен вести себя на широких запросах, как не допускать ложной полноты, как работать со сравнением 1995 и 2026, как вести себя при слабом retrieval и по каким критериям вообще можно считать систему готовой к следующему этапу.<br> В этой связи корректно считать выявленные замечания не признаком неудачи пилота, а его полезным и своевременным результатом. Пилот выполнил свою функцию: позволил увидеть реальные уязвимости до широкого использования инструмента и перевести их в набор конкретных продуктовых и инженерных контролей. Следующий этап проекта поэтому логично сосредоточен не на повторной переработке ingestion-слоя, а на закреплении финальной системной инструкции, проверке retrieval-политики, полном red-team прогоне и принятии решения о готовности продового бота на основе формализованного QA, а не интуитивной оценки.