Я не понимаю почему вас минусуют. Вполне адекватные вещи говорите. Если можно настроить пайплайн и отбрасывать плохой код, даже не доводя до пользователя, то даже если 1 из 50 генераций корректна это уже жестко окупается
Могу сказать что в яндекс внутреннем поиске так делают, так делают у меня в студии друга, майкрософте, дойче телекоме, в страйпе, это где проверенная информация
Да, писать хорошие тесты сложно. Но в эпоху дипкода мы можем использовать синтетику. Мощные модели помогают генерировать тысячи граничных сценариев для проверки более слабых или быстрых моделей. Это не подгонка, а создание обучающего и валидационного контура, который гарантирует, что система не развалится при первом же обновлении API провайдером. Ну а если развалится, быстро можно затектить. Хотя пока что учитывая что эвалы не шибко развиты это отчасти вилами по воде
ну так в инженерном подходе мы фиксируем не текст промпта, а pipeline и метрику. Я вообще статью решил написать ибо по запросу на нормальные методы промптоптимизации какие-то СТАРы разбираются и ролевые модели с xml-тегами.
Если код меняется, но проходит тесты и выполняет задачу (как пишут ниже), то стохастичность становится управляемым параметром. Современные оптимизаторы используют рефлексию, чтобы анализировать эти самые изменения и оставлять только те "мутаблы промпта, которые дают стабильный результат на всей выборке данных.
Программисту как раз проще написать optimizer.compile(), чем неделями подбирать синонимы. Весь этот тулинг нужен, чтобы превратить промпт из текста в скомпилированный артефакт. И вообще сейчас наступает эра Deep Coding, где ИИ-агенты не просто пишут сниппеты, а сами оптимизируют свои внутренние цепочки через те же MIPROv2 . Мои разрабы и я не пишем не пишем сами толком уже
Ваш скепсис понятен, но вы путаете аналитическое решение (где результат предсказуем на 100% по формуле) с численными методами оптимизации. Обучение весов любой нейросети, это тоже итеративный процесс минимизации ошибки, но мы называем это Computer Science, а не шаманизмом
Спасибо за такой развернутый комментарий, постараюсь ответить также!
Это обалденная аналогия для мануального подхода, но статья как раз описывает отхождения этого
С инженерной точки зрения, ваша позиция игнорирует фундаментальный сдвиг: мы перестали пытаться договориться с Духом вручную и начали применять к нему алгоритмы стохастической оптимизации
Непресказумесоть не нова. В инженерии это решается переходом от оценки единичных ответов к оптимизации функции потерь на валидном датасете. Мы не предсказываем конкретный ответ, мы математически максимизируем вероятность правильного ответа по всей выборке, используя методы вроде упомянутых типо GEPA. Дает приятный прирост
Проблема повторяемости. Ну даже эмбедды чутка но отличаются. Тут у меня нет грамотных ответов, однако из того что вижу вполне решается превращением промптов из жесктие инструкции и продуманными эвалами. А еще решается костылями как у claude
Сомневаюсь что обычным менеджерам это прям по силам. Опять таки замечу что кодинг тулы нормально так выросли над собой в том числе за счет костыльных hrpo /dspy like подходов. Сейчас еще RLM подъедет и заживем
Это круто, но стоит относится не как к сверхразуму или замене специалиста (технологии далеко не на таком уровне), а скорее как к блокноту и тому что ты круто отрефлексировал!
Насчет советов - я четко обозначил позицию, это то чем я руководствуюсь и мои рекомендации, но я не психотерапевт. К тому же почему я вдруг должен нести ответственность за совет?
А зачем компании человек ходячий справочник языка который просто реализует по ТЗ скрипт?
Я не понимаю почему вас минусуют. Вполне адекватные вещи говорите. Если можно настроить пайплайн и отбрасывать плохой код, даже не доводя до пользователя, то даже если 1 из 50 генераций корректна это уже жестко окупается
Программисты иногда тоже интересное выдают
А почему генератор должен быть разумным?)
Могу сказать что в яндекс внутреннем поиске так делают, так делают у меня в студии друга, майкрософте, дойче телекоме, в страйпе, это где проверенная информация
А чего пинать, часть ребят уже на это переходят, могу сказать что в яндексе начали активно пересаживаться на гибридную работу люди + агенты
Я больше скажу. Берешь claude code + mcp + linear (нафиг vibe kanban и тп тулы) и это уже работает
Да, писать хорошие тесты сложно. Но в эпоху дипкода мы можем использовать синтетику. Мощные модели помогают генерировать тысячи граничных сценариев для проверки более слабых или быстрых моделей. Это не подгонка, а создание обучающего и валидационного контура, который гарантирует, что система не развалится при первом же обновлении API провайдером. Ну а если развалится, быстро можно затектить. Хотя пока что учитывая что эвалы не шибко развиты это отчасти вилами по воде
ну так в инженерном подходе мы фиксируем не текст промпта, а pipeline и метрику. Я вообще статью решил написать ибо по запросу на нормальные методы промптоптимизации какие-то СТАРы разбираются и ролевые модели с xml-тегами.
Если код меняется, но проходит тесты и выполняет задачу (как пишут ниже), то стохастичность становится управляемым параметром. Современные оптимизаторы используют рефлексию, чтобы анализировать эти самые изменения и оставлять только те "мутаблы промпта, которые дают стабильный результат на всей выборке данных.
Программисту как раз проще написать optimizer.compile(), чем неделями подбирать синонимы. Весь этот тулинг нужен, чтобы превратить промпт из текста в скомпилированный артефакт. И вообще сейчас наступает эра Deep Coding, где ИИ-агенты не просто пишут сниппеты, а сами оптимизируют свои внутренние цепочки через те же MIPROv2 . Мои разрабы и я не пишем не пишем сами толком уже
Ваш скепсис понятен, но вы путаете аналитическое решение (где результат предсказуем на 100% по формуле) с численными методами оптимизации. Обучение весов любой нейросети, это тоже итеративный процесс минимизации ошибки, но мы называем это Computer Science, а не шаманизмом
Спасибо за такой развернутый комментарий, постараюсь ответить также!
Это обалденная аналогия для мануального подхода, но статья как раз описывает отхождения этого
С инженерной точки зрения, ваша позиция игнорирует фундаментальный сдвиг: мы перестали пытаться договориться с Духом вручную и начали применять к нему алгоритмы стохастической оптимизации
Непресказумесоть не нова. В инженерии это решается переходом от оценки единичных ответов к оптимизации функции потерь на валидном датасете. Мы не предсказываем конкретный ответ, мы математически максимизируем вероятность правильного ответа по всей выборке, используя методы вроде упомянутых типо GEPA. Дает приятный прирост
Проблема повторяемости. Ну даже эмбедды чутка но отличаются. Тут у меня нет грамотных ответов, однако из того что вижу вполне решается превращением промптов из жесктие инструкции и продуманными эвалами. А еще решается костылями как у claude
Сомневаюсь что обычным менеджерам это прям по силам. Опять таки замечу что кодинг тулы нормально так выросли над собой в том числе за счет костыльных hrpo /dspy like подходов. Сейчас еще RLM подъедет и заживем
Окей, собственно сужение неопределенности генерации до таких пределов, что не шибко отличимо от дискретных алгоритмов чем не канает?)
DSPy в помощь и этот подход динамично развивается
Во многих случаях вполне достаточно некоторого набора энтропии, средства для этого уже есть
А так ли уж она необходима?
Это круто, но стоит относится не как к сверхразуму или замене специалиста (технологии далеко не на таком уровне), а скорее как к блокноту и тому что ты круто отрефлексировал!
Окей!
Насчет советов - я четко обозначил позицию, это то чем я руководствуюсь и мои рекомендации, но я не психотерапевт. К тому же почему я вдруг должен нести ответственность за совет?