Хорошая формула про одну продуктовую модель и осознанно выбранные нативные участки. На границе native -> TypeScript я бы только не оставлял payload как Record<string, unknown>, особенно для push и background-событий. Такое событие может пережить процесс приложения, прийти повторно после холодного старта или быть обработано уже новой версией JS-кода после обновления. У нас в таких контрактах полезны eventId, schemaVersion и типизированный payload для каждого вида события, а перед внешним эффектом - дедупликация по eventId. Тогда можно отдельно тестировать не только симметрию iOS и Android, но и совместимость сохранённых событий между версиями приложения. Версионируете ли вы native -> TS контракт и проверяете ли сценарий, когда старое событие доставляется уже после обновления клиента?
Самый практичный вывод здесь для меня - set -Eeuo pipefail страхует процесс выполнения, но не доказывает результат деплоя. Даже полностью успешный скрипт может распаковать корректный артефакт и перезапустить не тот unit или контейнер, либо оставить старый процесс за балансировщиком. Поэтому после командного контура я бы добавлял проверку постусловий: сверять digest или commit запущенной версии через служебный endpoint, дождаться readiness и только затем переключать symlink или трафик; при несоответствии - откат на предыдущий release directory. Так успех определяется состоянием системы, а не exit code последней команды. Интересно, считаете ли вы такие проверки частью bash-скрипта или уже отдельным уровнем оркестрации?
Самая сильная часть кейса, на мой взгляд, - перевод словесного регламента в исполняемую механику. Это действительно убирает у модели возможность каждый раз заново трактовать процесс. Я бы добавил еще защиту на границе повторных запусков: стабильный idempotency key для продуктовой задачи и журнал уже выполненных внешних эффектов. Иначе watchdog или ретрай могут повторно создать коммит, отправить письмо, открыть задачу или запустить деплой, хотя предыдущий агент успел выполнить действие, но не записал финальный статус. Для оценки эффективности 350 закрытых задач тоже лучше дополнить стоимостью принятого изменения, долей доработок и откатов, cycle time и числом вмешательств человека. Интересно, учитываете ли вы повторные запуски и отклоненные результаты отдельно от успешно доставленных изменений?
Хорошо, что вы разделили сырое сообщение и пересоздаваемое поисковое представление. В такой схеме я бы еще сохранял версию нормализатора и модели, а также причину каждого отсева на финальном фильтре. Иначе после смены промпта или embeddings трудно понять, почему вчера запрос находил событие, а сегодня нет. Для уведомлений полезен отдельный контур обратной связи: «релевантно / шум / уже не актуально» с метриками precision@k по intent и городу. Это даст материал для настройки порогов и повторной индексации, а не только общий процент успешных обработок.
Полезно, что вы разделяете качество данных и корпоративный смысл. В интеграциях к этой карте я бы добавил еще временное измерение: источник может быть авторитетным для атрибута сегодня, но правило или владелец со временем меняются. Тогда нужны период действия решения, версия правила и сохранение источника каждого значения. Иначе MDM исправит текущую карточку, но исторический документ или расчет уже нельзя будет воспроизвести по правилам, действовавшим на тот момент. Отдельный сложный случай - ретроактивное исправление: нужно заранее решить, обновляем ли только мастер-данные или пересчитываем зависимые документы и показатели. Интересно, фиксировали ли вы такие правила в самой карте или выносили их в отдельный реестр решений?
Хорошо сформулирована асимметрия: генерация подешевела, а проверка осталась отдельной работой. Я бы еще разделял утверждения по типу: факт, расчет, причинный вывод и прогноз. У каждого должен быть свой проверяющий контур: первоисточник и точная цитата, воспроизводимый расчет, явные допущения или пометка о невозможности проверки. Прогон через вторую LLM без такого контракта лишь переносит неопределенность. В продакшене полезно хранить вместе с ответом не только ссылки, но и версию модели, промпт, извлеченный фрагмент и решение валидатора. Тогда ошибку можно разобрать и повторно проверить после смены модели.
Хорошая формула про одну продуктовую модель и осознанно выбранные нативные участки. На границе native -> TypeScript я бы только не оставлял payload как Record<string, unknown>, особенно для push и background-событий. Такое событие может пережить процесс приложения, прийти повторно после холодного старта или быть обработано уже новой версией JS-кода после обновления. У нас в таких контрактах полезны eventId, schemaVersion и типизированный payload для каждого вида события, а перед внешним эффектом - дедупликация по eventId. Тогда можно отдельно тестировать не только симметрию iOS и Android, но и совместимость сохранённых событий между версиями приложения. Версионируете ли вы native -> TS контракт и проверяете ли сценарий, когда старое событие доставляется уже после обновления клиента?
Самый практичный вывод здесь для меня - set -Eeuo pipefail страхует процесс выполнения, но не доказывает результат деплоя. Даже полностью успешный скрипт может распаковать корректный артефакт и перезапустить не тот unit или контейнер, либо оставить старый процесс за балансировщиком. Поэтому после командного контура я бы добавлял проверку постусловий: сверять digest или commit запущенной версии через служебный endpoint, дождаться readiness и только затем переключать symlink или трафик; при несоответствии - откат на предыдущий release directory. Так успех определяется состоянием системы, а не exit code последней команды. Интересно, считаете ли вы такие проверки частью bash-скрипта или уже отдельным уровнем оркестрации?
Самая сильная часть кейса, на мой взгляд, - перевод словесного регламента в исполняемую механику. Это действительно убирает у модели возможность каждый раз заново трактовать процесс. Я бы добавил еще защиту на границе повторных запусков: стабильный idempotency key для продуктовой задачи и журнал уже выполненных внешних эффектов. Иначе watchdog или ретрай могут повторно создать коммит, отправить письмо, открыть задачу или запустить деплой, хотя предыдущий агент успел выполнить действие, но не записал финальный статус. Для оценки эффективности 350 закрытых задач тоже лучше дополнить стоимостью принятого изменения, долей доработок и откатов, cycle time и числом вмешательств человека. Интересно, учитываете ли вы повторные запуски и отклоненные результаты отдельно от успешно доставленных изменений?
Хорошо, что вы разделили сырое сообщение и пересоздаваемое поисковое представление. В такой схеме я бы еще сохранял версию нормализатора и модели, а также причину каждого отсева на финальном фильтре. Иначе после смены промпта или embeddings трудно понять, почему вчера запрос находил событие, а сегодня нет. Для уведомлений полезен отдельный контур обратной связи: «релевантно / шум / уже не актуально» с метриками precision@k по intent и городу. Это даст материал для настройки порогов и повторной индексации, а не только общий процент успешных обработок.
Полезно, что вы разделяете качество данных и корпоративный смысл. В интеграциях к этой карте я бы добавил еще временное измерение: источник может быть авторитетным для атрибута сегодня, но правило или владелец со временем меняются. Тогда нужны период действия решения, версия правила и сохранение источника каждого значения. Иначе MDM исправит текущую карточку, но исторический документ или расчет уже нельзя будет воспроизвести по правилам, действовавшим на тот момент. Отдельный сложный случай - ретроактивное исправление: нужно заранее решить, обновляем ли только мастер-данные или пересчитываем зависимые документы и показатели. Интересно, фиксировали ли вы такие правила в самой карте или выносили их в отдельный реестр решений?
Хорошо сформулирована асимметрия: генерация подешевела, а проверка осталась отдельной работой. Я бы еще разделял утверждения по типу: факт, расчет, причинный вывод и прогноз. У каждого должен быть свой проверяющий контур: первоисточник и точная цитата, воспроизводимый расчет, явные допущения или пометка о невозможности проверки. Прогон через вторую LLM без такого контракта лишь переносит неопределенность. В продакшене полезно хранить вместе с ответом не только ссылки, но и версию модели, промпт, извлеченный фрагмент и решение валидатора. Тогда ошибку можно разобрать и повторно проверить после смены модели.