Comments 93
Вы всегда будете гадать на кофейной гуще, если не можете обеспечить повторяемость.
А так ли уж она необходима?
Повторяемость чего? На каком уровне? С какими допусками?
Я уверен, что и сказки, и былины изустно передавали без повторяемости и с повторяемостью одновременно. Форма подачи менялась быстрее, передаваемый смысл - медленнее.
Повторяемость - не самоцель. Вы свою публикацию "Главная проблема использования ИИ (Иллюзии Интеллекта) при разработке ПО" могли написать другими словами. Более того, вы её точно напИшите другими словами, если попробуете изложить те же мысли ещё раз.
Если говорить за повторяемость результата, то для передачи одних и тех же идей разным людям вообще, иногда, нужно использовать разные формы (слова) - например, объяснить "как пройти в библиотеку" русскому, англичанину и французу.
Абсолютная повторяемость переоценена.
Бро, мы тут генерируем код, если он меняется при одинаковом промте, о чем мы вообще рассуждаем?
О назначении этого кода, бро. О задачах, которые он должен выполнять.
Нам не нужен одинаковый код, нам нужен одинаковый результат работы этого кода.
Вам же всё равно, как называются переменные в коде? Особенно, если вам его ни дебажить не надо, ни даже читать. Более того, вам всё равно какие алгоритмы используются внутри, если результат работы кода вас устраивает. Вам нужна повторяемость не на уровне кода, а на уровне результата.
Если промпт даёт повторяемость на уровне результата - то вот и вот.
А если нам результат работы кода нужен вообще один раз? Параметризированный промпт, который создаёт одноразовые программы. Возможно даже на разных ЯП.
Нам не нужен одинаковый код, нам нужен одинаковый результат работы этого кода.
А как проверить что результат работы не изменился при изменении кода?
Запустить тесты? Я угадал?
Верно. Но кто их будет писать? И что-то мне подсказывает, что писать их придётся, в таком случае, не меньше, чем пришлось бы написать кода. Ведь придётся проверять все сценарии.
А если вы сами пишите код, то вы его сразу пишите правильно и без ошибок? Или тоже пишете сценарии его проверки? Своего собственного кода?
Ну так вот, в случае кодогенерации через промпты вам нужно сделать только половину работы - написать тесты. Причём не на все сценарии, а лишь на важные конкретно для этого результата. Впрочем, 100% code coverage уже давно не в моде, насколько мне известно. IMHO, profit.
Да, писать хорошие тесты сложно. Но в эпоху дипкода мы можем использовать синтетику. Мощные модели помогают генерировать тысячи граничных сценариев для проверки более слабых или быстрых моделей. Это не подгонка, а создание обучающего и валидационного контура, который гарантирует, что система не развалится при первом же обновлении API провайдером. Ну а если развалится, быстро можно затектить. Хотя пока что учитывая что эвалы не шибко развиты это отчасти вилами по воде
Если совместить опыт Magento, GitHub/JIRA-тикеты и кодогенерацию, то, в пределе, LLM-агенты могут в автомате (!) обновлять кодовую базу на проде по тикетам конечных пользователей.
Меня тут сейчас начнут пинать ногами за такие слова. Но это просто от недостатка воображения. Это действительно можно. Уже сейчас. Без всякого AGI :)
Да чего уж мелочиться. Путь огни сами и тикеты создают. Тогда им и пользователи вообще будут не нужны :-)
Я уверен, что где-то примерно так ПО уже сейчас и разрабатывают. Одни агенты пишут код, а другие его тестируют и пишут тикеты, которые первые разбирают и фиксят.
Это уже реальность. Где-то краем глаза видел про такой подход. Не запомнил, где именно. Я пока что считаю, что участие человека в контуре принятия решений (оценки результата) обязательным. Хотя бы при постановке задачи. Но лучше - при оценке результата (обучение, самое, что ни на есть) и ещё лучше - не в одно лицо, а массово ("судом присяжных"), а ещё лучше - если "все эти люди" заинтересованы в результатах правильной работы кода, который они оценивают.
Да, в такой "карусели" программисты действительно становятся не очень сильно нужными.
Могу сказать что в яндекс внутреннем поиске так делают, так делают у меня в студии друга, майкрософте, дойче телекоме, в страйпе, это где проверенная информация
Если смотреть в корень любой инженерно-технической задачи, то главными в ней являются:
- правильная задача требований к функциям и условиям эксплуатации проектируемой системы (параметрам её работы);
- проверка, что созданная система удовлетворяет заданнным параметрам.
Как не странно, так создают вооружения. Военным нужно, чтобы используемое оружие решало определённые ими задачи. И на испытаниях проверяется то, что повторяются требуемые параметры срабатывания систем. А как достигается эта повторяемость, военным по фигу. Не по фигу это производителям, которым нужны технологические процессы, позволяющие обеспечить эту повторяемость. Но если новые техпроцессы типа аддитивных технологий и генеративного проектирования позволят производить хоть каждый раз разные изделия, но при этом эти разные изделия будут выдавать требуемые характеристики их эксплуатации, то и произволдителям повторяемость самих изделий тоже станет по фигу.
Конечно можно, вопрос только в качестве результата. Чем больше работы вы спихиваете на неразумный генератор текста, тем качество.
А почему генератор должен быть разумным?)
Программисты иногда тоже интересное выдают
Смысл автоматизации ведь в избавлении от недостатков и повышении качества. А так получается замена шила на мыло.
Ну не скажите. Многие вещи можно проверять куда быстрее. Опять таки переносить много рутины, вроде вынести в микросервис на фастапи кусок функционала, а потом когда убедиться что бизнес-логика ок и данные не теряются переписать на более эффективный стек, вроде гошки милое дело
Но опять таки, как мы ушли в сторону ИИ кодинга. если статья больше про способы машинного улучшения промптов для всяких тулов, например для gen агентов картинов или text2sql
Я больше скажу. Берешь claude code + mcp + linear (нафиг vibe kanban и тп тулы) и это уже работает
А чего пинать, часть ребят уже на это переходят, могу сказать что в яндексе начали активно пересаживаться на гибридную работу люди + агенты
М, там и так качество сервисов жиденькое, ждём вообще полный отстой 🤑
А где плотненькое?
Там где хотя бы аутентификация не ломается и аккаунты не создают вам без вашего ведома)
Ну то есть базовые вещи работают нормально))
Можно ещё вспомнить как их банк недавно задудосился об свою же акцию)) А все на Хабр приходят, rps считают, пыль в глаза))
Интересно даже что они там навайбкодят, если сейчас уже не вывозят свой функционал) Вы меня прям заинтересовали, интересно посмотреть))
Тикет: ошибка в интерфейсе, отсутствует кнопка пополнить на 9999$ в личном кабинете. Кнопка должна в один клик сразу добавлять средства на баланс.
Какой-то оверинжиниринг. Похоже на попытку решения надуманной проблемы.
Это ведь в любом случае не уменьшает общей сложности самой программы. Вам в любом случае нужно описать её алгоритм. Будь то спецификация/промпт на естественном языке, либо исходный код на ЯП.
А что именно оверинжниринг? Вложенность комментов уже высокая, потерял суть
Мощные модели помогают генерировать тысячи граничных сценариев для проверки более слабых или быстрых моделей. Это не подгонка, а создание обучающего и валидационного контура, который гарантирует, что система не развалится при первом же обновлении API провайдером. Ну а если развалится, быстро можно затектить
Вот это нагромождение многоуровневых обвязок из агентов вокруг проблемы, закидывая это нерациональным количеством железа. Вместо решения самой проблемы - написания кода.
Так тесты, это же тоже код. А как вы писали, для кода повторяемость не важна, важен результат! Тогда удачи вам в постоянном переписывании тестов и подгонке результатов их работы под новые версии кода. :-)
TDD - сначала тесты, потом код. Код подгоняется под тесты, а не тесты под код.
Более того, тесты не всегда код (ручное тестирование). Более того, есть smoke tests, которые не зависят от сложности "под капотом" - их не нужно переписывать часто. Ну и наконец, есть пользователи, которые "тестируют на проде". Вы, может, будете смеяться, но я из экосистемы Magento - там это вполне себе нормальное явление. Протоптанные пользователями маршруты работают как часы, но шаг в сторону - и бага на баге.
Вы не поняли. Если у вас нет повторяемости кода и он меняется от запроса к запросу, то к коду тестов это тоже относиться. А если у вас плавает не только код программы, но и код тестов, то это чистое шаманство, и не важно как вы такие тесты называете.
ОК, давайте попробуем настроится на одну волну:
function add(a, b) {
return a + b;
}
const add = function(a, b) {
return a + b;
};
const add = (a, b) => a + b;Это разный JS-код или повторяющийся?
Мы фиксируем название, вход и выход (интерфейс) для некоторой функции и делаем набор тестов, которые описывают требуемое поведение (тестирование "чёрного ящика") - насколько велик может быть этот "чёрный ящик"?
Что для вас есть "повторяемость кода"?
Я писал не о "повторяемости кода", а о "повторяемости выполнения промптов". Это включает в себя "повторяемость кода" (так как код тоже является результатом выполнения промпта), но не ограничивается только им.
А смысл повторяемость в том, чтобы один и тот же рабочий проипт всегда выдавал рабочий код. Если вы сможете обеспечить гарантировнанную на 100% работоспособность разного кода, тогда вопросов нет. Однако практика показывает, что LLM как черный ящик не может даже просто повторить, что раньше уже корректно работало.
Однако практика показывает, что LLM как черный ящик не может даже просто повторить, что раньше уже корректно работало.
Возможно, у этого метода есть свои границы применимости и вы за них вышли?
LLM - это же вероятностная штука, если она даёт хотя бы 10% подходящих вариантов, то просто используйте подходящие варианты и не используйте неподходящие. У вас же есть критерии "корректно работало" - даёте на вход LLM битый код, критерии корректности и сообщение об ошибке. Потом отсекаете 90% неверных вариантов и используете первый попавшийся из "корректно работает". При соответствующем pipeline агент и сам делает то же самое.
А смысл повторяемость в том, чтобы один и тот же рабочий промпт
А это вам зачем? Вам же рабочий код нужен? Вернее даже - результат работы этого кода. Вам нужны дырки, а не свёрла.
100%-ю уверенность в том, что "дырки" получаются, как надо, даёт только практика (прод) - и ничего более. Тесты позволяют получить эту уверенность дешевле и безболезненнее (хотя уже и не на 100%). А вера в то, что ваш код работает так, как и планировалось... ну, у меня она, по-моему, в первый же год профдеятельности пропала. Но я не с железом дело имел, а с живыми пользователями. Они очень непредсказуемые. LLM на них чем-то похожи :)
Я не понимаю почему вас минусуют. Вполне адекватные вещи говорите. Если можно настроить пайплайн и отбрасывать плохой код, даже не доводя до пользователя, то даже если 1 из 50 генераций корректна это уже жестко окупается
А это вам зачем? Вам же рабочий код нужен? Вернее даже - результат работы этого кода. Вам нужны дырки, а не свёрла.
100%-ю уверенность в том, что "дырки" получаются, как надо, даёт только практика (прод) - и ничего более. Тесты позволяют получить эту уверенность дешевле и безболезненнее (хотя уже и не на 100%).
Допустим, нам нужна дырка 5мм. Ваш вариант мне видится так: берём сложного робота, который сам будет подбирать свёрла в диапазоне 4-6мм (примерно) и сверлить дырки; и потом мы с линейкой будем измерять полученные дырки; либо используем не менее сложного робота с линейкой (остаётся ещё вопрос на сколько точно этот робот будет измерять). И всё это вместо того, что бы самому выбрать сверло 5мм и просверлить дырки (можно даже станок использовать).
Ну дырка важнее инструмента, это кажется бесспорно, а стохастичность LLM данность, с которой нужно работать, а не бороться. Проблема в том, что веса модели постоянно меняются, и вчерашнее идеально подобранное сверло сегодня внезапно начинает делать брак. К тому же часто некая изменчивость генерации вполне подконтрольна
стохастичность LLM данность, с которой нужно работать, а не бороться
А лучше не применять такие инструменты там, где стохастичность не нужна.
Вы противник ИИ?
Я противник неуместного применения его.
Почему описанные подходы в статье на ваш взгляд нерациональны?
Я же правильно понимаю, что подход заключается в составлении инструкции на специальном формализованном (в какой-то степени) языке для генерации инструкции на неформализованном языке для получения инструкции на формализованном языке. Разве тут нет пары лишних шагов? Тут и так помимо меня немало критических комментариев оставили. Вряд ли я смогу объяснить нерациональность такого подхода понятней.
ну так в инженерном подходе мы фиксируем не текст промпта, а pipeline и метрику. Я вообще статью решил написать ибо по запросу на нормальные методы промптоптимизации какие-то СТАРы разбираются и ролевые модели с xml-тегами.
Если код меняется, но проходит тесты и выполняет задачу (как пишут ниже), то стохастичность становится управляемым параметром. Современные оптимизаторы используют рефлексию, чтобы анализировать эти самые изменения и оставлять только те "мутаблы промпта, которые дают стабильный результат на всей выборке данных.
Я уверен, что и сказки, и былины
Я не уверен, что и сказки, и былины были таковыми изначально...:-)
Не вижу другого способа обеспечить повторяемость, кроме как выкрутить температуру на 0. Но, боюсь, результат будет столь же повторяем, сколь и бесполезен.
Температура это "креативность" ответа и вероятность возникновения LLM галюцинаций, но это никак не влияете на его повторяемость (воспровизводимость).
Очень даже влияет. Температура говорит, насколько случайным должен быть выбор следующего токена. При температуре, равной нулю, выбор следующего токена должен основываться только на статистических данных, накопленных при обучении (по крайней мере, это ожидается от LLM). Конечно, 100 % повторяемости вы не получите на сети с миллиардами параметров, потому что ошибки FLOP будут накапливаться при прохождении сигнала между слоями и достигать существенных величин, а в любом реальном сервисе с более чем одним пользователем будет ещё и кэш.
При фиксированном seed, температура не будет влиять на воспроизводимость , т.е. для разных значений температуры ответы хоть и будут разные, но они будут всегда повторяться, тогда как если seed при каждом запросе будут меняться, то при при одной и той же температуре воспроизводимости уже не будет.
Приятно читать хоть чуть-чуть разбирающихся людей, а не про то что ИИ тупиковый путь
для разных значений температуры ответы хоть и будут разные, но они будут всегда повторяться,
Не понял. Вы хотите сказать, что каждому сочетанию температура+seed соответствует один и только один ответ сети?
Не понял. Вы хотите сказать, что каждому сочетанию температура+seed соответствует один и только один ответ сети?
Да, если все остальные входные данные так же остаются неизменными.
Алгоритм вычисления LLM фиксированный и определяется только конфигурацией её слоев. Чистая математика, которую при желании можно посчитать на калькуляторе (только будет очень долго), тогда как вариативность ответов обеспечивается входными данными и слоями, в которых используются случайные числа.
Если вы фиксируете seed, то убираете случайную составляющую между разными вызовами и при одинаковых входных данных всегда будете получать один и тот же результат.
Параметризация не единственный путь. Опять таки очень сильно зависит от сферы применения
Такое ощущение, что идеальный промпт будет стремиться к готовому коду :)
DSPy в помощь и этот подход динамично развивается
Ну Cucumber со своим Gherkin тоже поначалу динамично развивался. Но кто его использует сейчас? И кто будет писать на этом DSPy - менеджеры или программисты?
Сомневаюсь что обычным менеджерам это прям по силам. Опять таки замечу что кодинг тулы нормально так выросли над собой в том числе за счет костыльных hrpo /dspy like подходов. Сейчас еще RLM подъедет и заживем
Сомневаюсь что обычным менеджерам это прям по силам.
В том то и дело. Тогда для кого этот весь тулинг? Программистам ведь проще писать на формализованном языке, чем составлять заклинания на естественном языке, которые будут интерпретированы непредсказуемым образом.
Программисту как раз проще написать optimizer.compile(), чем неделями подбирать синонимы. Весь этот тулинг нужен, чтобы превратить промпт из текста в скомпилированный артефакт. И вообще сейчас наступает эра Deep Coding, где ИИ-агенты не просто пишут сниппеты, а сами оптимизируют свои внутренние цепочки через те же MIPROv2 . Мои разрабы и я не пишем не пишем сами толком уже
Так какой же это тогда программист? Чем он отличается от системного аналитика?
А зачем компании человек ходячий справочник языка который просто реализует по ТЗ скрипт?
Вы не поверите! Реализовать по ТЗ скрипт )
человек ходячий справочник языка
Это вы кодера описали )
А программист нужен, прежде всего, для заполнения неполноты ТЗ (а они не могут быть полными). А потом уже реализовать скрипт.
К такому?
Наука от шаманизма отличается предсказательной способностью. Пусть не полной, но хотя бы в каких-то рамках.
Цикл «а давайте тогда?..» -> «это лучше или хуже?..» -> goto step 1 это все еще шаманизм.
Наука от шаманизма отличается предсказательной способностью. Пусть не полной, но хотя бы в каких-то рамках.
Не только предсказательностью, но и воспроизводимостью.
Однако автору про это кажется неизвестно :-)
Окей, собственно сужение неопределенности генерации до таких пределов, что не шибко отличимо от дискретных алгоритмов чем не канает?)
В смысле, за n шагов мы на неизвестный процент приблизимся к неизвестной эффективности (но это не точно), такое сужение неопределенности?
Создание промтов как было искусством создания заклинаний, заставляющих Духа Машины сделать то, что нужно автору заклинания, так и осталось. Просто накопились некоторые экспериментальные знания, позволяющие процесс улучшить. Вот только есть две небольшие проблемы: сложно заранее предсказать что именно сделает Дух Машины под воздействием конкретного заклинания и сложно заставить Духа в точности повторить ранее выполненные действия. Да, повторяемость может быть не важна, но попробуйте работать с автомобилем, каждый экземпляр которого уникален
Спасибо за такой развернутый комментарий, постараюсь ответить также!
Это обалденная аналогия для мануального подхода, но статья как раз описывает отхождения этого
С инженерной точки зрения, ваша позиция игнорирует фундаментальный сдвиг: мы перестали пытаться договориться с Духом вручную и начали применять к нему алгоритмы стохастической оптимизации
Непресказумесоть не нова. В инженерии это решается переходом от оценки единичных ответов к оптимизации функции потерь на валидном датасете. Мы не предсказываем конкретный ответ, мы математически максимизируем вероятность правильного ответа по всей выборке, используя методы вроде упомянутых типо GEPA. Дает приятный прирост
Проблема повторяемости. Ну даже эмбедды чутка но отличаются. Тут у меня нет грамотных ответов, однако из того что вижу вполне решается превращением промптов из жесктие инструкции и продуманными эвалами. А еще решается костылями как у claude
"Гранд-тру датасет". Этот текст написан на стенах, табуретке, выдавлен на мыле и бесконечно повторяется на веревке...
P.S. На абажуре снятой с крюка люстры еще, и гравирован на самом крюке.
Ух. Что то я ничего не понял. Но было интересно почитать.
Как оптимизация промптов превратилась из шаманства в инженерную дисциплину