Ну, есть гипотеза, что это может быть - как насчёт оружия, одного экземпляра которого достаточно для уничтожения крупного мегаполиса - чем не путь к обожествлению?..
Любая информация по айти может оказаться галлюцинацией. На stack overflow полно неточных или просто мусорных ответов, и даже самые залайканные ответы могут быть верны для ситуации из вопроса, но нерелевантны твоей проблеме(например, использование зависимости, которая у тебя в компании запрещена по политикам безопасности или ещё что-то). Более того - официальные доки тоже могут врать, не далее как неделю назад боролся с багом - по официальной документации 2 метода формирования запроса к бд в орм должны давать абсолютно идентичный результат, а он вообще нихрена не, и, как показал дебаг - в моем случае(подозреваю, что не самом экзотическом) и не должен был быть.
Это ж не повод отказываться от официальных доков и SO. Точно так же и с нейронками - если внедрять llm driven development или stack overflow driven development, то, скорее всего, рано или поздно выстрелит(но не факт). А если ко всему подходить, как говорится, with a grain of salt и по принципу доктора Хауса - то вполне рабочая штука. Просто у нейронок характер вранья отличается от "человеческого", это надо учитывать, но это не блокер.
Нет, чтобы нейронка условно описала какую-то функцию как "вывод в консоль" в то время как на самом деле она делает rm -rf - это надо, чтобы 1) по этой функции не было или почти не было доступной инфы, которую она выдаст 2) "правдоподобный" нафантазированный ответ говорил про консоль вместо удаления - но это, например, значит, что название функции что-то типа logToConsole, а не deleteAll, и как она тогда под капотом что-то удаляет - вопрос. Нейронка старается в ситуациях, где нет инфы, сгенерить что-то внешне консистентное, а это значит, что для прям радикального вранья и то, о чем спрашивают, должно иметь проблемы с внутренней консистентностью. Да ещё и не быть сильно известным(чтобы включить фантазии у нейронки). А точно ли этим стоит пользоваться вообще?
Более реалистичный пример фантазий - это скорее что-то типа, не знаю, метода, в который параметром кидают какую-то величину + единицу измерения - нейронка, не имея инфы, легко нафантазирует, что это объект из двух полей, хотя на самом деле автор по каким-то соображениям сделал строковый формат через пробел. Вот такое да, с хорошим шансом будет переврано, но так ли это критично и непроверяемо?
Ну, проведу аналогию. Есть фреймворк актуальной версии 2.0, в 10% контрактов отличающийся от 1.0. Так вышло, что доков по актуальной версии у вас нет, но есть по первой. Его точно нет смысла читать из-за 10% неверной инфы? Или после прочтения будет довольно неплохое представление, что к чему, а с расхождениями можно уже и на практике разобраться?
Это вероятностный вопрос - чем "известнее" инфа, которую спрашиваешь, тем больше шанс, что суждения нейронки будут правильными. И да, стопроцентные галлюцинации(прям все нафантазировано) - это сильно менее вероятно, чем "все верно", если тема популярная, ну а самый вероятный исход - в основном верно, но по каким-то пунктам будет враньё. Как инструкция или учебник - не годится, но как "взгляд с высоты птичьего полета" - вполне. Ну и что значит не узнаю - если я планирую дальше пользоваться тем, про что спрашивал, то крупные нестыковки вылезут очень быстро. Просто надо эти шансы ошибок учитывать и не верить на слово.
Самое интересное, что ИИшка реально очень удобна в быту или учебе личного характера, то есть физическому лицу прям очень хорошо может зайти, потому что цена галлюцинации не очень высокая(ну, главное, до жизненно важных вопросов допускайте с осторожностью). Мне очень понравилось её спрашивать в качестве ликбеза по незнакомой технологии - сначала "дай краткое описание, что и зачем", потом "составь айсберг возможностей" и в конце "сделай роадмап, как написать такую штуку с нуля" - сразу понимаешь общую картину и примерные границы применения, а по нюансам уже можно и вне ИИ читать. Ни учебник, ни форумы так не умеют. Мясной напарник умеет, но как-то неудобно человека от работы отрывать ради удовлетворения любопытства. А ИИшку - пожалуйста. И да, в деталях она может подвирать, это нужно учитывать, но общую картину даст неплохо, если технология не супер малоизвестная.
Но вот бизнес, где цена ошибки иная - это уже совсем другая история(с)
Я ни разу не гуру, но мне всегда казалось, что базово всегда надо делать sql и нормализации. А не надо только в том случае, когда формат данных может сильно меняться со временем по составу и структуре полей, причем надо поддерживать все варианты - и старые, и новые. Вот в такой ситуации да, монго или аналоги уменьшат боль(но не уберут полностью). А если данные просто сложные(пардон за), но более-менее одни и те же по структуре - ну потрать время на нормальную структуру табличек:)
Интересно, а не прокатило ли бы такое решение: запускаем локально самую бюджетную по ресурсам нейронку, задача которой - определить, что запрос юзера уже был раньше(по смыслу, конечно, не посимвольно), а ответы того же гигачата сохраняем в условном редисе в виде "вопрос-ответ" и соответственно при матчинге берём из него вместо того, чтобы лезть вовне и жечь лишние токены?
Не ИИ-фанат, но как по мне - революция тут скорее не в том, ЧТО ищут, а в формате ответа, который в плане гибкой настройки не имеет конкурентов. Я сам решаю, насколько глубоко копать и как выдать результат - например, мне очень понравилось в ИИ спрашивать про какие-то технологии в виде "дай ответ в виде айсберга от общеизвестного к эзотерике", более-менее понятно и то, на каком ты уровне понимания, и что подтянуть. Да, это не заменит учебник со структурированным изложением, но давайте честно - не все и не во всех задачах готовы долго что-то изучать, часто результат нужен здесь и быстро. В этом плане ИИшка прям работает(при условии, что к её выдаче нужно сохранять здоровый скепсис типа "наверное, так, проверю, но может и соврать").
ИИ- не кодер, ИИ- техпис. Вместо картинок и описаний можно легко накидать MVP-шку с абы каким какчеством кода и моками вместо данных, главное - ее пощупают юзеры, скажут "тут норм, тут не то, тут вообще не этого хотели", rinse, repeat- и вот когда оно стабилизировалось, можно фиксировать в ТЗ (каркас которого тоже доверить ИИ). Авось что-то из навайбкоденного и в разработке пригодится(но это уже необязательно).
Вот точно помню, что где-то в классической НФ был рассказ про мужика, из-за сбоя в каком-то оборудовании отразившимся зеркально - то есть чел тот же, личность та же, но вся биология поменялась с лево- на декстро- и наоборот. Кончилось ЕМНИП плохо(но для ограниченного круга лиц, никакого апокалипсиса).
Имхо. Для себя придумал 5 вопросов к задаче, которые должны в качестве rule of thumb помочь определить, годная задача для ллмизации или не.
1) входные данные, приводящие к одному результату, могут сильно варьироваться (условно приход-расход для сведения баланса- только если строки переставлять, а вот запрос, куда бы слетать в отпуск- очень большое поле того, как это можно сформулировать) и не очень поддаются стандартизации через UI?
2) выходные данные, удовлетворяющие пользователя для его входных данных, также могут сильно варьироваться (те же примеры- мне не нужно "что-то похожее на мои расходы за месяц", и даже правильный ответ, но римскими цифрами или в двоичной СС способен как минимум удивить- а вот рекомендации по отпуску я приму в куче вариантов, от простого текста до списка с приоритетами)?
3) Мала ли цена ошибки для пользователя и просто ли её найти(опять же деньги вещь критичная, а вот полететь в условно Катар вместо ОАЭ, хотя ОАЭ подошло бы лучше- да ничего особо страшного)?
4) Много ли релевантной моей задачи информации в сети и (чуть хуже) в литературе, чтобы ллм имела корпус данных для адекватного ответа вместо галлюцинаций?
5) Могу ли я придумать для этой задачи идеального мясного исполнителя- кто он, какой бэкграунд, скиллы и прочее (это скорее уже для генерации промпта, но если ответ "нет"- возможно, вы хотите странного и странное ллм вам и выдаст)?
Чем больше ответов "да" - тем ЛЛМнее задача. Собственно, кодогенерация для программиста - скорее "да" в 1 и 2(потому что тз обычно на человеческом языке со всей его неопределенностью, а сам код хотя и гораздо более детерминирован, но все равно и переменные можно называть по-разному, и одну и ту же вещь чуть по-разному закодить...), не очень уверенное "да" в 3 (ошибки могут быть критичными, но много средств их ловли до появления), твердое "да" в 4 и 5- то есть не идеально, но определенно в позитивной зоне.
Имхо пока(возможно, в будущем поменяется) rule of thumb - чем однозначнее текстовый ответ на заданный вопрос, тем меньше подойдёт нейронка. Поэтому как раз обычные тексты на человеческом языке, которые можно миллионом вариантов сформулировать - отличное поле для деятельности, код- в целом похуже, но тоже достаточно вариативный, а вот условно числовые примеры- неа.
Я как-то в начале ИИ-хайпа(3 или следующая за ней чатгпт) хотел её научить мокать продовые данные - условно, пользователь ввел какое-то нечто, которое уронило страничку, вот возьми его данные, замени их на более-менее реальные моки с сохранением предположительного проблемного места и отдай дальше для дебага. Вот простейший даже не для джуна, а для просто более-менее адекватного человека кейс "в адресе нету номера дома"(типа условно Магнитогорск, улица Ленина, квартира 17) мне ей пришлось реально танцуя с бубном объяснять в стиле "а посмотри вот сюда внимательно, может быть, вот именно тут что-то подозрительно?", ну и чот я как-то засомневался в универсальности технологии с тех пор(хотя казалось бы, как раз вот такие задачи, которые плохо формализуются, но хорошо делаются просто обычным живым человеком- идеальное поле для нейронок).
Что касается увольнений - то имхо тут цимес для менеджеров в них самих, бо низко висящий фрукт в плане экономии денег. А ИИ- это та самая прикормка, с которой можно и одуреть: типа ты не просто уволил чувака, а как бы с дешёвой ему заменой(но слово "как бы" тут не просто так).
При этом я не то чтобы скептик и считаю, что само создание ИИ в нынешнем виде - крутой прорыв, который много чего может дать, на уровне изобретения микроскопа. И, как и микроскоп, у ИИ есть границы применимости, не надо им забивать гвозди(хотя в теории можно, почему нет).
Если у этих оптимизаторов бизнес начнёт такую же динамику цены давать, как Твиттер после покупки Маском - их акционеры живьём сожрут в извращённой форме...
Ну можно бахнуть на каждое нажатие клавиши и добавить адекватный дебаунс, так что не так все страшно, но вопрос- зачем- всё ещё остаётся. Выглядит как довольно редкий кейс.
Я, наверное, отстал от жизни и трендов, но объясните кто-нибудь - какую проблему решают все эти танцы с бубном вместо лобового constraint unique в базе как источнике истины и обработке эксепшена вставки? Если мы констрейнт не сделали(а почему? что, настолько всё плохо с производительностью?), то риски того, что все эти проверки рано или поздно дадут сбой, все равно остаются и если реализуются- возможны очень неприятные баги. Если сделали- то так и так какая-то обработка эксепшена вставки не помешает(ну в лог хоть кинуть, да и просто правило хорошего тона), так почему бы и не сделать в коде отдельную "штатную" веточку для такого кейса? При этом количество запросов будет минимально возможное- ну то есть буквально ровно тот один, который нам по-любому делать для вставки. Не, ну я могу в теории придумать кейс, когда проверки до вставки могут иметь смысл - например, если мы хотим валидировать пользовательский ввод на уникальность ещё до сабмита формы, ну, тогда да. Но такое надо бы отдельно уточнить- и накладно, и с ТЗ информбезопасности могут быть вопросики.
Ага, а потом без констрейнта, но с лимит 1 всё же по какой-то причине (например, баг фронта с дублированием запросов на создание- ну, скажем, useEffect с напортаченными депсами) таки будет дубль в бд и будет веселая ловля шрединбага "а почему у юзера покупка не прошла/прошла бесплатно"?)
Почему второе(если действительно докажут изоморфизм этих задач) проблема- понятно, а первое почему? Это же буквально тот самый "бэкдор", сложно обратимая операция, которая и позволяет нам использовать эту механику для асимметричного шифрования.
Ну, есть гипотеза, что это может быть - как насчёт оружия, одного экземпляра которого достаточно для уничтожения крупного мегаполиса - чем не путь к обожествлению?..
... А, ну да.
Любая информация по айти может оказаться галлюцинацией. На stack overflow полно неточных или просто мусорных ответов, и даже самые залайканные ответы могут быть верны для ситуации из вопроса, но нерелевантны твоей проблеме(например, использование зависимости, которая у тебя в компании запрещена по политикам безопасности или ещё что-то). Более того - официальные доки тоже могут врать, не далее как неделю назад боролся с багом - по официальной документации 2 метода формирования запроса к бд в орм должны давать абсолютно идентичный результат, а он вообще нихрена не, и, как показал дебаг - в моем случае(подозреваю, что не самом экзотическом) и не должен был быть.
Это ж не повод отказываться от официальных доков и SO. Точно так же и с нейронками - если внедрять llm driven development или stack overflow driven development, то, скорее всего, рано или поздно выстрелит(но не факт). А если ко всему подходить, как говорится, with a grain of salt и по принципу доктора Хауса - то вполне рабочая штука. Просто у нейронок характер вранья отличается от "человеческого", это надо учитывать, но это не блокер.
Нет, чтобы нейронка условно описала какую-то функцию как "вывод в консоль" в то время как на самом деле она делает rm -rf - это надо, чтобы 1) по этой функции не было или почти не было доступной инфы, которую она выдаст 2) "правдоподобный" нафантазированный ответ говорил про консоль вместо удаления - но это, например, значит, что название функции что-то типа logToConsole, а не deleteAll, и как она тогда под капотом что-то удаляет - вопрос. Нейронка старается в ситуациях, где нет инфы, сгенерить что-то внешне консистентное, а это значит, что для прям радикального вранья и то, о чем спрашивают, должно иметь проблемы с внутренней консистентностью. Да ещё и не быть сильно известным(чтобы включить фантазии у нейронки). А точно ли этим стоит пользоваться вообще?
Более реалистичный пример фантазий - это скорее что-то типа, не знаю, метода, в который параметром кидают какую-то величину + единицу измерения - нейронка, не имея инфы, легко нафантазирует, что это объект из двух полей, хотя на самом деле автор по каким-то соображениям сделал строковый формат через пробел. Вот такое да, с хорошим шансом будет переврано, но так ли это критично и непроверяемо?
Ну, проведу аналогию. Есть фреймворк актуальной версии 2.0, в 10% контрактов отличающийся от 1.0. Так вышло, что доков по актуальной версии у вас нет, но есть по первой. Его точно нет смысла читать из-за 10% неверной инфы? Или после прочтения будет довольно неплохое представление, что к чему, а с расхождениями можно уже и на практике разобраться?
Это вероятностный вопрос - чем "известнее" инфа, которую спрашиваешь, тем больше шанс, что суждения нейронки будут правильными. И да, стопроцентные галлюцинации(прям все нафантазировано) - это сильно менее вероятно, чем "все верно", если тема популярная, ну а самый вероятный исход - в основном верно, но по каким-то пунктам будет враньё. Как инструкция или учебник - не годится, но как "взгляд с высоты птичьего полета" - вполне. Ну и что значит не узнаю - если я планирую дальше пользоваться тем, про что спрашивал, то крупные нестыковки вылезут очень быстро. Просто надо эти шансы ошибок учитывать и не верить на слово.
Самое интересное, что ИИшка реально очень удобна в быту или учебе личного характера, то есть физическому лицу прям очень хорошо может зайти, потому что цена галлюцинации не очень высокая(ну, главное, до жизненно важных вопросов допускайте с осторожностью). Мне очень понравилось её спрашивать в качестве ликбеза по незнакомой технологии - сначала "дай краткое описание, что и зачем", потом "составь айсберг возможностей" и в конце "сделай роадмап, как написать такую штуку с нуля" - сразу понимаешь общую картину и примерные границы применения, а по нюансам уже можно и вне ИИ читать. Ни учебник, ни форумы так не умеют. Мясной напарник умеет, но как-то неудобно человека от работы отрывать ради удовлетворения любопытства. А ИИшку - пожалуйста. И да, в деталях она может подвирать, это нужно учитывать, но общую картину даст неплохо, если технология не супер малоизвестная.
Но вот бизнес, где цена ошибки иная - это уже совсем другая история(с)
Я ни разу не гуру, но мне всегда казалось, что базово всегда надо делать sql и нормализации. А не надо только в том случае, когда формат данных может сильно меняться со временем по составу и структуре полей, причем надо поддерживать все варианты - и старые, и новые. Вот в такой ситуации да, монго или аналоги уменьшат боль(но не уберут полностью). А если данные просто сложные(пардон за), но более-менее одни и те же по структуре - ну потрать время на нормальную структуру табличек:)
Интересно, а не прокатило ли бы такое решение: запускаем локально самую бюджетную по ресурсам нейронку, задача которой - определить, что запрос юзера уже был раньше(по смыслу, конечно, не посимвольно), а ответы того же гигачата сохраняем в условном редисе в виде "вопрос-ответ" и соответственно при матчинге берём из него вместо того, чтобы лезть вовне и жечь лишние токены?
Не ИИ-фанат, но как по мне - революция тут скорее не в том, ЧТО ищут, а в формате ответа, который в плане гибкой настройки не имеет конкурентов. Я сам решаю, насколько глубоко копать и как выдать результат - например, мне очень понравилось в ИИ спрашивать про какие-то технологии в виде "дай ответ в виде айсберга от общеизвестного к эзотерике", более-менее понятно и то, на каком ты уровне понимания, и что подтянуть. Да, это не заменит учебник со структурированным изложением, но давайте честно - не все и не во всех задачах готовы долго что-то изучать, часто результат нужен здесь и быстро. В этом плане ИИшка прям работает(при условии, что к её выдаче нужно сохранять здоровый скепсис типа "наверное, так, проверю, но может и соврать").
ИИ- не кодер, ИИ- техпис. Вместо картинок и описаний можно легко накидать MVP-шку с абы каким какчеством кода и моками вместо данных, главное - ее пощупают юзеры, скажут "тут норм, тут не то, тут вообще не этого хотели", rinse, repeat- и вот когда оно стабилизировалось, можно фиксировать в ТЗ (каркас которого тоже доверить ИИ). Авось что-то из навайбкоденного и в разработке пригодится(но это уже необязательно).
Вот точно помню, что где-то в классической НФ был рассказ про мужика, из-за сбоя в каком-то оборудовании отразившимся зеркально - то есть чел тот же, личность та же, но вся биология поменялась с лево- на декстро- и наоборот. Кончилось ЕМНИП плохо(но для ограниченного круга лиц, никакого апокалипсиса).
Имхо. Для себя придумал 5 вопросов к задаче, которые должны в качестве rule of thumb помочь определить, годная задача для ллмизации или не.
1) входные данные, приводящие к одному результату, могут сильно варьироваться (условно приход-расход для сведения баланса- только если строки переставлять, а вот запрос, куда бы слетать в отпуск- очень большое поле того, как это можно сформулировать) и не очень поддаются стандартизации через UI?
2) выходные данные, удовлетворяющие пользователя для его входных данных, также могут сильно варьироваться (те же примеры- мне не нужно "что-то похожее на мои расходы за месяц", и даже правильный ответ, но римскими цифрами или в двоичной СС способен как минимум удивить- а вот рекомендации по отпуску я приму в куче вариантов, от простого текста до списка с приоритетами)?
3) Мала ли цена ошибки для пользователя и просто ли её найти(опять же деньги вещь критичная, а вот полететь в условно Катар вместо ОАЭ, хотя ОАЭ подошло бы лучше- да ничего особо страшного)?
4) Много ли релевантной моей задачи информации в сети и (чуть хуже) в литературе, чтобы ллм имела корпус данных для адекватного ответа вместо галлюцинаций?
5) Могу ли я придумать для этой задачи идеального мясного исполнителя- кто он, какой бэкграунд, скиллы и прочее (это скорее уже для генерации промпта, но если ответ "нет"- возможно, вы хотите странного и странное ллм вам и выдаст)?
Чем больше ответов "да" - тем ЛЛМнее задача. Собственно, кодогенерация для программиста - скорее "да" в 1 и 2(потому что тз обычно на человеческом языке со всей его неопределенностью, а сам код хотя и гораздо более детерминирован, но все равно и переменные можно называть по-разному, и одну и ту же вещь чуть по-разному закодить...), не очень уверенное "да" в 3 (ошибки могут быть критичными, но много средств их ловли до появления), твердое "да" в 4 и 5- то есть не идеально, но определенно в позитивной зоне.
А эта лекция - для колхозников!(С)
Имхо пока(возможно, в будущем поменяется) rule of thumb - чем однозначнее текстовый ответ на заданный вопрос, тем меньше подойдёт нейронка. Поэтому как раз обычные тексты на человеческом языке, которые можно миллионом вариантов сформулировать - отличное поле для деятельности, код- в целом похуже, но тоже достаточно вариативный, а вот условно числовые примеры- неа.
Я как-то в начале ИИ-хайпа(3 или следующая за ней чатгпт) хотел её научить мокать продовые данные - условно, пользователь ввел какое-то нечто, которое уронило страничку, вот возьми его данные, замени их на более-менее реальные моки с сохранением предположительного проблемного места и отдай дальше для дебага. Вот простейший даже не для джуна, а для просто более-менее адекватного человека кейс "в адресе нету номера дома"(типа условно Магнитогорск, улица Ленина, квартира 17) мне ей пришлось реально танцуя с бубном объяснять в стиле "а посмотри вот сюда внимательно, может быть, вот именно тут что-то подозрительно?", ну и чот я как-то засомневался в универсальности технологии с тех пор(хотя казалось бы, как раз вот такие задачи, которые плохо формализуются, но хорошо делаются просто обычным живым человеком- идеальное поле для нейронок).
Что касается увольнений - то имхо тут цимес для менеджеров в них самих, бо низко висящий фрукт в плане экономии денег. А ИИ- это та самая прикормка, с которой можно и одуреть: типа ты не просто уволил чувака, а как бы с дешёвой ему заменой(но слово "как бы" тут не просто так).
При этом я не то чтобы скептик и считаю, что само создание ИИ в нынешнем виде - крутой прорыв, который много чего может дать, на уровне изобретения микроскопа. И, как и микроскоп, у ИИ есть границы применимости, не надо им забивать гвозди(хотя в теории можно, почему нет).
Если у этих оптимизаторов бизнес начнёт такую же динамику цены давать, как Твиттер после покупки Маском - их акционеры живьём сожрут в извращённой форме...
Ну можно бахнуть на каждое нажатие клавиши и добавить адекватный дебаунс, так что не так все страшно, но вопрос- зачем- всё ещё остаётся. Выглядит как довольно редкий кейс.
Я, наверное, отстал от жизни и трендов, но объясните кто-нибудь - какую проблему решают все эти танцы с бубном вместо лобового constraint unique в базе как источнике истины и обработке эксепшена вставки? Если мы констрейнт не сделали(а почему? что, настолько всё плохо с производительностью?), то риски того, что все эти проверки рано или поздно дадут сбой, все равно остаются и если реализуются- возможны очень неприятные баги. Если сделали- то так и так какая-то обработка эксепшена вставки не помешает(ну в лог хоть кинуть, да и просто правило хорошего тона), так почему бы и не сделать в коде отдельную "штатную" веточку для такого кейса? При этом количество запросов будет минимально возможное- ну то есть буквально ровно тот один, который нам по-любому делать для вставки. Не, ну я могу в теории придумать кейс, когда проверки до вставки могут иметь смысл - например, если мы хотим валидировать пользовательский ввод на уникальность ещё до сабмита формы, ну, тогда да. Но такое надо бы отдельно уточнить- и накладно, и с ТЗ информбезопасности могут быть вопросики.
Ага, а потом без констрейнта, но с лимит 1 всё же по какой-то причине (например, баг фронта с дублированием запросов на создание- ну, скажем, useEffect с напортаченными депсами) таки будет дубль в бд и будет веселая ловля шрединбага "а почему у юзера покупка не прошла/прошла бесплатно"?)
Почему второе(если действительно докажут изоморфизм этих задач) проблема- понятно, а первое почему? Это же буквально тот самый "бэкдор", сложно обратимая операция, которая и позволяет нам использовать эту механику для асимметричного шифрования.