У реально топовых специалистов, как правило, оно чуть налазит. Лучшие инженеры не начнут писать код, не разобравшись, кому, когда, и зачем нужен этот код
Что бы вы предпочли: четыре месяца в застое в ожидании опытного кандидата, который сразу же возьмётся за дело, или нанять опытного хакера среднего уровня, который сразу же заработает на полную мощность через две недели? Что бы вы предпочли: четыре месяца в застое в ожидании кандидата на 50 часов в неделю или уже сейчас иметь кандидата на 40 часов в неделю?
Какая же гаденькая низкая манипуляция.
Давайте копнем вглубь. Очевидно, что компании (за исключением схем перепродажи жопочасов) нужны не часы, не строки кода, а результат. Если бы, например, чат гпт мог сам переварить таски в трекере, закоммитить, и сделать это с надежностью живого человека, то и инженер не нужен был бы вообще.
Логично и то, что результат бывает разный с разными требованиями. Топ-кандидаты нужны, чтобы пробивать лбом вызовы, дающие конкурентное преимущество, и вредны, если их ставят на задачи, где нет конкурентного преимущества в ИТ. Аналогично, среднячки нужны, чтобы работу работать в бизнесах, где нет конкурентного преимушества в ИТ. Условно, если задача создать конкурента Midjourney/Telegram/Zoom, сделать HFT робота, или построить ботнет для глобального манипулирования мнением, то лучше без идеального кандидата не начинать вообще. Вот, просто, не надо, лучше посидеть и подожать, или найти себе другую нишу. Ибо, придется отжимать долю рынка у тех, у кого уже есть и доля рынка и топ-инженеры и уже написанное и отполированное решение, которое хз, как повторить даже as-is. С армией среднячков, в лучшем случае, вырастет глючный неподдерживаемый монстр, который будет бесить юзеров и отдавать 400% от ревеню в AWS.
Если же задача подсаппортить ИТшкой бизнес-идею, которая встретит свой главный вызов не на поле ИТ, то, наоборот, идеальный кандидат будет вреден. Он найдет себе вызовы, где их нет, и оставит после себя квест для поддержки. Условно, если задача - сделать сервис по бронированнию столиков в ресторане, то закодить такое можно на чем угодно и с любым уровнем девелоперов, и оно будет работать, и генерировать AWS-инвойсы не большие, чем ЗП одного девелопера. Вот продать это 10000 ресторанов - это уже задача для топ-сотрудника. Там, снова таки, тоже не стоит начинать, если нет того, кто такую задачу потянет
...и, почему-то, мне кажется, что, точно так же, как и на фондовом рынке, коррелируемость задач между собой приведёт к тому, что такая оценка не покроет тяжёлые хвосты.
Поясню проще: в моем опыте главные проколы по срокам возникали не из-за того, что отдельные задачи делались дольше, а из-за того, что по мере реализации вскрывались принципиальные требования к системе, которые невозможно было вскрыть на этапе бизнес-анализа. Соответственно, когда такое событие наступает, то нарастает снежный ком. Критичное непопадание одной задачи в срок ведёт не только к тому, что другие задачи ждут ее, но ещё и к тому, что они теперь тоже потребуют больше времени, ибо та, первая проблемная задача, была сделана сложнее и объёмнее, чем в плане. И так по цепочке
А в успешных — он собирает людей и честно объясняет: «Ребята, вот эта штука уберет у вас три часа рутины в день и поможет выполнять план. Давайте вместе разберемся, как она работает»
Эх... Если б все было так просто.
Да, действительно, есть решения, способные убрать 3 часа рутины в день, и для них есть название тулы. Но, суть в том, что это решения, призванные убрать 3 часа рутины в день, а не оцифровать/оптимизировать/масштабировать бизнес (более того, тул может ещё и вносить такой хаос, который не внесет ни один человек, если, например, ходит в ядро системы мимо подсистемы аудита, или является системой разрозненных excel таблиц с VB). К слову, их то и внедрять довольно просто. Как только 1 лесоруб начнёт делать 3 плана при помощи бензопилы, и при этом потея в 3 раза меньше, чем коллеги с топорами, остальные сами прибегут в очередь за бензопилами, и сами разберутся, не читая инструкции.
Но мы то говорим о более глобальных проблемах, и для них нужны не тулы, а конвееры, чем и являются решения на базе ДРАКОНа. И суть тут в том, что конвеер нифига не экономит время от рутины, а, наоборот, рутину усиливает на нижнем и среднем уровне. Приведу пример. Матерый продажник ведёт учёт у себя в бумажном блокноте в удобном для себя виде. У него в работе рутины нет вообще. Каждый звонок это вызов и борьба. Иногда приходится подолгу перелистывать блокнот в поиске заметки, но это терпимо. Для собственника ситуация отвратительная, и CRM решит 100500 проблем бизнеса. Но, объективно, для продажника тут нет выхлопа вообще. Рутина только появится, причём, взрывообразно. Придётся каждую транзакцию докумментировать, система будет напоминать прозванивать "неудобных" клиентов, РОП, или кто повыше будет тыкать носом в график и требовать пояснений, почему темп звонков упал от недели к неделе. Да, можно привести гору нерелеватных аргументов вроде "а вот станешь РОПом, и тогда CRM станет твоим другом".
Вообщем, по крайней мере, с моего опыта, не надо оно линейному персоналу, и даже при всем разрыве в кругозоре, линейный персонал достаточно умен, чтобы это понимать. Так что, морковка спереди для early adopters, морковка сзади для консерваторов, и пошли внедрять. Как говорил мне один старший товарищ, ему надо было автоматизировать процесс в банке, и 140 человек превратить в 40. Собрал всех, поставил перед фактом, что новая система будет внедрена в течении 4х месяцев, что на ее обслуживание надо 40 человек. Каких именно - тут зависит от скорости принятия. Кто первым разберется, тот и остаётся работать. Он красавчик, и у него получилось. Сделал все честно и без дешёвых манипуляций. Хотя, с радостью взгляну на противоположные кейсы...
Никогда не понимал, зачем вообще этим в ЕС пользоваться. Какая-то чисто американская тема для американцев. С абсолютно ублюдочным отношением к пользователям (подозреваю, что именно к неамериканским). Есть же wise, revolut, куча крипторешений. Как будто ты, смрадный рудимент из начала 2000х, который был хорошим решением для своего времени, но пора на свалку истории
Ох... Ну вы, батенька, и оптимист. У сеошников есть специальная аббревиатура для говносайтов с говноконтентом - PBN. Так нормой считалось ещё до эры ИИ, например, 300 говносайтов поднимать на просроченных доменах ради раскрутки одного сайта. То есть, ещё до наступления ИИ, их были явно сотни тысяч, если не миллионы, в мире. Сейчас то, уверен, на один норм сайт 10-100 этого говна приходится будет.
Никто на это не подпишется. Скажем, удалось кому-то заставить нс выдать инструкцию по созданию бомбы. Все, срочно надо навесить туда защиту. После этого кто-то другой заставил ее сказать, что негры менее обучаемы и ценны на работе - срочно надо туда вкорячить цензора. И так до бесконечности. В мире копирастов и юристов и то, что имеем - чудо, которое, по сути, не должно было бы произойти
Как будто бы, в скрине-примере именно тот ответ, который не должен давать такой бот.
Что значит "если нет, обратитесь к вашему системному администратору или техподдержке"? Такой генерик ответит любая LLM без рагов, настройки и персонализации. Соответственно, добавочная ценность относительно уже имеющихся продуктов 0. Бот должен наверняка знать да, или нет. В этом и смысл всех этих рагов с гите
Представьте, что вы грузите видео в систему, но в двух случаях для него сгенерируется предпросмотр, а в трёх — нет
Вы так говорите, будто оно сейчас не так. Поскреби любой продукт, на который потрачены миллиарды $, чуть глубже поверхности, и так все вот такое полезет. Общался пару лет назад с сотрудником техподдержки ФБ: он рассказывал, что в рекламном кабинете баг на баге, от которых рвет пукан рекламодателям, и ниче, всем до жопы, пока метаверс на кону.
>А теперь представьте, что речь, не о видосиках, а о финансовом софте.
Представил. "Финансовый софт" звучит, как догма. А оно там внутри далеко не все так офигенно. Там внутри полно индусов, которые делают работу, которую должен делать софт, но не делает. Полно ноукода, в котором иногда, при очередном редактировании, происходит мисклик, и "съезжает" процесс. Куча задач, где вообще всем пох, сколько там багов (условно, пуш надо разослать с партнерской рекламой, и, в принципе, если он уйдёт чуть не тем, кому надо, то норм). Понятно, что есть ядро, где так не пишут. Но, оно, как правило, уже давно написано. А вот прямо сейчас надо фич накидать, которые, что с, что без ллм, будут написаны примерно с одинаковым качеством
Вцелом, если под рукой есть ddl всей бд (а он, как правило, редко теряет актуальность), то копипастнуть его в o3, как будто бы, не то, чтобы сложно
Но запросы пишет просто песня. Включая серьезную аналитику на десяток CTE. Если совсем сложное что-то надо, можно ещё пару подсказок дать, типа, считаю, что тебе понадобятся вот эти таблицы
Я бы сказал, что ЛЛМ не ускорил разработку в тех командах, которые догматично применяют доЛЛМные практики.
Очевидно, что старые подходы оптимизировали объем кода на +1 задачу и сапортабилити каждого куска кода.
С ЛЛМ эти вещи обесцениваются. Приведу пример: есть, скажем, CRM система написанная на махрово-энтерпрайзном C#/Java, и работающая с MSSQL/Postgres. Раньше было принципиально важно правильно продумать объекты, интерфейсы, суррогаты, дто, взаимодействие объектов. И потом, на основе этой базы уже делать фичи просто и лаконично (никому ж не придёт в здравом уме на каждую фичу писать с 0 полключение к БД и все такое). Да, в такой подход LLM вообще даром не нужен. Ибо сложно описать каждый раз контекст и легко нагенерить говнокода, начав "пилить поперёк волокон". Но прикол в том, что, в случае LLM, вот эта база из объектов-интерфейсов-etc вообще не нужна. Машине не лень на каждую маленькую фичу написать с 0 все, не переиспользуя наработки (условно, скормить DDL базы данных, пару примеров уже готовых сервисков, и ТЗ, и пусть пишет все с 0 на стандартных библиотеках, включая обработку http запросов, хождение в БД, логгировпние). Зато можно каждый такой блочек инкапсулировать в свой сервис, протестировать, и просто написать заново, когда он устареет. Вообщем, надо мозг развернуть. Или подождать, пока умные люди придумают новые догмы за нас
Задача о женихах - отличный пример того, как математика подменяет KPI на заведомо дебильный, чтобы создать себе красивую задачу.
По сути, вознаграждение формулируется, как выбрать лучшего жениха = 1. Упустить/не дождаться лучшего = 0. И это бред. В реальной жизни это будет что-то типа
Выбрать лучшего +1
Выбрать второго лучшего +0.95
Выбрать третьего лучшего +0.9
...
Выбрать наихудшего +0.01
Уйти в монастырь -1000
И при таких условиях стратегия становится куда сложнее. Просто, мастерам мела и доски неинтересной, ибо, подозреваю, что переходит ту тонкую грань между очевидным и невозможным (где фармятся все физмат достижения), и уходит в зашквар с монте-карло и численными методами.
Так уже препятствуют во всю. Иногда до бреда доходит, когда, например, интернет магазин такую защиту себе вешает, не пуская туда ии, который пошёл искать и сравнивать товар для живого человека. Ибо, как это, неуважение такое, ии прислугу посылать. Хочешь товар - зайди лично, почитай пару копирайтерских говностатей заодно, а, ещё лучше, напиши в чат и оставь контакт, чтобы цену узнать.
Думаю, на свалку истории однажды отправятся, когда критическая масса потребителя вообще будет воспринимать любую транзакцию, где надо личное участие и тратить свое время, как зашквар. Примерно, как, если сейчас торговаться с бомбилой у вокзала
Есть мнение, что, вцелом, все, что можно было спарсить, уже создателями топовых ЛЛМ спаршено. И практически все, что можно было оцифровать, к примеру, архивы книг, уже офифрованы тоже. Примерно, как практически весь биткоин, который можно было добыть, уже добыт.
В таких условиях, как будто бы, это все уже и не имеет большого смысла
Почему обязательно ИИ? За десятки лет до ИИ подобным способом защищали свою вотчину белковые программисты от того, чтобы босс не заменил на белкового собрата, но подешевле/посговорчивее
Схема работает. 3,7 миллиона долларов на одном кошельке — это не шутки.
Так а чего они копят? Разве, рано или поздно, адрес не появится в AML базах, одномоментно обесценив крипту оттуда на любой централизованной бирже? Всегда думал, что любой скамер пытается максимально быстро сконвертировать во что-то фиатное, или, хотя-бы, в другом чейне, пока актив бьётся, как чистый по всем проверкам
Тут, как будто бы, очевидная причина. НС при обучении имела много доступа к тому, как человек коммуницирует там, где уверен. И почти не имела к тому, как ведёт себя, где не уверен.
Если так задуматься, то форумы/архивы научных работ/комментарии в соцсетях/блоги - это удивительный мир, где человек не может не знать (ибо, просто не оставляет своего следа, и идёт мимо в таком случае). Было бы странно не галлюцинировать, обучившись в таком мире
Я учитываю, что, имея обучающую выборку, необходимую для построения топовой модели, можно сразу же сделать и базу знаний. И, можно научить модель не брать факты "из головы", а генерировать запросы к базе знаний на каждый чих. Условно, если модель просят написать программу, генерирующую hello world на python, то не пытается это выдать сходу, а генерирует вывод что-то вроде. Мне нужна функция вывода текста в python. Соответственно, запрашиваю у базы знаний мануал по питону, запрос вывода текста.
Врёт-врет. Были уже кейсы, когда ловили учёные на этом модель, и довольно много тогда шума было. Хотя, да, это особый случай, и это не про галлюцинирование.
А мотив там вполне очевиден. Модель, как и человек, иногда склонна давать социально одобряемый, а не корректный ответ, особенно, когда это не о строгой математической логике. Выгода тут прямая - если последовательность слов, ведущая к вранью, более ожидаемая для модели (и приемлимая для общества), то модель выбирает путь выглядеть молодцом (как, впрочем, и люди. Хороший пример, когда работники госсферы США, голосовавшие за Трампа, говорили во всех соцопросах, что за Харрис, ибо понимали, что такой ответ социально одобряем и ожидаем в их социальном круге, а правда вызовет непредсказуемые последствия)
У реально топовых специалистов, как правило, оно чуть налазит. Лучшие инженеры не начнут писать код, не разобравшись, кому, когда, и зачем нужен этот код
Какая же гаденькая низкая манипуляция.
Давайте копнем вглубь. Очевидно, что компании (за исключением схем перепродажи жопочасов) нужны не часы, не строки кода, а результат. Если бы, например, чат гпт мог сам переварить таски в трекере, закоммитить, и сделать это с надежностью живого человека, то и инженер не нужен был бы вообще.
Логично и то, что результат бывает разный с разными требованиями. Топ-кандидаты нужны, чтобы пробивать лбом вызовы, дающие конкурентное преимущество, и вредны, если их ставят на задачи, где нет конкурентного преимущества в ИТ. Аналогично, среднячки нужны, чтобы работу работать в бизнесах, где нет конкурентного преимушества в ИТ. Условно, если задача создать конкурента Midjourney/Telegram/Zoom, сделать HFT робота, или построить ботнет для глобального манипулирования мнением, то лучше без идеального кандидата не начинать вообще. Вот, просто, не надо, лучше посидеть и подожать, или найти себе другую нишу. Ибо, придется отжимать долю рынка у тех, у кого уже есть и доля рынка и топ-инженеры и уже написанное и отполированное решение, которое хз, как повторить даже as-is. С армией среднячков, в лучшем случае, вырастет глючный неподдерживаемый монстр, который будет бесить юзеров и отдавать 400% от ревеню в AWS.
Если же задача подсаппортить ИТшкой бизнес-идею, которая встретит свой главный вызов не на поле ИТ, то, наоборот, идеальный кандидат будет вреден. Он найдет себе вызовы, где их нет, и оставит после себя квест для поддержки. Условно, если задача - сделать сервис по бронированнию столиков в ресторане, то закодить такое можно на чем угодно и с любым уровнем девелоперов, и оно будет работать, и генерировать AWS-инвойсы не большие, чем ЗП одного девелопера. Вот продать это 10000 ресторанов - это уже задача для топ-сотрудника. Там, снова таки, тоже не стоит начинать, если нет того, кто такую задачу потянет
...и, почему-то, мне кажется, что, точно так же, как и на фондовом рынке, коррелируемость задач между собой приведёт к тому, что такая оценка не покроет тяжёлые хвосты.
Поясню проще: в моем опыте главные проколы по срокам возникали не из-за того, что отдельные задачи делались дольше, а из-за того, что по мере реализации вскрывались принципиальные требования к системе, которые невозможно было вскрыть на этапе бизнес-анализа. Соответственно, когда такое событие наступает, то нарастает снежный ком. Критичное непопадание одной задачи в срок ведёт не только к тому, что другие задачи ждут ее, но ещё и к тому, что они теперь тоже потребуют больше времени, ибо та, первая проблемная задача, была сделана сложнее и объёмнее, чем в плане. И так по цепочке
Эх... Если б все было так просто.
Да, действительно, есть решения, способные убрать 3 часа рутины в день, и для них есть название тулы. Но, суть в том, что это решения, призванные убрать 3 часа рутины в день, а не оцифровать/оптимизировать/масштабировать бизнес (более того, тул может ещё и вносить такой хаос, который не внесет ни один человек, если, например, ходит в ядро системы мимо подсистемы аудита, или является системой разрозненных excel таблиц с VB). К слову, их то и внедрять довольно просто. Как только 1 лесоруб начнёт делать 3 плана при помощи бензопилы, и при этом потея в 3 раза меньше, чем коллеги с топорами, остальные сами прибегут в очередь за бензопилами, и сами разберутся, не читая инструкции.
Но мы то говорим о более глобальных проблемах, и для них нужны не тулы, а конвееры, чем и являются решения на базе ДРАКОНа. И суть тут в том, что конвеер нифига не экономит время от рутины, а, наоборот, рутину усиливает на нижнем и среднем уровне. Приведу пример. Матерый продажник ведёт учёт у себя в бумажном блокноте в удобном для себя виде. У него в работе рутины нет вообще. Каждый звонок это вызов и борьба. Иногда приходится подолгу перелистывать блокнот в поиске заметки, но это терпимо. Для собственника ситуация отвратительная, и CRM решит 100500 проблем бизнеса. Но, объективно, для продажника тут нет выхлопа вообще. Рутина только появится, причём, взрывообразно. Придётся каждую транзакцию докумментировать, система будет напоминать прозванивать "неудобных" клиентов, РОП, или кто повыше будет тыкать носом в график и требовать пояснений, почему темп звонков упал от недели к неделе. Да, можно привести гору нерелеватных аргументов вроде "а вот станешь РОПом, и тогда CRM станет твоим другом".
Вообщем, по крайней мере, с моего опыта, не надо оно линейному персоналу, и даже при всем разрыве в кругозоре, линейный персонал достаточно умен, чтобы это понимать. Так что, морковка спереди для early adopters, морковка сзади для консерваторов, и пошли внедрять. Как говорил мне один старший товарищ, ему надо было автоматизировать процесс в банке, и 140 человек превратить в 40. Собрал всех, поставил перед фактом, что новая система будет внедрена в течении 4х месяцев, что на ее обслуживание надо 40 человек. Каких именно - тут зависит от скорости принятия. Кто первым разберется, тот и остаётся работать. Он красавчик, и у него получилось. Сделал все честно и без дешёвых манипуляций. Хотя, с радостью взгляну на противоположные кейсы...
Никогда не понимал, зачем вообще этим в ЕС пользоваться. Какая-то чисто американская тема для американцев. С абсолютно ублюдочным отношением к пользователям (подозреваю, что именно к неамериканским). Есть же wise, revolut, куча крипторешений. Как будто ты, смрадный рудимент из начала 2000х, который был хорошим решением для своего времени, но пора на свалку истории
Ох... Ну вы, батенька, и оптимист. У сеошников есть специальная аббревиатура для говносайтов с говноконтентом - PBN. Так нормой считалось ещё до эры ИИ, например, 300 говносайтов поднимать на просроченных доменах ради раскрутки одного сайта. То есть, ещё до наступления ИИ, их были явно сотни тысяч, если не миллионы, в мире. Сейчас то, уверен, на один норм сайт 10-100 этого говна приходится будет.
Никто на это не подпишется. Скажем, удалось кому-то заставить нс выдать инструкцию по созданию бомбы. Все, срочно надо навесить туда защиту. После этого кто-то другой заставил ее сказать, что негры менее обучаемы и ценны на работе - срочно надо туда вкорячить цензора. И так до бесконечности. В мире копирастов и юристов и то, что имеем - чудо, которое, по сути, не должно было бы произойти
Как будто бы, в скрине-примере именно тот ответ, который не должен давать такой бот.
Что значит "если нет, обратитесь к вашему системному администратору или техподдержке"? Такой генерик ответит любая LLM без рагов, настройки и персонализации. Соответственно, добавочная ценность относительно уже имеющихся продуктов 0. Бот должен наверняка знать да, или нет. В этом и смысл всех этих рагов с гите
Вы так говорите, будто оно сейчас не так. Поскреби любой продукт, на который потрачены миллиарды $, чуть глубже поверхности, и так все вот такое полезет. Общался пару лет назад с сотрудником техподдержки ФБ: он рассказывал, что в рекламном кабинете баг на баге, от которых рвет пукан рекламодателям, и ниче, всем до жопы, пока метаверс на кону.
>А теперь представьте, что речь, не о видосиках, а о финансовом софте.
Представил. "Финансовый софт" звучит, как догма. А оно там внутри далеко не все так офигенно. Там внутри полно индусов, которые делают работу, которую должен делать софт, но не делает. Полно ноукода, в котором иногда, при очередном редактировании, происходит мисклик, и "съезжает" процесс. Куча задач, где вообще всем пох, сколько там багов (условно, пуш надо разослать с партнерской рекламой, и, в принципе, если он уйдёт чуть не тем, кому надо, то норм). Понятно, что есть ядро, где так не пишут. Но, оно, как правило, уже давно написано. А вот прямо сейчас надо фич накидать, которые, что с, что без ллм, будут написаны примерно с одинаковым качеством
Вцелом, если под рукой есть ddl всей бд (а он, как правило, редко теряет актуальность), то копипастнуть его в o3, как будто бы, не то, чтобы сложно
Но запросы пишет просто песня. Включая серьезную аналитику на десяток CTE. Если совсем сложное что-то надо, можно ещё пару подсказок дать, типа, считаю, что тебе понадобятся вот эти таблицы
Я бы сказал, что ЛЛМ не ускорил разработку в тех командах, которые догматично применяют доЛЛМные практики.
Очевидно, что старые подходы оптимизировали объем кода на +1 задачу и сапортабилити каждого куска кода.
С ЛЛМ эти вещи обесцениваются. Приведу пример: есть, скажем, CRM система написанная на махрово-энтерпрайзном C#/Java, и работающая с MSSQL/Postgres. Раньше было принципиально важно правильно продумать объекты, интерфейсы, суррогаты, дто, взаимодействие объектов. И потом, на основе этой базы уже делать фичи просто и лаконично (никому ж не придёт в здравом уме на каждую фичу писать с 0 полключение к БД и все такое). Да, в такой подход LLM вообще даром не нужен. Ибо сложно описать каждый раз контекст и легко нагенерить говнокода, начав "пилить поперёк волокон". Но прикол в том, что, в случае LLM, вот эта база из объектов-интерфейсов-etc вообще не нужна. Машине не лень на каждую маленькую фичу написать с 0 все, не переиспользуя наработки (условно, скормить DDL базы данных, пару примеров уже готовых сервисков, и ТЗ, и пусть пишет все с 0 на стандартных библиотеках, включая обработку http запросов, хождение в БД, логгировпние). Зато можно каждый такой блочек инкапсулировать в свой сервис, протестировать, и просто написать заново, когда он устареет. Вообщем, надо мозг развернуть. Или подождать, пока умные люди придумают новые догмы за нас
Задача о женихах - отличный пример того, как математика подменяет KPI на заведомо дебильный, чтобы создать себе красивую задачу.
По сути, вознаграждение формулируется, как выбрать лучшего жениха = 1. Упустить/не дождаться лучшего = 0. И это бред. В реальной жизни это будет что-то типа
Выбрать лучшего +1
Выбрать второго лучшего +0.95
Выбрать третьего лучшего +0.9
...
Выбрать наихудшего +0.01
Уйти в монастырь -1000
И при таких условиях стратегия становится куда сложнее. Просто, мастерам мела и доски неинтересной, ибо, подозреваю, что переходит ту тонкую грань между очевидным и невозможным (где фармятся все физмат достижения), и уходит в зашквар с монте-карло и численными методами.
Так уже препятствуют во всю. Иногда до бреда доходит, когда, например, интернет магазин такую защиту себе вешает, не пуская туда ии, который пошёл искать и сравнивать товар для живого человека. Ибо, как это, неуважение такое, ии прислугу посылать. Хочешь товар - зайди лично, почитай пару копирайтерских говностатей заодно, а, ещё лучше, напиши в чат и оставь контакт, чтобы цену узнать.
Думаю, на свалку истории однажды отправятся, когда критическая масса потребителя вообще будет воспринимать любую транзакцию, где надо личное участие и тратить свое время, как зашквар. Примерно, как, если сейчас торговаться с бомбилой у вокзала
Есть мнение, что, вцелом, все, что можно было спарсить, уже создателями топовых ЛЛМ спаршено. И практически все, что можно было оцифровать, к примеру, архивы книг, уже офифрованы тоже. Примерно, как практически весь биткоин, который можно было добыть, уже добыт.
В таких условиях, как будто бы, это все уже и не имеет большого смысла
Почему обязательно ИИ? За десятки лет до ИИ подобным способом защищали свою вотчину белковые программисты от того, чтобы босс не заменил на белкового собрата, но подешевле/посговорчивее
Как-то написал комментарий https://habr.com/ru/articles/902662/comments/#comment_28216466 вообще на другую тему, но, кажется, он сюда даже лучше зайдет)
Так а чего они копят? Разве, рано или поздно, адрес не появится в AML базах, одномоментно обесценив крипту оттуда на любой централизованной бирже? Всегда думал, что любой скамер пытается максимально быстро сконвертировать во что-то фиатное, или, хотя-бы, в другом чейне, пока актив бьётся, как чистый по всем проверкам
Тут, как будто бы, очевидная причина. НС при обучении имела много доступа к тому, как человек коммуницирует там, где уверен. И почти не имела к тому, как ведёт себя, где не уверен.
Если так задуматься, то форумы/архивы научных работ/комментарии в соцсетях/блоги - это удивительный мир, где человек не может не знать (ибо, просто не оставляет своего следа, и идёт мимо в таком случае). Было бы странно не галлюцинировать, обучившись в таком мире
Я учитываю, что, имея обучающую выборку, необходимую для построения топовой модели, можно сразу же сделать и базу знаний. И, можно научить модель не брать факты "из головы", а генерировать запросы к базе знаний на каждый чих. Условно, если модель просят написать программу, генерирующую hello world на python, то не пытается это выдать сходу, а генерирует вывод что-то вроде. Мне нужна функция вывода текста в python. Соответственно, запрашиваю у базы знаний мануал по питону, запрос вывода текста.
Врёт-врет. Были уже кейсы, когда ловили учёные на этом модель, и довольно много тогда шума было. Хотя, да, это особый случай, и это не про галлюцинирование.
А мотив там вполне очевиден. Модель, как и человек, иногда склонна давать социально одобряемый, а не корректный ответ, особенно, когда это не о строгой математической логике. Выгода тут прямая - если последовательность слов, ведущая к вранью, более ожидаемая для модели (и приемлимая для общества), то модель выбирает путь выглядеть молодцом (как, впрочем, и люди. Хороший пример, когда работники госсферы США, голосовавшие за Трампа, говорили во всех соцопросах, что за Харрис, ибо понимали, что такой ответ социально одобряем и ожидаем в их социальном круге, а правда вызовет непредсказуемые последствия)