Опять вы почему-то настаиваете, что если у вас стохастическая система, то гарантировать ничего нельзя. Но, во-первых, любая система отчасти стохастическая. Во-вторых, можно с определенной вероятностью. Вы же понимаете разницу между вероятностью безотказной работы 99,9 % и 0.1%.
завтра юзер напишет ту же мысль, но другими словами, и база тестов радостно загорится зеленым, а прод снова упадет.
значит вы не пофиксили суть проблемы и не смогли воспроизвести ее в тестах. В вашем случае тест считается состоявшимся если модель сгенерировала пустой промпт, а фикс рабочим если приложение от этого не сломалось.
мы тестируем им валидатор, а не стохастический "черный ящик" так сказать
Это не отменяет необходимость делать е2е тесты, а то получится что компонент отдельно протестирован и работает, а когда выкатили систему с ним на прод - она при первом сообщении упала, потому что просто не проверили все вместе.
Я бы очень сомневался стоит ли сайнофить такой релиз на прод, если есть известные режимы работы системы которые приводили к инцидентам и которые не проверены в е2е тестах.
А если удалось вручную протестить е2е, вроде вы сами об этом писали, то стоит подумать с нейронками, как бы это засунуть в регрессию, чтобы потом случайно не разломать - для этого же регрессия и нужна.
Промпт там не просто текст, это жесткая детерминированная карта тегов ([VERDICT:], [TASK:], [STAGE:]),
А у вас логи не сохранились? Можно же просто послать в модель весь контекст который был на тот момент у модели и она по идее должна опять зависнуть с какой-то вероятностью, Вы же утверждаете что она может сама по себе зависнуть при некотором контексте, и так можно проверить ваш валидатор почти в e2e тесте.
ловить такие глухие защиты нужно динамически и на лету.
С тем что нужно в рантайме уметь обрабатывать ошибки в том числе пустые ответы никто не спорит) Но я за то что некоторые сценарии которые стрельнули на проде стоит добавить в регрессию.
А если температуру 0 поставить воспроизводится? А если неколько раз прогнать и порог частоты воспроизведения подобрать и необходимое число испытаний? Взять в охапку ChatGPT и подумать с ней как здесь могут помочь матстат и теория надёжности.
покажут зелёный свет, а в проде баг всё равно выстрелит
Aways has been. И это ника не отменяет необходимость делать тесты, тобы не получилось почти как в анекдоте, выкатили новую версию с фиксами, пришёл чувак с тем же запросам и все опять упало) А потом ещё и выяснится что на том самом poison message новый солюшн даже и не проверяли...
ловить приходится только динамически и прямо на лету, как раз через валидатор.
Так это не отменяет необходимость QAить динамический валидатор, а тут и тот самый промпт пригодится
Проблема в том, что работа с базой в состоянии RO не была поддержана на уровне нашего облачного фреймворка — рантайм сервиса просто отказывался стартовать. Задача лежала в плане, и в некотором роде это был контролируемый риск, но так получилось
А что бы вы посоветовали, чтобы митигировать подобные риски? Например, единая система чейнж менеджмента с ревью итд, или обязательный онбординг на прод внутренних сервисов, который бы отлавливал такие баги.
control plane умеет атомарно изменять записи? А что с добавлением и удалением? Я веду к тому что там за структура данных такая для мапы, которую можно на лету и читать и менять или там лочется вся мапа на чтение при изменении, но тогда это стопнет весь бизнес поток
Опять вы почему-то настаиваете, что если у вас стохастическая система, то гарантировать ничего нельзя. Но, во-первых, любая система отчасти стохастическая. Во-вторых, можно с определенной вероятностью. Вы же понимаете разницу между вероятностью безотказной работы 99,9 % и 0.1%.
значит вы не пофиксили суть проблемы и не смогли воспроизвести ее в тестах. В вашем случае тест считается состоявшимся если модель сгенерировала пустой промпт, а фикс рабочим если приложение от этого не сломалось.
Это не отменяет необходимость делать е2е тесты, а то получится что компонент отдельно протестирован и работает, а когда выкатили систему с ним на прод - она при первом сообщении упала, потому что просто не проверили все вместе.
Я бы очень сомневался стоит ли сайнофить такой релиз на прод, если есть известные режимы работы системы которые приводили к инцидентам и которые не проверены в е2е тестах.
А если удалось вручную протестить е2е, вроде вы сами об этом писали, то стоит подумать с нейронками, как бы это засунуть в регрессию, чтобы потом случайно не разломать - для этого же регрессия и нужна.
Но дело хозяйское)
А у вас логи не сохранились? Можно же просто послать в модель весь контекст который был на тот момент у модели и она по идее должна опять зависнуть с какой-то вероятностью, Вы же утверждаете что она может сама по себе зависнуть при некотором контексте, и так можно проверить ваш валидатор почти в e2e тесте.
С тем что нужно в рантайме уметь обрабатывать ошибки в том числе пустые ответы никто не спорит) Но я за то что некоторые сценарии которые стрельнули на проде стоит добавить в регрессию.
А если температуру 0 поставить воспроизводится? А если неколько раз прогнать и порог частоты воспроизведения подобрать и необходимое число испытаний? Взять в охапку ChatGPT и подумать с ней как здесь могут помочь матстат и теория надёжности.
Aways has been. И это ника не отменяет необходимость делать тесты, тобы не получилось почти как в анекдоте, выкатили новую версию с фиксами, пришёл чувак с тем же запросам и все опять упало) А потом ещё и выяснится что на том самом poison message новый солюшн даже и не проверяли...
Так это не отменяет необходимость QAить динамический валидатор, а тут и тот самый промпт пригодится
Почему нельзя? Более того, он у вас уже есть - тот самый промпт на котором генерился пустой ответ.
tps это хорошо но и ttft тоже надо бы указывать а еще заполненость контекста на тот момент
Квантовый компьютер решил задачу по генерации квантового состояния)
Думаю вы уже сами должны были догадаться, что ваш тезис про "никаких проблем" был слишком наивен.
А ну то есть всё-таки видите проблемы в виде дополнительных рисков?
И что это куча инженеров будет делать без инфры, сидеть молиться?)
Спасибо
Спасибо за увлекательную статью и поучительную)
А что бы вы посоветовали, чтобы митигировать подобные риски? Например, единая система чейнж менеджмента с ревью итд, или обязательный онбординг на прод внутренних сервисов, который бы отлавливал такие баги.
Правда нет? А как вы будете прод сапортить без инфры?)
Почему вы не померили сколько стоит рост контекста за счёт связей, насколько увеличивается время ответа итд.
И как здесь статический анализатор поможет в агентском цикле обратной связи, если он ошибок не возвращает?
Ну да, там не вся хэш мапа лочится, а только список в конкретном бакете спинлоком.
https://github.com/torvalds/linux/blob/0f23d56f17fdfc7db69d51f64c8b91bbab947aa9/kernel/bpf/hashtab.c#L83
control plane умеет атомарно изменять записи? А что с добавлением и удалением? Я веду к тому что там за структура данных такая для мапы, которую можно на лету и читать и менять или там лочется вся мапа на чтение при изменении, но тогда это стопнет весь бизнес поток
А как с гонками разбираться, если налету мапы политик обновлять?
это продакт называется, и до этого тоже был продакт
а что они сделали в итоге и почему ии агенты не могут сделать также?
Проще но быстрее ли?
А по поводу новых контрактов - вы же уже их добавляете, переводя условный целочисленный формат биржи в вещественные числа например.
А зачем числа с плавающей точкой? нельзя обойтись целочисленной математикой, если количество цифр после запятой известно из протокола биржи например.