Аргумент про confidence-слои интересный, но он не решает проблему, а сдвигает её на этаж выше — и вот почему. Confidence-оценка — это не гарантия истинности, а гарантия калибровки модели относительно самой себя. Слой “степени уверенности” отражает, насколько модель уверена в своём ответе исходя из внутренних активаций и распределения вероятностей токенов — а не то, насколько ответ соответствует внешней реальности. Модель может быть уверенно неправа: если в обучающих данных был системный паттерн-искажение (устаревший регламент, ошибочная маркировка, смещённая выборка), высокая уверенность будет присвоена именно неверному ответу. Это классическая проблема aleatoric vs epistemic uncertainty — слой уверенности хорошо ловит “я не знаю, потому что не видел таких данных”, но плохо ловит “я видел много таких данных, но они были ошибочны”. Даже с RAG и грounding проблема не исчезает, а меняет форму. Модель может уверенно и с высоким confidence-score извлечь релевантный документ, но неверно интерпретировать его в контексте конкретного кейса — это не галлюцинация фактов, а галлюцинация применимости. Ни один confidence-слой сегодня не оценивает “правильно ли я применил это правило именно к этой ситуации с этими нюансами” — а это ровно то, что в банке называется business logic verification, и именно об этом писал я в статье, а не о фактологических галлюцинациях в чистом виде. И главное — даже идеальная калибровка не убирает вопрос порога. Допустим, у модели появится безупречный confidence-score. Кто-то всё равно должен решить: при каком уровне уверенности агент действует автономно, а при каком передаёт решение человеку? 95%? 99.9%? Для возврата 500 рублей и для блокировки счёта клиента порог должен быть разный. Это решение — не техническое, а бизнес-этическое, и принимает его не модель (у неё нет ответственности), а аналитик или риск-менеджер. То есть даже в вашем сценарии “AI не врёт” аналитик не исчезает — он просто переходит от верификации фактов к калибровке порогов допуска, что я и описывал в разделе про Аналитика 4.0 (границы автономии, эскалация, human-in-the-loop). Так что оговорка про домен не лишняя: в необратимых сценариях порог допустимой ошибки стремится к нулю независимо от того, насколько хорош confidence-слой — а установить и защитить перед регулятором этот порог всё равно работа человека.
Мысль про “не подгонять LLM под старые модели проектирования, а пересобрать сам конвейер под его природу” — сильная и справедливая, особенно для той части рынка, где заказчик действительно готов принимать сырые быстрые итерации без прода. Это по сути другой вид контракта с заказчиком, а не другой вид аналитика — и это стоит явно проговаривать на старте проекта, а не молчаливо подстраивать методологию под ограничения модели.
Но здесь важна оговорка про домен. В банке (и в любой регулируемой среде — финансы, медицина, инфраструктура) “выпустить, что разработалось” физически невозможно как модель работы: есть комплаенс, аудит, ответственность перед регулятором и клиентом за деньги и данные. Там “односеансовый выпуск с контрактом” — это не ускорение, а перекладывание риска на этап после релиза, где он стоит в разы дороже. Поэтому мой тезис не “совмещать ежа с ужом”, а разделять зоны: там, где ошибка дешёвая и обратимая — да, можно и нужно резать конвейер под скорость LLM; там, где дорогая и необратимая — верификация человеком не накладные расходы, а то, что легитимизирует сам выпуск.
Про “прохиндеев на рынке разработки” — согласен, что демпинг ценой и сроками через “AI сделает быстро” уже происходит, и это реальный риск для качества индустрии в целом. Но именно поэтому ценность аналитика, умеющего отличить “быстро и достаточно” от “быстро и потом расхлёбывать”, будет расти, а не падать — конкуренция за скорость обесценивает ремесленника, но не обесценивает того, кто решает, где скорость уместна, а где нет.
Спасибо за развёрнутую метафору с прохожими — она хорошо описывает главный риск, о котором писал: доверие непроверенному ответу без верификации. Но здесь принципиальная разница: прохожий не даёт вам инструмент проверить свой ответ, а LLM — даёт (можно попросить показать источник, ход рассуждения, трассировку к данным). Проблема не в том, что модель иногда «врёт как прохожий», а в том, готов ли аналитик каждый раз требовать эту трассировку, а не верить красивому ответу с первого раза — именно это я и называю новым минимумом профессии, а не старым SRS-ГОСТом.
С пунктом про «это уже не вы вчерашний» согласен полностью — навыки действительно перестраиваются, я и пишу об этом (смещение от написания требований к верификации и оркестрации). Но не готов называть это отдельной специальностью «вайб-аналитик»: смещение фокуса навыков происходило и раньше (1.0 → 2.0 → 3.0), профессия каждый раз менялась, но не переименовывалась — менялся набор инструментов, а не суть роли: разобраться, что нужно бизнесу, и нести ответственность за результат.
Аргумент про confidence-слои интересный, но он не решает проблему, а сдвигает её на этаж выше — и вот почему. Confidence-оценка — это не гарантия истинности, а гарантия калибровки модели относительно самой себя. Слой “степени уверенности” отражает, насколько модель уверена в своём ответе исходя из внутренних активаций и распределения вероятностей токенов — а не то, насколько ответ соответствует внешней реальности. Модель может быть уверенно неправа: если в обучающих данных был системный паттерн-искажение (устаревший регламент, ошибочная маркировка, смещённая выборка), высокая уверенность будет присвоена именно неверному ответу. Это классическая проблема aleatoric vs epistemic uncertainty — слой уверенности хорошо ловит “я не знаю, потому что не видел таких данных”, но плохо ловит “я видел много таких данных, но они были ошибочны”. Даже с RAG и грounding проблема не исчезает, а меняет форму. Модель может уверенно и с высоким confidence-score извлечь релевантный документ, но неверно интерпретировать его в контексте конкретного кейса — это не галлюцинация фактов, а галлюцинация применимости. Ни один confidence-слой сегодня не оценивает “правильно ли я применил это правило именно к этой ситуации с этими нюансами” — а это ровно то, что в банке называется business logic verification, и именно об этом писал я в статье, а не о фактологических галлюцинациях в чистом виде. И главное — даже идеальная калибровка не убирает вопрос порога. Допустим, у модели появится безупречный confidence-score. Кто-то всё равно должен решить: при каком уровне уверенности агент действует автономно, а при каком передаёт решение человеку? 95%? 99.9%? Для возврата 500 рублей и для блокировки счёта клиента порог должен быть разный. Это решение — не техническое, а бизнес-этическое, и принимает его не модель (у неё нет ответственности), а аналитик или риск-менеджер. То есть даже в вашем сценарии “AI не врёт” аналитик не исчезает — он просто переходит от верификации фактов к калибровке порогов допуска, что я и описывал в разделе про Аналитика 4.0 (границы автономии, эскалация, human-in-the-loop). Так что оговорка про домен не лишняя: в необратимых сценариях порог допустимой ошибки стремится к нулю независимо от того, насколько хорош confidence-слой — а установить и защитить перед регулятором этот порог всё равно работа человека.
Мысль про “не подгонять LLM под старые модели проектирования, а пересобрать сам конвейер под его природу” — сильная и справедливая, особенно для той части рынка, где заказчик действительно готов принимать сырые быстрые итерации без прода. Это по сути другой вид контракта с заказчиком, а не другой вид аналитика — и это стоит явно проговаривать на старте проекта, а не молчаливо подстраивать методологию под ограничения модели.
Но здесь важна оговорка про домен. В банке (и в любой регулируемой среде — финансы, медицина, инфраструктура) “выпустить, что разработалось” физически невозможно как модель работы: есть комплаенс, аудит, ответственность перед регулятором и клиентом за деньги и данные. Там “односеансовый выпуск с контрактом” — это не ускорение, а перекладывание риска на этап после релиза, где он стоит в разы дороже. Поэтому мой тезис не “совмещать ежа с ужом”, а разделять зоны: там, где ошибка дешёвая и обратимая — да, можно и нужно резать конвейер под скорость LLM; там, где дорогая и необратимая — верификация человеком не накладные расходы, а то, что легитимизирует сам выпуск.
Про “прохиндеев на рынке разработки” — согласен, что демпинг ценой и сроками через “AI сделает быстро” уже происходит, и это реальный риск для качества индустрии в целом. Но именно поэтому ценность аналитика, умеющего отличить “быстро и достаточно” от “быстро и потом расхлёбывать”, будет расти, а не падать — конкуренция за скорость обесценивает ремесленника, но не обесценивает того, кто решает, где скорость уместна, а где нет.
Спасибо за развёрнутую метафору с прохожими — она хорошо описывает главный риск, о котором писал: доверие непроверенному ответу без верификации. Но здесь принципиальная разница: прохожий не даёт вам инструмент проверить свой ответ, а LLM — даёт (можно попросить показать источник, ход рассуждения, трассировку к данным). Проблема не в том, что модель иногда «врёт как прохожий», а в том, готов ли аналитик каждый раз требовать эту трассировку, а не верить красивому ответу с первого раза — именно это я и называю новым минимумом профессии, а не старым SRS-ГОСТом.
С пунктом про «это уже не вы вчерашний» согласен полностью — навыки действительно перестраиваются, я и пишу об этом (смещение от написания требований к верификации и оркестрации). Но не готов называть это отдельной специальностью «вайб-аналитик»: смещение фокуса навыков происходило и раньше (1.0 → 2.0 → 3.0), профессия каждый раз менялась, но не переименовывалась — менялся набор инструментов, а не суть роли: разобраться, что нужно бизнесу, и нести ответственность за результат.