Podlodka #373 – Разработка LLM-приложений

Всем привет, друзья! С вами подкаст «Подлодка». Меня зовут Женя Котелло. Со мной сегодня Егор Толстой. Егор, привет! Всем привет! И у нас сегодня выпуск «Как никогда на повестке дня». Все хайпят вокруг LLM. Мы не могли пройти эту тему. стороной. И вы, наверное, помните, у нас уже был выпуск про GPT и все, что с ним связано. Но, но...

Давай, Егор. Короче, сейчас. Мы начнем сразу с меты. Начал недавно слушать все выпуски подкаста, куда я не прихожу, и я начал триггериться с того, что всегда в начале выпуска мы говорим, этот выпуск как никогда актуальный или как никогда... подходящий. Получается, у нас всегда выпуски актуальные, подходящие. Давай делать наоборот. В начале каких-то выпусков мы будем говорить, этот выпуск как никогда какой-то не в тему. Согласен, да.

Выпуск как никогда не в тему, потому что можно было его записать еще где-то года полтора назад. Но что поделать... Во, мякотка пошла! И справляемся как можем. Так вот, о чем мы будем говорить? Мы будем говорить про приложения вокруг LLM, на базе LLM, как угодно. Называйте. В общем, когда мы берем большие языковые модели...

те самые Large Language Models, и с их помощью строим какие-то бизнесовые, да не только пользовательские приложения, сервисы и так далее и тому подобное. Чтобы вам сразу было понятно, о чем мы говорим, мы в подлодке уже такое приложение написали, но сломались на этапе его хостинга. Короче, Катя написала бота, которого обучили на транскриптах всех выпусков подлодки, который умеет отвечать на вопросы вида «А нормально ли ГО язык?» Ну, естественно.

на нет. А что надо знать тимлиду? Ну, типа, ничего, он же менеджер. И на прочие такие замечательные вопросы, смотря на то, что говорили гости. Короче, бот был классный, Катя его обещает вот-вот допилить и захостить где-то не на ее личном компьютере. компьютере, вот. Но, короче, вот как такое замечательное чудо техники построить, мы сегодня и обсудим. Да, и поможет нам в этом наш сегодняшний гость Макс Страхов. Макс, AI, ML-инженер и техлит в Apple и ex-Google, co-founder ex... Привет. Привет.

Да, как меня уже представили, я, значит, занимаюсь карьерными консультациями и ростом сотрудников и так далее, но сегодня я буду обсуждать вопрос по моей прямой специальности, по машинному обучению. Это такой для меня пилот, обычно я о других темах. публично разговариваю. Поэтому сегодня мы поговорим про LLM, а точнее, мне кажется, самая интересная тема LLM — это как с помощью LLM сделать что-то полезное.

Потому что LLM сама по себе это файлик, он ничего не делает, но этот файлик можно взять и потом с помощью разнообразных шагов превратить в... в некоторую пользу для человечества. Ну, сейчас большие технологические гиганты этим занимаются очень много, и Google, и Apple, и Microsoft, все подряд.

Полетели, значит, делать что-то, попытаться делать что-то полезное из LLM. Ну и также система стартапов хорошо развивается. Кто-то использует API, кто-то использует непосредственно модели, кто-то даже обучает свои модели. Поэтому здесь есть о чем поговорить.

много всего интересного, очень большое поле для обсуждения. Не уверен, что мы сможем погрузиться в каждый уголок этого домена сегодня, но мы попробуем. Круто, круто. И давай перед тем, как мы погрузимся в самую-самую-самую мякотку, буквально пару слов у тебя просто какой-то...

Это офигенский прикольный опыт в крутых компаниях. И, кстати, буквально маленькая ремарочка для наших слушателей. Все ссылочки на гостя, на его канал и все такое мы приложим к описанию этого выпуска, как мы обычно прикладываем. там всякие полезные ссылки, поэтому если вдруг все-таки вы заинтересуетесь не только LLM по результатам этого выпуска, но захотите, например, посмотреть канал про карьеру FUN, вы сможете это сделать. Собственно, про карьеру. Макс, можешь пару слов буквально сказать про...

свой бэкграунд. Как ты пришел вообще в эту индустрию, в индустрию AI, ML и всего, что связано в том числе и с большими языковыми моделями? Ну, пришел я в эту индустрию очень давно. Это было 2000, наверное... 2012 год, где-то тогда. Тогда еще не было никакого AI, не было никакого ML. Были Data Science и деревья решающие, значит, мы обучали. Пришел я в Яндекс.

Я не особо занимался вообще статистикой. Я был математиком по образованию, но статистикой вообще не занимался, у меня были совсем другие интересы. А тут я отчет в Яндекс пришел случайно и оказался в той команде, которая, ну, собственно, в команде, занимающейся качеством ранжирования, которая, собственно, сделала

машинно обученные модели для ранжирования в поиске Яндекса. Если поиск Яндекса в то время был плохого качества, то я виноват, можете в меня кидать кирпичи. Но потом я ушел, поэтому за сегодняшний я уже не отвечаю. В основном это было классическое машинное обучение, но как раз в то время начали появляться вот AlexNet, это как раз 2013 год, и именно в то время начали появляться нейронные сети снова на горизонте.

Да, тогда они еще были очень узкоспециализированные, но вот они выиграли ImageNet, это было очень впечатляюще, но тем не менее это было все-таки что-то нишевое, новое и непонятное. В индустрии мы не занимались никакими нейронными сетями, это была академическая в основном деятельность.

А индустрия, ну мы даже вот Яндекс вроде как такая передовая технологическая компания, мы дошли только через пару лет для того, чтобы начать смотреть, что там с нейронными сетями происходит. Вот я даже помню, еще когда я там был, у нас были интересные попытки использовать...

протоязыковые модели, как тогда называлось, Word2Vec, вот это все, для того, чтобы улучшать наше качество ранжирования. Но у нас ничего не получалось, это все разваливалось, и никакого качества мы из них не смогли выдавить, и в итоге мы условно сдались, но ненадолго. Но потом я ушел, но потом ребята все-таки вернулись к этому, особенно когда трансформеры появились в поле зрения.

Тогда была совсем другая история, совсем другие объемы данных, совсем другие модели. И тогда это все начало получаться. В мою молодость, когда я начинал этим заниматься, это все либо вообще не было, либо не получалось вообще никак. Потом я провел почти 8 лет в Гугле. Технически я был software engineer, но...

Везде почему-то я занимался машинным обучением, внедрял ранжирование в всякие внутренние, ну не внутренние, а какие-то маленькие поисковые машины гугловские. Небольшой поиск, а маленький. В большом поиске я улучшал качество тоже с помощью машин обычных подсистем.

Ну и в рекламе я тоже повышал качество с помощью машинообычных систем. И последний год в Google я вообще провел в организации, которая называется Cloud AI. Мы занимались разработкой, ну буквально разработкой AI-агентов для пользователей Google Cloud. Это не такие пользователи, которые сервера там покупают, а и такие пользователи, которые пользуются API-шками. Есть продукт Vertex.AI, это очень большой продукт в Google Cloud, очень много больших компаний особенно используют его. И мы занимались...

Лично я занимался суммаризацией и подсказками. То есть, если у тебя есть чат... Например, ты call center. У тебя есть 100 миллионов людей, которые тебе звонят все время. Ну и вместо звонков лучше в чат их отправлять. А чатом может управлять не человек, а машина. Точнее, человек там все равно сидит и как бы следит, и он работает вместе с машиной.

Ну, я вот разрабатывал модель для подсказок человеку, то есть чтобы не машина сама отвечала, а чтобы мы давали варианты человеку, а он их выбирал. И я занимался моделью суммуризации, потому что одна из очень важных вещей для колл-центра — это собирать данные. Но нельзя просто так собирать данные, потому что они пользовательские, там чувствительные информации. и так далее поэтому

После каждого разговора сотрудник call-центра пишет summary по разговору, и это занимает очень долго. Ну, тем более, что мы понимаем, что это сотрудники не супервысокой квалификации, им тяжело писать, еще и на английском зачастую тяжело писать. Вот, поэтому это вообще очень большая...

большая боль на них, и вот мы разрабатывали, вот я лично разрабатывал модель суммаризации для разговоров. После этого я перешел в компанию Apple, вот, и мы делаем ваши телефоны. Вот. И здесь я... возглавляю несколько команд в качестве поиска В этот раз я не занимаюсь ранжированием, чем что я делал в Яндексе, но теперь я занимаюсь другими аспектами качества поиска и там несколько вертикалей, и мне на самом деле не очень можно разговаривать о деталях. Окей.

Мы вот-вот перейдем ко всем тонкостям и хитростям LLM, но перед этим небольшой анонс для любителей нашей конференции, да и просто для интересующихся. И особенного внимания попрошу фронтендеров. Почему? А сейчас скажу почему, и это не реклама фронтенд-крю.

Это нечто совершенно новое для нас. 27 мая стартует первый сезон нашей абсолютно новой конференции подлодка React Crew. Да-да, у нас будет конференция про React. Как всегда, недельная онлайн-конференция. В течение пяти дней мы будем обсуждать...

дать что-то, связанное с React. А что сейчас скажу? Тема этой конференции — архитектура. О чем еще зарубаться в первом сезоне, как не об архитектуре? Конечно же. Не буду спойлерить вам всю программу. Переходите по ссылке в описании и смотрите. Там все есть, но вкратце просто... скажу, что мы поговорим про реактивность как базовый паттерн, затронем всякие разные другие паттерны, разберем кейсы миграции, подберем подходящие под конкретные задачи State Manager и много-много другое.

И помимо программы на сайте вы еще сможете найти список спикеров, которые будут выступать на конференции. Они у нас все очень клевые и классные, так что переходите и ознакомьтесь с программой и спикерами. И специально для слушателей этого... выпуска по промокоду ReactGPT через нижнее подчеркивание будет приятная скидка на билет. Так что еще раз. 27 мая. Конференция под лодкой React Crew. Ждем вас и возвращаемся к LLM.

Быстро добавлю, маленькая рекламная вставка, что мы тут сейчас говорили разные интересные слова, например, качество поиска, например, ML в рекомендациях. И вот если вам стало интересно послушать про них, у нас, конечно же, есть выпуски. Номера я не скажу, но за... ходите на сайт подлодка.io, пишите поиск, пишите рекомендации, и вам высветятся офигенные выпуски на эти темы. Прям рекомендую. Эх, а как бы эта вставка могла звучать, если бы бот был уже The Religion?

Ну да ладно. Ну круто, круто. Просто образцовая какая-то карьерная траектория. Очень крутые компании, очень крутые команды, крутой опыт. Так что предлагаю на этой... позитивной крутой волне, сразу переходить к мясу. И давай начнем с есть большого слона по частям, наверное. И я бы начал вот с такого. В понимании в таком моем, допустим, обывательском, если посмотреть максимально...

оборудовательской перспективы. Ну, что такое LLM? Это в первую очередь приходит в голову какой-нибудь чат GPT, то есть есть какой-то сервис, я ему что-то говорю, он мне что-то отвечает с какой-то разной степенью бредовости, точности, тому, насколько это можно верить, нельзя верить. В общем, с чего вообще мы должны начинать думать про то, чтобы на базе LLM...

построить какое-то приложение. Можно, наверное, пройтись с того, какие там вообще проблемы, о чем нам придется думать, когда мы будем это приложение делать. Да. Ну, я люблю начинать сначала. Это мой личный подход, который я обычно использую. Поэтому начнем сначала.

Сначала сегодня, как я изначально сказал, мне очень хочется поговорить сегодня про механизм извлечения пользы из машинообучных моделей. Часть из них — это LLM, и, собственно, основная тема выпуска — это LLM. Но, в принципе... Те же самые идеи, они применимы к другим областям, например, к моделям компьютерного зрения.

более или менее те же самые проблемы. Единственное, что они работают не с текстом, а со зрением. Ну и сейчас в современном мире все идет к тому, что мы будем мультимодальные модели использовать, которые работают и с текстом, и с картинками, и даже с видео. И мы видим вот эти классные демки.

Потом мы видим другие домки, которые их вместе объединяют. И у нас вот есть уже чат GPT, который может и картинки анализировать тоже. Вообще грани между разнообразными машинообучными моделями, они стираются со временем. Вообще слово LLM, мне кажется, оно рано или поздно уйдет в... историю вот останется у нас интеллектуальные агенты которые умеют работать с любым контентом в цифровом видео хотя бы поэтому да я наверное

Сам по себе тоже имею гораздо больше опыта с текстом работать, чем с картинками и другими вещами. Но, в принципе, все, что мы сегодня обсудим, оно более или менее применимо в разных доменах. Ну, так вот, начнем сначала. Представьте, что у вас есть машина на обычной модели. Ну, например, GBT, да?

И вот вам надо с ней что-то сделать, и вы чувствуете, чувствуете внутри, что можно ее как-то применить так полезно, но не знаете как. И, собственно, это самая главная проблема, о которой мы сегодня на самом деле не будем говорить. Тем не менее, это действительно самая главная проблема, это придумать вообще, а что с ними делать-то?

Потому что все, наверное, год назад на релизе ChatGPT, или полтора года назад уже, открыли chatgpt.openai.com, написали привет в промпт. Модель вам ответила привет и тебе тоже. Задавай мне свои вопросы. И вы такие, типа, окей, что теперь? И это самое сложное, придумать, а что теперь? В чем, собственно, use case и что вы хотите с ней сделать? Это, к сожалению, тема, она...

Больше такая предпринимательская, а не техническая. Поэтому сегодня мы о ней говорить не будем. Но стоит всегда помнить, что это вообще-то самое сложное. Все остальное это уже дело техники. Создание каких-то пользовательских юзкейсов. Это вот самое главное. Не стоит слишком фокусироваться на технологиях, пока у вас нету даже не то, что бизнес-кейса, а хотя бы просто пользовательского кейса, какой-то процесс, который полезен.

Буквально быстро вопрос. Перед тем, как нырнем в технологию, да, давай сильно прям в юзкейсы не закапываться, но, может быть, ты можешь назвать буквально несколько направлений, где сейчас вот применение LLM действительно прям классно стреляет и помогает бизнесу.

так, чтобы обозначить границы. А где, наоборот, фигней оказалось? Ну, оказалось фигней, это я не могу привести, наверное, примеров хороших, просто потому что еще рано говорить. Много очень стартапов, но мы видим, что экосистема стартапов вокруг языковых моделей огромная. И большое число из них, скорее всего, фигня. Но пока мы не знаем. Инстаграм, очевидно, был фигней, но потом оказалось, что он очень нужен почему-то всем. Но пока его не сделали, никто не знал, что он нужен.

То же самое и сейчас. Вполне возможно, что то, что мы сейчас смотрим на какие-то стартапы, которые занимаются LLM-based продуктами, кажется, что это глупость какая-то, а на самом деле это будет нужно. Ну вот, например, у меня есть знакомый, бывший коллега из Google, который сейчас делает кампанию по LLM.

based-интерфейс SQL-базам данных. Ну, условно говоря, он генерирует SQL-запросы из разговора с пользователем. Вот полезно это или нет? Мне, как разработчику, кажется, что это бред какой-то, потому что мне проще SQL-запрос написать, чем я буду с чатом говорить, честно скажу. Но я очевидно понимаю, что есть очень много нетехнических людей, которым действительно упростит.

общение с структурированной базой данных, какая-то языковая модель. Это классные умные коллеги мои бывшие, которые действительно capable сделать что-то технологическое, но вот насколько пользовательский USK здесь есть, я не знаю. На другой стороне есть юзкейсы, которые давно назревали. Ну, в том числе и Сундар, и Сатья Надела, они все говорят про использование языковых моделей в поисковиках.

Ну, собственно, Microsoft уже внедрил OpenAI фичи в Bing. Google сейчас как раз внедряет свои языковые фичи в гугловый поиск. Понятное дело, что в этом конкретном случае это... Ну и кейс, который, в принципе, уже давно был, он уже как бы изначально был. Самое простое, что вот когда вы пишете поисковый запрос еще 15 лет назад...

поисковик, он добавлял к вашему запросу синонимы. Вот вы написали какое-то слово, а он синоним к нему добавлял. Это, в принципе, то же самое, что и LLM, только очень примитивно и вручную, и вот как-то так вот, конфигурируемый лингвистами больше, чем машинами.

LLM делает то же самое. Она, в принципе, добавляет тоже такие же синонимы. Иногда, правда, это не слова-синонимы, это предложение-синонимы, это еще что-то, еще что-то. Какие-то более абстрактные конструкции, но студия от этого не меняется. И поэтому это, в принципе, этот use case, это...

ну, итеративное улучшение на уже существующем каком-то продукте и на существующем workflow. И, ну, в данном случае, очевидно, это супер успешно. Есть другие проблемы с современными поисковыми системами, но конкретно... Использование LAM это явно не ухудшает их качество. Ну и на самом деле у нас есть данные о том, что это на самом деле не ухудшает, но об этом я не могу распространяться, к сожалению. В деталях, по крайней мере.

Ну, как мы и сказали, мы не будем сильно упираться в кейсы, потому что это совершенно другая область, придумать хорошую идею, ну, как ты уже сказал, это самое ценное, но мы сегодня как раз хотим поговорить про конкретику о того, когда у нас уже есть идея, что дальше-то делать.

Давай, может быть, начнем с простого, самого такого дефолтного сценария. Мы, конечно, начнем с дефолтного сценария, ну и мы, наверное, какие-то сценарии будем упоминать в процессе нашего разговора, в любом случае. Но прежде чем переходить к инструментам, я все-таки хочу поговорить, почему это сложно, в чем проблема.

Проблема-то, как казалось бы, вот у тебя есть OpenAI чатик, пишешь у него запрос, а он дает ответ, и все, вообще хорошо. Ничего делать не надо. На самом деле нет, это, конечно, сложно. Все слышали, что такое галлюцинации. Это когда вы спрашиваете у... языковой модели что-то, а она пишет вам в ответ что-то другое, что вам кажется бредом. Ну или не бредом, а просто чем-то странным. Или неправильным, или неприятным. Это люди называют галлюцинацией.

И есть такое поверье, почему-то непонятно почему, мне непонятно, но, в общем, есть такое поверье, что модели иногда галлюцинируют. Вот что-то спросили их, а иногда они могут загаллюцинировать и сказать вам, что стонца значит меньше, чем луна.

Это, конечно, не так. На самом деле все, что выдает модель, это галлюцинация. Нет ничего, что не галлюцинация. Она выдумывает все. Без понимания этого не очень понятно, с чем мы пытаемся справиться. На мой вкус, по крайней мере, нет смысла говорить о галлюцинациях, а есть смысл говорить о...

выхлопе моделей, которые нам нравятся и которые нам не нравятся. Вот если она, например, грубит тебя, то нам это не нравится, несмотря на то, что технически здесь нет ничего неверного, но нам это неприятно, нам это не нравится, и поэтому это вот проблема. И в принципе...

То же самое с фактическими знаниями, потому что я себе могу представить легко пример человека, который вообще писатель, и он как бы использует эти языковые модели, чтобы писать фантастику. И то, что там солнце меньше луны, это совершенно нормально в его контексте. Вот поэтому здесь не нужно. думать, что мы пытаемся справиться с галлюцинациями. Мы не пытаемся справиться с галлюцинациями. Мы пытаемся направить галлюцинации модели в нужное нам русло. В то русло, которое подходит под наши юзкейсы.

Это очень важное заблуждение, что нет никаких галлюцинаций, на самом деле все галлюцинация, ну или ничего не галлюцинация, тут уж какой, это философский вопрос уже, в этот момент становится, но есть проблемы с тем, что есть ответы, которые вам не нравятся. Причин может быть бесконечное количество, но причины на самом деле не важны. Важно, что вас не устраивают такие ответы. И именно с этой проблемой мы пытаемся побороться. Как убрать ответы, которые нас не устраивают и...

оставить ответы, которые нас устраивают. Потому что можно убрать все, очень легко. Но нет, мы все-таки хотим хоть как-то получить пользу, поэтому мы хотим использовать LLM, но не хотим, чтобы она нам выдавала нежелательно выхлоп. Кстати говоря, где-то год назад классный чел из ETH, который сделал 4chan GPT проект, и он обучил GPT модель на 4chan. И вот очевидно, что в его конкретном юзкейсе... нужно было

чтобы она грубила, чтобы она говорила непристойные вещи и всякие гадости. Потому что, ну, иначе это была бы плохая 4chan GPT. Очень важно помнить, что вот это вот то, что называют галлюцинированием, и в любом случае то, что называют нежелательным выхлопом, оно очень сильно зависит от... контекста все инструменты которые мы сегодня будем обсуждать их можно

применять, а может не применять, а можно применять по-разному, в зависимости от того, какие у вас есть требования. Тут сейчас хочется важный вопрос задать, такой вопрос-ремарка. Мы же сейчас пока что говорим про желательный-желательный выхлоп. Хотя мы еще не говорили про способы справиться, наверное, мой вопрос преждевременный. Короче, я хотел сказать, мы говорим про нежелательный выхлоп как внутреннее встроенное свойство самой модели, с которым нужно бороться с тем, кто эту модель делает.

Или с точки зрения тех, кто потом этой моделью будет пользоваться? Я так понимаю, мы пройдемся по-другому уже. Да, мы пройдемся по всем. Мы пройдемся по всем из этих вариантов. Но на самом деле здесь нет четкой границы. Это какая-то вот такая фазия вещи. Кто пользуется, кто сделает.

Многие, кто пользуется, делают свои, например. У них тогда нет такого разделения. У других есть. И мы поговорим как раз про различия между этими двумя возможными бизнес-моделями. Ну, хорошо. Все-таки я предлагал бы начать сначала. Первый шаг...

как сделать языковую модель полезной, это ее обучить. Это кажется тривиальным, но мне кажется важным, опять же, начать с начала и поговорить с самого первого шага. Первый шаг — это обучение. Обучаются языковые модели с помощью так называемого процесса Masked Language Learning. Это когда ты берешь... кусок текста, закрываешь там слово, и эта модель должна предсказать, какое там было слово. Очень простая технология. Вам нужно только очень-очень много текста и очень-очень много GPU, чтобы

долго-долго перемалывать эти данные, и рано или поздно модель научится очень хорошо предсказывать слова. Ну и надо понимать, что чтобы предсказывать закрытое слово, вообще-то... нужно обладать нехилыми знаниями. То есть, ну, является ли... Знаете, было недавно в Гугле, да не только в Гугле, кажется, кейс, когда какой-то сумасшедший сотрудник сказал, что так они на самом деле уже осознанные, живые эти модели, что значит, с ними можно там...

поговорить о чем-то, что, значит, они вот такие все интеллектуальные. Сложно сказать, что такое интеллект, во-первых, но в любом случае, чтобы действительно, чтобы предсказывать слова, даже вот вроде как звучит очень просто, предсказать слово, которое закрыли.

Но чтобы это сделать, нужно очень много знать. Ну, например, вот у тебя предложение, есть высота эльфа и башни сколько-то метров, и вот ты закрыл сколько-то, и вот она должна предсказать сколько-то. Вот это слово, число вставить. Ну и как бы ей придется знать этот факт.

Каким-то образом ей придется этот факт найти в интернете, который мы в качестве тренировочных данных скармливаем ей, и каким-то образом она запомнил этот факт. Ну, то есть, чем это отличается от того, как человек запомнил этот факт, это хороший вопрос. Это, наверное, все-таки к философам, но с точки зрения механической... в принципе то же самое. Поэтому уже вот этот mask language model модель это очень мощная штука. И на самом деле 95 плюс процентов всего компьютера, всех данных

идет именно в эту часть проблемы. То есть, когда мы смотрим на ламу, например, какую-нибудь или на любую другую языковую модель, почти вся работа, которая была сделана, это вот работа в mask language модели. Ну, когда я говорю работы, я имею в виду работу, которую сервера делают. С людьми сложнее. Для людей как раз это простая часть, потому что математически это очень просто сформулированная проблема.

И, ну, понятное дело, что вам нужен хороший инженер-математик, который запрограммирует статистический процесс обучения на mask language модели, и как бы все. Поэтому с точки зрения человека там не очень много работы, но там очень много компьютера уходит и очень много данных. Это, собственно, первый шаг, который делает из совсем ничего, делает какую-то модель, которая уже суперполезная в том смысле, что где-то внутри нее очень много фактов есть, знания о языках, знания о зачастую даже каких-то...

Связанных вещах типа переводов, потому что мы, например, Википедию на нескольких языках прочитали и так далее. Это уже очень полезный артефакт, но пока что его польза не реализована, он потенциально полезный. Поэтому дальше мы можем переходить к следующему пункту. Когда у нас есть Mass Legend модель... Происходит следующий процесс, он называется alignment. Ну и да, вы, наверное, уже обсуждали на другом подкасте это, но я тоже быстренько скажу. Alignment — это буквально процесс...

попытки направить выхлоп модели в конкретное русло. Потому что, опять же, если вы все-таки сделали MLM-модель только, то у вас там будет... 4chan, короче, в том числе. Вам зачастую очень не хочется. Особенно вам не хочется, если вы, например, компания вроде OpenAI или альтернативной компании, которая имеет схожую бизнес-модель, которая предоставляет не какой-то конкретный бизнес,

продукт, да, а предоставляют просто вот API, типа, берите и пользуйтесь чем хотите. Ну и вот представьте себя на месте OpenAI, если у вас будет в обучающих данных какой-нибудь 4chan, короче, а у вас придет клиент, который корпорация. Вот, и она такая будет вас использовать и... клиентам уже этой корпорации будет какой-то выхлоп странный выдаваться, неприятный для них. Ну и корпорация, соответственно, придет к вам и скажет, что за херня, вы портите наш бренд.

И начнется, ну, с одной стороны, конечно, контракты могут разорваться, с другой стороны, бизнес пропадет, а с другой стороны, это даже может быть до серьезных и легальных процедур довести. Поэтому с точки зрения компании вроде OpenAI, ну, или вообще любой компании, которая предоставляет foundational модели.

В том числе, например, Lama, только она не IP предоставляет, она предоставляет артефакты. Но тем не менее, для всех этих вот компаний очень важно сделать первичный alignment модели, чтобы запретить ей условно. Говорит гадости. Это как первый слой. Дальше есть много разных параметров, которые они измеряют. Есть, например, параметр helpfulness, compliance и так далее. Например, вы, наверное, заметили, что...

что бы вы ни сказали, чат GPT, она соглашается все время с вами по каким-то практически любым вопросам. Ее можно убедить в чем угодно. Но это вот как раз специально спроектированная фича. Потому что многие люди, они, значит, испытывают негативные эмоции, если с ними не соглашаться.

В результате чего, ну, они будут жаловаться. Вот поэтому инженеры OpenAI собрали специальные датасеты, на которых было максимально все compliant. Ну, когда собирается, собственно, тренировочный сет не для ML-модели, а уже для следующего alignment-процесса. Оттуда вычищается все, что не compliant. Это только один из примеров, но там много разных примеров есть, там есть много разных метрик, которые они измеряют.

по качеству текста. Мне, например, нравится метрика helpfulness, нравится в кавычках, потому что helpfulness это вот, ну, буквально люди оценивают, насколько helpful ответ. И проблема тут в том, что по этой метрике модель, она учится максимально быть полезной. Но в том числе она пытается быть полезной, даже когда не может. И в итоге ты ее спросишь, например, скажи мне, какие книги написал какой-то такой автор, и она выдумает эти книги из ниоткуда, если она не знает.

Это артефакт вот этого helpfulness. Но, с другой стороны, если ее этому не учить, то она начинает типа, да, что-то вообще отвали, не хочу отвечать на этот вопрос. Да, то есть есть полярные проблемы, и, наверное, в каком-то смысле, к сожалению, но в другом смысле, наверное, это...

Закономерно, сейчас мы на том полисе, где она пытается на все, что угодно ответить, даже если ничего не понимает в этом. Это проблематично для многих бизнес-кейсов. Ну, в том числе, мы потом будем говорить о конкретных больше кейсах, некоторых, которые на моем опыте были.

И там это прям проблема. Но, тем не менее, с помощью онлайн-процесса мы собираем второй тренировочный сет, уже не mask-language сет, который весь интернет берут, а второй специальный, аккуратненько вручную написанный, вопросы-ответы и так далее.

интеракции между гипотетической моделью и гипотетическим пользователем, которые пишут люди. То есть они прям аккуратненько сидят и записывают. Это все максимально курируется, это должно быть максимально helpful, максимально useful, максимально positive и так далее. Это второй слой получения пользы из модели, потому что очень важно помнить, что модель, которая будет грубить, почти всегда предоставит вам нулевую пользу, просто потому что ее нельзя использовать, вам запретят.

Неважно, насколько она умная. Поэтому, чтобы получить какую-то пользу, ее приходится бить палкой, короче, ограничивать и заставлять ее быть вежливой и максимально милой. Даже если ценой этому будут глупые ответы, соглашение с чем угодно, выдумывание того, чего на самом деле нет. Это просто цена за возможность использовать эти модели. Понятно. В отличие от MLM, системы, когда мы предсказываем закрытые слова,

Здесь используется другая система обучения, она называется reinforcement learning with human feedback. Вы можете на Википедию зайти и ничего не понять, вот это сложная, правда, штука. Во-первых, это не конкретный алгоритм, это целое семейство алгоритмов, и там много твиков, плюс это буквально cutting edge research, то есть там...

пока нету какого-то устоявшегося процесса. Ну, понятное дело, что есть то, что используют большие разные системы, но там все время какие-то статьи, все время какие-то твики, и вот, поэтому... Это сложная тема, но тем не менее это совсем другой алгоритм, он более сложный, но он работает на гораздо меньшем количестве данных.

Но эти данные надо очень аккуратно вручную собирать, очень аккуратно помечать и очень аккуратно, типа, следить, чтобы там не было ничего плохого. Точнее, ничего нежелательного для вас. А сейчас небольшой технический вопрос, если можно. А это все, ну, типа, как они друг с другом...

относится модель, которую обучили через MLM, и модель, которую обучают Alignment. Это все как бы одни артефакты, один набор весов, который потом дообучается, или это две разных модели, грубо говоря, одна просто фильтрует базар другой, если совсем. Это обычно гибрид. Обычно мы берем готовые веса меломоделей, а сверху достраиваем еще слойчик.

И вот эти новые веса — это новые веса, но есть и старые веса, и оно обучается все вместе. То есть это гибрид, но, в принципе, это просто шаги от ничего к продукту. Первый шаг — это MLM модель обучить или взять готовую. Второй шаг — это Aligned модель обучить или взять готовую. другой метод обучения, но да, мы переиспользуем артефакты, которые были на предыдущем шаге. Супер, понял, все. Sorry за лирическое отступление, давай дальше. Вот, примерно на этом месте...

Мы завершили разговор о том, что делает разработчик с самой языковой моделью. Ну, а еще раз, в современном мире так получилось, что бизнес-модель этих разработчиков — это предоставить API или предоставить VISA, а другие компании, другие агенты, они используют.

Эта модель. Ну, результатом такой вот бизнес-модели... Ну, на самом деле, это не всегда так, например, внутри Гугла там другие условия, но вот в большом мире, который публичный, да, именно так все происходит, и результатом такого процесса и такой бизнес-модели мы имеем то, что вот эти все эти API, они супер обобщенные.

То есть у нас буквально есть чат GPT, с которым можно поговорить о чем угодно. И дальше уже работа конкретных маленьких компаний, ну или больших компаний, использовать это вот что-то, как-то это вот так вот упаковать, чтобы ограничить скоп с чего угодно на что-то конкретное, но полезное. Поэтому большая часть работы уже, конечно же, сделана OpenAI, ну или другими компаниями, которые занимаются разработкой LLM-моделей. Но...

Эта часть работы больше дорогая, чем большая, честно говоря. То есть это много компьютеров, много серверов, много работы, много алаймента и так далее. Легальные риски, опять же, туда же вписаны. А дальше есть...

Очень много разных юзкейсов, и каждый из которых разрабатывает маленький стартап или, возможно, несколько. На этом месте заканчивается то, что делает OpenAI непосредственно, ну и альтернативные компании, которые занимаются похожими вещами. И мы переходим к тому, что делают, собственно, пользователи. Когда я говорю пользователь, это может быть...

либо компания, которая использует API OpenAI, ну, то есть буквально в чат GPT заправить запросы, но также это может быть и другая компания, которая использует LAMO. Вы берете, просто модель скачиваете, как саму модель, и пытаетесь с помощью нее что-то сделать. Это примерно то же самое с точки зрения инструментов, которые у вас есть.

Ну, конечно, с моделью и больше инструментов есть, но тем не менее, концептуально это примерно одно и то же. Потому что дальше это уже ваша работа, как-то взять эту модель и чуть-чуть ее как-то ограничить, чтобы она стала полезной для вашего конкретного бизнес-плана.

Поэтому мы переходим к тому, что делают пользователи, в данном случае, когда подпользователь, я имею в виду, ну, человек, который пытается с помощью обобщенной вот этой модели, которая уже aligned, сделать что-то конкретное. Какие-то вопросы есть? Да не, мне кажется, мы прям четко прошлись. Как раз вот сейчас любопытно, потому что модель же получается обобщенно, модель получается очень корректно.

Как пользу это из них теперь извлечь? Потому что ты ей скажешь 2 плюс 2, 4. Она скажет да. Потом ты говоришь, ой, извини, я ошибся. 2 плюс 2, 5. Она такая, да-да, вы правы. Это буквально так и происходит. Рад помочь. 2 плюс 2, 5. Да, это буквально так и происходит. И это интуитивно кажется большой проблемой, но еще раз, очень важно не забывать, что без этого вообще бы запретили все эти модели, потому что они бы грубили всем. И обзывали всех нехорошими словами.

Так вот, значит, теперь мы переходим к списку вещей, которые могут делать, собственно, пользователи модели, чтобы сделать ее более полезной для себя. Ну, начнем с самого простого. Еще раз, вот вы вспомните себя, наверное, многие здесь хоть раз пользуются GPT. Это супер.

Суперпопулярно, супервесело. Ну, если вы не пользовались, скорее всего, вы видели видео или там скриншоты какие-то и так далее. Что происходит? Вы что-то спрашиваете, а она что-то отвечает. И вот там есть кнопочка такая. Regenerate называется. Перегенерировать ответ.

И вот первый способ сделать так, чтобы модель выдавала то, что вам хочется, это просто нажимать эту кнопочку, пока вам не понравится. Это смешно звучит, но на самом деле это вполне валидный способ, и он используется достаточно часто. И мы можем себе представить себе юзкейсы, например, люди, которые генерируют, ну вот сейчас очень много стало популярно, какие-нибудь посты на LinkedIn с помощью RGPT сделаны, или там посты на Medium. Для них это способ идеальный.

Это человек, которому нужен конкретный пост, он знает, что ему надо, и он просто кликает regenerate, пока, значит, не получится все, что ему нравится. Это совершенно нормальный процесс. И, на самом деле, очень много людей, у которых больше креативные юзкейсы, которые не штампуют одинаковые какие-то вещи.

А у них есть малое количество задач, но каждая задача уникальная и креативная. Для них это является основным способом влиять на модель так, чтобы она выдавала то, что им нравится. Тут надо помнить, что языковая модель — это статистическая модель. То есть каждый раз, когда вы ее запускаете Она выдает вам разные результаты Даже если вы один и тот же вход в нее отправили

Но на самом деле так вообще все модели работают, машинно-обученные. Просто если вы думаете о каком-нибудь классификаторе, то обычно там ставится треш-холд разработчиком этого классификатора. И вот у вас он становится детерминированный. Но на самом деле все, любую машинно-обученную модель можно использовать как вероятность.

Ну и обычно это не очень полезно, там котиков от собачек не очень полезно, вероятно, отличать. А вот в генеративном контексте это как раз становится очень полезно, потому что вы генерируете разный результат каждый раз при каждом вызове. Ну и, собственно, вот эта кнопочка Regenerate, она именно этим и занимается, она отправляет тот же вход в модель, но потому что она случайная, вероятностная, она выдает разный выхлоп.

И, в принципе, если вам достаточно этого юзкейса, то не надо стесняться, не надо стыдиться своей примитивности. Делайте так, и оно будет хорошо вам. Но это может же быть... Ну, короче, я сужу по своему опыту с тем же самым ChargeGPT. Ну, здесь прям, правда, ограниченная применимость, потому что чаще всего то, что он выдает после нажатия на кнопку Regenerate...

очень сильно похоже на то, что было до этого. Смысловая составляющая, в общем, редко менялась у меня. Может быть, это мои кейсы? Это правда. Но если вы будете использовать API... то внезапно у вас окажется, что там есть параметр температура. И вот ее можно двигать. И если вы поднимаете температуру, я не буду сейчас обсуждать, что это такое, но тем не менее ее можно увеличить. И когда вы ее увеличите, то увеличивается...

разнообразие выхлопа. Поэтому вполне возможно, что в конкретных ваших вопросах и при конкретной вашей температуре действительно у вас не было особого разнообразия, но для других вопросов, а также для того же вопроса, но с другой температурой, у вас будет гораздо больше разнообразия. В API есть такой доступ к этому параметру, в UI я, по-моему, не видел доступа к этому параметру

И тут надо понимать, что в принципе, вот то, что я сейчас описал, это по сути главным образом работает нейронная сеть в голове пользователя, а не нейронная сеть на сервере OpenAI, потому что пользователь читает ответ, ему он не нравится, он ее выкидывает. Генерирует новый, читает еще один, ему не нравится, он выкидывает.

Это вот совместная командная работа нейросети на сервере в OpenAI и нейросети в вашей голове. Окей, ну, допустим, не подходит. Плохо получается. Что дальше делаем тогда? Ну, плохо-неплохо, нет. Такое получаться плохо не может. Это, на самом деле, идеальный способ. Единственное, что он... подходит только для ограниченного круга задач, когда у вас количество задач маленькое, но они все разнообразные и...

креативное. Если у вас много однотипных задач, то, естественно, такое не подходит, потому что вы задолбаетесь, короче, кликайте на refresh. Ну и ясное дело, что если вы пытаетесь что-то вообще автоматизировать, то это вообще неприемлемо. Тем более это очень дорого, потому что, ну, представьте себе, что вы пишете софт,

который просто за вас кнопочку нажимает, пока, значит, не будет хорошего результата. Ну, окей, а как, во-первых, оценить, хороший он или нет? А во-вторых, ну, вы же что пользователь? Час, что ли, будешь ждать, пока вы там не сгенерируете что-то, что вам понравилось? Вот, поэтому действительно есть другие способы, но мы до них еще доберемся. В первую очередь, представьте себе, что вы нажимаете много раз эту кнопочку Regenerate, а у вас все никак ничего хорошего нет. Ну, если...

это не работает, то можно сделать маленький шажок дальше и изменить вход. Например, переформулировать свой запрос. Переформулировать это просто может много чего значить, у вас может быть по-другому запрос задан, вы можете другие слова использовать, вы можете структурированный больше запрос сделать. много разных вариантов, но, в общем, если вы хоть раз в чат GPT задавали вопрос, он отвечал вам что-то, что вам не понравилось, и вы задавали другой вопрос, то вот вы...

Prompt Engineer. Поздравляю вас. Это называется Prompt Engineering. Переформулировать запрос так, чтобы ответ был такой, который вам понравится. Этот способ не отличается от предыдущего в том смысле, что действительно здесь тоже работает ваша нейросеть, потому что вы занимаетесь фильтрацией ответов.

И вы тоже, опять-таки, переформулируете, пока вам не придет то, что вам понравилось. Это как бы расширение, но, тем не менее, оно ничего не автоматизирует. До автоматизации мы дойдем. Ну, это похоже, знаешь, как из классической теории управления, или как это называется. Короче, когда мы в системе... добавляем пока что самый простой механизм обратной связи потому что до сих пор его не было мы с одним и тем же входом

Один и тот же вход подаем в систему и такие, ну, надеемся, в этот раз получится что-нибудь другое. А тут мы, вероятность системы, добавляем обратную связь, чтобы как-то модифицировать input. Да, да. Ну и, собственно, именно поэтому вообще-то это очень успешная вещь. То есть, ну, слово Prompt Engineering все знают. Это...

Очень успешная технология. Да, и действительно, потому что мы добавляем обратную связь, и обратная связь, она просто меняет, как мы работаем с LLM. Но пока что мы немножко изменили, мы просто переформулируем. Уже тут у нас есть целый ворох вариантов, что мы можем делать. Потому что переформулировать... это абстрактное слово, а по факту что происходит? Это очень нюансно и интересно. Один из самых мега успешных способов переформулировать запрос называется in-context learning.

Это значит обучение в контексте. Это когда вы не отдельно модель обучаете, а потом используете, а вот обучаете прямо в процессе использования. ну и какого-нибудь классификатора котиков и собачек такого нету, поддержки такой фичи, а вот у LM есть поддержка этой фичи. Ну, в самом простом варианте это заключается в том, что вы просто предлагаете правильный ответ модели. Ну, например, вы хотите, чтобы модель была... калькулятором, чтобы она арифметикой за вас занималась. Вы можете в своем запросе

Хей, модель, побудь, пожалуйста, калькулятором, написать несколько примеров, что нам вообще надо делать. Значит, 2 плюс 2 — 4, а 2 умножить на 3 — 6. Скормить таблицы Брадиса. Ну да, да. Может быть, может быть. Ну, это, наверное... Рано или поздно мы до этого дойдем тоже, да. Оказывается, что вот такая штука супер-мега помогает. Добавление буквально парочки примеров, ну и понятно, что в смысле арифметики это вообще простой пример, гораздо более сложные есть способы...

добавлять какие-то примеры, которые вам нравятся. Но это прям революцию произвело. Ну, не то чтобы... В прошлом году каждый день была революция почти, но это была одна революция. Мы научились добавлять несколько примеров в... наш запрос тем самым например вы знаете ответ на два вопроса из вашего домена

Какая высота у Бурдж-Халифа вы знаете, и эльфовая башня вы знаете, а вот у какой-нибудь Empire State Building вы не знаете. Вот вы дали два примера, которые вы знаете, а потом вы можете бесконечное количество примеров спрашивать, которые вы не знаете. И оказывается, модели почему-то работают гораздо лучше, если им давать хотя бы какой-то пример.

что вы от нее хотите. Но это неудивительно. При работе с людьми мы видим такие же эффекты. Если человеку что-то показать, то он потом гораздо лучше справляется с задачей, чем ему ничего не показать, а просто делать задачу. То же самое, видимо, работает с машинообученными моделями.

Вопрос, почему это работает, он на самом деле сложный, потому что... Что такое это? Ну, например, она дает вам более фактическую информацию, почему это работает. Непонятно, да? Возможно, потому что вы добавляете какие-то слова...

которая ассоциирует, значит, ваш запрос в Википедии, и теперь она все ответы из Википедии дает, а в Википедии написано, какая высота у Empire Steel Building, да? То есть, возможно, она как-то... Это тюнит ее не только на конкретное вот... Ну, тюнит ее на конкретный домен, что она вот...

Фокусируется на каком-то домене. Это какие-то абстрактные слова, фокусируются, тюнят, что-то непонятно. Мне тоже непонятно, но как-то вот это работает. Но слово это может означать другое. Ну, например, очень часто, мы еще дойдем, но очень часто вы хотите от модели, чтобы она генерировала вам... не просто ответ текстом, а какой-нибудь структурированный ответ. Например, табличку написала. Или там JSON. И вот это вот вопрос, если вы в вопрос добавите пример с JSON, который вам нужен,

Это гораздо-гораздо сильнее, просто бесконечно увеличивает вероятность, что она вам правильный шанс отдаст. Даже тогда она ошибается иногда, ну и там разные по-разному ошибаются, но тем не менее, если этого не сделать, то вообще плохо будет. Я пытался как раз себе приложение сделать, я вот...

говорю, напиши мне ответ в виде джессона. И она такая, ну окей, и начинает расписываться длинным ответом, а в серединке джессон вставляет еще какой-то разной формы, и формат джессона разный каждый раз. Непонятно. А если ты в промпт добавляешь, хей, вот такой вот джессон конкретный, то всегда почти одинаковый JSON. Ну, не всегда, но 90% случаев она выдает одинаковый JSON в нужном формате с нужными полями. Отлично, правда?

Ну, одна из моих гипотез, перед тем, как вообще весь это AI был популярен, раньше мы работали с лингвистами, чтобы улучшать поисковые движки, и вот поэтому у меня остались остаточные знания, значит, из работы с математическими лингвистами с тех пор. Одна из моих гипотез, что вот это работает очень хорошо, в том числе, потому что язык вообще имеет рекурсивную структуру. Ну, там, я...

проснулся, а потом пошел чистить зубы, а потом пошел умываться, а потом принял душ, а потом еще что-то, еще что-то, еще что-то. Это рекурсивные структуры предложения в языке. Вы даете буквально паттерны языковой модели. которым она может апеллировать. Ей просто не нужно думать, она просто берет и рекурсивно вот этот рекурсивный паттерн, который вы ей дали, она просто его применяет. И благодаря вот этой рекурсивной структуре непосредственно практически всех человеческих языков естественных,

И благодаря тому, что это статистическая модель, ей проще, чем человеку в каком-то смысле заниматься такими рекурсивными задачами. Именно поэтому это очень хорошо помогает. Но это больше про форму, а про содержание непонятно, почему это помогает. По крайней мере, мне не совсем понятно. Ну, естественно, есть много статей на эту тему, но статьи — это Cutting Edge Research, и там не всегда понятно, ну окей, в этом конкретном случае да, но генерализируется ли это на все модели и так далее.

Информация статей, даже если она верная, то она не всегда понятна, в каком контексте она работает и так далее. Поэтому, по большому счету, мне кажется, мы не знаем, что я хочу сказать. Это звучит особенно впечатляюще от человека, который занимается подобными вещами уже больше 10 лет. Ну да.

Ну, в данном случае, мне кажется, очень адекватная аналогия с людьми, которые тоже разговаривают на каких-то языках, и много лингвистов изучают, как вообще все это устроено, и как оно устроено, очень хорошо изучено, а вот почему оно так, ну... Это вот гораздо более сложный вопрос. Окей, хорошо. Значит, это первая такая революция была, значит, добавляешь примеры и становится гораздо лучше. Но гораздо лучше это не значит идеально. Поэтому надо идти дальше и надо еще больше улучшать.

Особенно учитывая, что чем лучше оно работает, тем больше желания спросить что-то посложнее. Когда первые модели были сделаны много-много лет назад уже, мы спрашивали у них что-то простенькое, а сейчас мы буквально разговариваем с ними. То есть это гораздо сложнее. И чтобы делать еще более сложные задачи, недостаточно некоторых примеров, особенно если там абстрактные задачи, особенно если они разнообразные. Поэтому следующее, что мы придумали сделать, это технология называется Chain of Thought.

Такая цепочка мыслей. Это, значит, добавление в prompt in-context learning примеров, которые устроены как последовательность действий, а не как... Одно действие. Ну, то есть, обычно, как вы себе думаете, вот есть вопрос, а вот есть ответ, да? И вот раньше с ЛМК разговаривали вот так.

Но потом поняли, что если... Вот на самом деле ответа-то нет. Ну и с людьми, когда вы разговариваете, у вас нет ответа. Точнее, у вас ответ-то есть, но у вас не только ответ есть. А у вас есть куча мыслей в голове человека, которые потихонечку-потихонечку друг в друга перетекают, и только последний из них — это ответ.

Ну а в промежутке там много вычислений. И мы попробовали то же самое с языковыми моделями и дали им in-context learning примеры, ну и, кстати говоря, и по-файн-тюнили тоже в некоторых случаях, с буквально этим самым паттерном. Когда вы даете задачу модели... и даете тренировочный пример, на котором она не сразу ответ дает, а вы прям буквально в тренировочном примере перечисляете мысленный процесс, который приводит к решению задачи. И оказалось, что действительно это супер хорошо работает.

И тоже сильно улучшает возможности решать более сложные задачи. Опять же, если вы спросите меня, почему это работает, ну, здесь, на самом деле, чуть проще в каком-то смысле ответить, потому что часть причины, почему это лучше работает, потому что чем больше мы отправляем токенов, в модель, тем больше она что-то считает. То есть у нее буквально процессор больше инструкции выполняет. Ну, в данном случае на GPU процессора больше инструкции выполняет. То есть у нее есть больше поля для размышлений.

который с помощью вычислений происходит. Чем короче запрос, тем меньше она посчитала что-то. Чем длиннее запрос, тем больше отчет посчитала. Ну и казалось бы, что да, вы просто делаете гораздо более длинный запрос, добавляете кучу мусора, и она должна быть лучше. Ну вот такое почему-то не работает, но если удлинить запрос как-то осмысленно, какие-то релевантные вещи для него добавить, то это...

действительно становится, ну, начинает работать гораздо лучше. Ну, я предполагаю, что если мусор добавляется, то оно тоже как бы становится лучше, но, с другой стороны, оно еще и хуже становится, потому что это мусор, который мешает. То есть оно как бы и лучше, и хуже, и в сумме хуже. А если полезно что-то добавлять, ну в том числе вот Chain of Thought, да, то оно только лучше становится.

А есть сравнение производительности Chain of Thought и разбития на запросы на несколько промптов, когда ты не в одном промпте цепочку прописываешь, а эту цепочку сам, как пользователь, реализуешь через последовательные промпты? Я не очень понимаю... вопросы, мне кажется, это странно. На самом деле нет никаких последовательных промптов, есть один промпт. Просто он каждый раз все длиннее и длиннее. Если ты про чат интерфейс говоришь... А, все, все, все, да, да, да, окей, все, спасибо, да.

Дурацкий вопрос, понял о чем ты. Нет последовательности. Если вы про чат-интерфейс говорите, то каждый следующий запрос, на самом деле, это просто добавление новой информации в промт, а потом весь промт отправляется на сервер.

Ну, то есть, ответ, что аналогично тогда. Да, ну, по сути, это, в принципе, аналогично. Но другое дело, что не совсем аналогично, потому что, когда вы несколько раз добавляете в запрос что-то как пользователя, вы же каждый раз ответ получаете. И вот этот ответ, он может быть мусором.

И поэтому, наверное, все-таки лучше именно добавить in-context learning пример с конкретным, точно правильным, проверенным вами лично мыслительным процессом, который вы записали точно аккуратно. Тогда у вас не будет ни релевантных, ни правильных вещей в вашем промпте. Вот, а если вы будете пытаться чатиться с ней, то, ну, это тоже нормально, но, ну, это похоже, но у вас там будут неревентные вещи, которые вы хотите, чтобы она забыла.

Для этого вам придется новую сессию, открытие, новый чат, копировать туда-сюда, перегенерировать все. Это просто непонятно. Это не очень полезно. То есть это полезно для креативных задач, которые мы уже обсудили ранее, но для движения капсономизации это меньше помогает.

Для решения сложная задача. Эмпирически очень сильно матчится, потому что, мне кажется, когда пытаешься что-то сложное узнать, опять же, там, задаешь вопрос, получаешь ответ, задаешь вопрос, получаешь ответ. Чем дольше длится этот диалог, тем под конец, если ответы мимо все.

ну или там не совсем те, что нужно, у меня ощущение, что качество падает, потому что, ну вот, неправильные ответы, которые мимо, которые там качество недостаточно хорошее, они как будто бы засоряют, в общем, в конечном итоге промпт. Каждый следующий ответ как будто все хуже и хуже.

в итоге, правда, становится проще скомпилировать новый запрос с учетом всех вводных, которые ты в него добавил постепенно, и в новой сессии его закинуть. Тогда, ну, типа, сразу более революционный ответ. Так и есть. Прикольно, прикольно.

Сразу многие вещи становятся понятнее. Вот. Это Chain of Thought. Есть куча расширений. Есть Trio of Thought. Это когда у нас не цепочка, а когда у нас... корневая мысль, потом две детские мысли, у каждой из детских мыслей еще две детские мысли, и такое дерево получается, значит, из мыслей, и мы обрезаем те, которые нам не нравятся, и оставляем только тот...

путь в дереве, который самый классный из всех. То есть мы, по сути, ей даем каждый раз два варианта ответа. Она дает тебе два варианта ответа на каждую мысль, и получается дерево. Это еще лучше работает, но понятное дело, что... Это значит, что нам надо очень-очень много вычислять, и большая часть этих вычислений будет выкинута, а кто-то, тоже еще непонятно кто, оценивает, какой из вариантов лучше.

А кто оценивает, ну, понятно, что вы тоже модели спросите, скорее всего. Ну, на самом деле, есть много технологий, например, мы можем консистентность сравнивать, если там у тебя есть... Окей, альтернативно выбор лучшего можно выбирать демократический. Если у тебя есть 50 вариантов, можно выбрать самый распространенный. Не по идентичному тексту, а скорее подсчитать статистики по словам, например.

и выбрать вариант из самого большого кластера по статистикам, по словам. Вот так, как-то так. Ну, короче, такие эвристики, которые исполняются, но на коллекции ответов, либо непосредственно... одной коллекции, либо в виде дерева, когда у вас не было несколько уровней интеракции. Помимо три, есть еще другие, короче, их много, много статей, которые эти вещи разбирают, но мне кажется, что это очень сложно, и...

Я даже не уверен, что это... Ну, это полезно в моменте, но я не уверен. Мне кажется, рано или поздно нам придется от этого избавляться, потому что это какие-то странные модели интеракции с моделями, которые не очень удобные, они медленные, дорогие и, ну, в общем... они какую-то академическую в основном пользу, на мой взгляд, представляют, потому что в реальной индустрии мы таким вещами не занимаемся, даже не потому что не хотим, а потому что это просто все не работает на практике.

Не работать в смысле невозможно внедрить. Это слишком долго, слишком медленно, слишком дорого и так далее. Слушай, вопрос про академическую полезность. А насколько она правда есть, насколько она правда большая эта полезность? Потому что, с моей точки зрения, это выглядит так. У тебя есть, ну, грубо говоря, черный ящик. Ну, понятно, что если ты вложился конкретно, если ты лично поучаствовал в обучении вот этой большой модели,

то для тебя не совсем черный ящик, но все равно. Вот ты потом в итоге сидишь и такой, давай-ка попробую в свой... в промп добавить пример решенных задач. А давай попробуй это еще сделать вот так, чтобы получился Chain of Thought. И в итоге ты, не зная почему, не зная причин, как изменение твоего инпута влияет на модель, получаешь более качественный результат. А выводы-то какие об этом можно сделать?

Но это же все, по сути, как бы гадание получается. То есть ты ищешь способы переформулировать или как-то улучшить свой запрос, чтобы получить более качественный ответ, но механизмов за этим ты не знаешь. И механизмы можно попытаться...

вывести, проведя какое-то большое количество экспериментов и примерно предположить, что вот наша модель лучше реагирует на запросы, сформулированные именно так и так и так. Мы не очень понимаем почему, но статистически вот так вот это работает. Это типа, ну, хороший... академический процесс вообще

Или я в чем-то ошибаюсь? Любой процесс, который что-то изучает, хороший академический процесс. Академия так работает. Они делают много-много вещей, многие из которых глупостью оказываются, а иногда выстрелы и бам, и классно.

Академия так и работает. Мы слепую, щупаем мир. В данном случае мы щупаем, как эти модели, blackbox большие устроены. Ты заранее не знаешь, что сработает, поэтому тебе приходится делать все подряд. Поэтому любой процесс, который искренне нацелен на то, чтобы что-то изучить, это хороший академический процесс. Но, конечно, Нобелевскую премию вряд ли за чейно-то отдадут.

Супер. Окей, давай тогда дальше двигать. Окей. Значит, до сих пор мы говорили о чем-то ручном. Это когда вы, значит, переформулируете промпты разнообразными способами, либо по-простому, либо по-сложному, либо с примерами, либо чейнами и так далее.

и вручную оцениваете, а что хорошо, а что нет. Мы немножко обсудили, как можно алгоритмически оценивать, когда вы дерево строите, когда вы получаете несколько ответов и пытаетесь кластеризовать их и выбрать что-то такое. Но все-таки все какая-то магия. Это полуручная магия, так скажем. Если вы хотите не просто использовать модели для чего-то полезного, что мы уже обсудили, а теперь вы хотите что-то не просто полезное сделать, а что-то автоматизировать, чтобы у вас есть вот...

как вот, знаете, горячие пирожки, и каждый из них надо выпечь. И они все одинаковые. Их много. Их там тысячи, миллионы. Вот так работают программные системы. Да, у вас есть, значит, миллионы одинаковых или очень похожих задач, которые надо просто все проделать. Вот вы пользуетесь поисковым движком, вы каждый раз делаете запрос. Конечно, запрос разный, но по большему счету процесс один и тот же. Задача одна и та же, просто немножечко сконфигурированная вашим запросом. И вот...

Мы делаем одно и то же, консистентно, и каждый раз получается нормально. С LLM это все взрывается и не работает, потому что, как мы видим, каждый раз получается что-то новое, и каждый раз... То, что мы обсуждали, приходилось вручную оценивать, хорошо получилось или нехорошо получилось. Вот это стрёмно. И как не просто пользователь, а как разработчик приложения очень стрёмно этим пользоваться. Сложно.

Но, конечно же, люди, они упорные, поэтому на этом не остановились. И есть уже сейчас несколько вариаций, способов улучшить ситуацию, о которых мы, собственно, и поговорим. Ну, окей. Значит, представим теперь, что мы разработчик приложения. У нас есть пользователь, который нажимает вот так на кнопочку много раз, на одну и ту же. И мы делаем что-то одно и то же, но это что-то одно и то же делает что-то с помощью LLM. Ну, например, мы...

хотим, не знаю, написать хайку для пользователя, значит. И вот он кликает, и ему хайку показывается. И кликает еще раз, и ему еще хайку показывается. А потом мы даем текстовое поле, в котором он может тему выбрать, для которой хайку будет генерироваться. Вот такой вот интересный юскейс.

Начать, естественно, очень просто. Ты берешь свой промпт, который ты, значит, в ChatGPT окошечке написал, который генерирует тебе хайку, и вставляешь его в свой код. И в коде заменяешь, значит, слово с темой на %s в printf. Условно, это шаблонизатор. Вы берете и с помощью шаблонизатора вставляете вашу тему, который выбрал пользователь, в ваш промпт. Каждый раз генерируется новый промпт, по сути, немножечко отличающийся на эту тему.

Ну и каждый раз он отправляется в модель, и она каждый раз на новую тему генерирует хайку. Механически это очень просто сделать, никаких проблем вообще. Но как только вы это сделаете, внезапно обнаружится, что да, вы много времени потратили на промпт, Вы отточили его до идеала. Но вот он работает 9 раз, а 10 раз какую-то хрень выдает. А потом еще 9 раз работает, а потом еще раз хрень выдает. Почему? Потому что мы уже поговорили, все эти модели машинно обученные, они вероятностные.

А в современных ЛМКах, в них вероятность она прям включена, максимально включена, потому что они генеративные. У них нет вариантов никаких других. Он выдает вероятностно что угодно. Другое дело, что это что угодно модулируется промптом, но модулируется — это не значит гарантия. Это не гарантия, короче. Никто контракт не подписывал. По факту на любой вопрос он может задать вообще любой ответ, просто с очень маленькой вероятностью.

Ну и совсем полный бред он выдает совсем и совсем маленькой вероятностью, но с какой-то более-менее адекватной вероятностью, там, в 1%, он может выдать что-то, что не хайку, да, какое-то другое стихотворение, например. Ну и, ну, ваш продукт будет... Банально сломан. Это баг. Если бы это была обычная программная система, мы бы сказали, что это баг.

Ну, в данном случае баг это или нет, непонятно, в каком-то смысле это фича, наверное, но, с другой стороны, вам это не нравится. И, собственно, с чего мы начали, нет никаких галлюцинаций, есть тоже выход, который вам не нравится. То, что она выдает не хайку, хотя вы попросили хайку, вот вам не нравится. нравится, это не нравится. Что с этим можно сделать? Это сложный вопрос. На самом деле, в каком-то смысле это простой вопрос. И ответ на него тривиальный. Ничего. Все равно оно будет.

Но дальше начинаются нюансы. Окей, а как часто оно будет? А насколько плохо оно будет? Это как бы вероятность нашей модели, правильно? Она может выдать теоретически вообще любой текст. Но будет ли она посылать нафиг вашего пользователя? Скорее всего, нет, потому что разработчик LLM провел процесс alignment. Они много поработали, и они, если уж не гарантированно исключили, значит, такие неприятные ответы.

то хотя бы с очень-очень большой вероятностью исключили неприятные ответы, и даже если он случится один раз на миллиард, возможно, это не такая уж и большая проблема. Поэтому вы можете сделать то же самое. Но это будет не бинарное решение, как вот в обычном программном продукте у вас бинарное решение, либо баг, либо не баг, да. Здесь у вас нет бинарного решения, но у вас есть шкала. Вот от...

все время происходит такая фигня, да она происходит достаточно редко, чтобы мы могли это игнорировать. Собственно, вот об этом мы и будем говорить. Потому что, да, решения нет, но есть решения, которые частично приводят нас в более хорошее состояние по отношению к тому, что по умолчанию происходит. Ну и да, это сложный домен Именно потому, что здесь вот нет решения Мы не знаем, что делать, чтобы это решить

Мы можем только пытаться пробовать какие-то технологии применять, которые что-то где-то улучшают, а где-то не улучшают. Это тоже так бывает. Именно поэтому это достаточно высокоплачиваемая профессия сейчас. Потому что сложно, правда сложно. Поговорим о примерах. Ну, окей, давайте начнем опять с простого. Мы можем использовать ту же самую, а может быть и другую, LLM для того, чтобы валидировать ее собственный выхлоп. Например, вы спросили, дайте мне хайку, она вам выдала не хайку.

А вы назад ее спрашиваете, а вот это хайку или нет? И она говорит, нет. И вы такой, о, окей. Можно еще раз спросить? И вот у вас будет цикл. Вы, значит, спрашиваете в запросе от пользователя. Потом... Второй раз делаете запрос, проверяя ответ модели у этой же самой модели, а возможно у конкурента модели, а возможно у нескольких, и делаете демократическое голосование. А потом, если она говорит, да, все окей, вы отправляете ответ пользователю.

А если это говорит не окей, вы пробите еще раз. Ну и так в цикле пока не получится. Ну и понятное дело, что если, ну в теории это может бесконечно длиться, ну окей, ладно. В таком случае можно оборвать запрос, но на практике, опять же, чаще всего она все-таки что-то адекватное выдает. И тем более, что вы уже...

поработали над промптом, уже занялись промпт-энжинирингом и уже много-много оффлайн в своем UI тюнили этот промпт. Поэтому чаще всего он работает, поэтому все нормально обычно. Но иногда...

Ответ будет чуть подольше, потому что вам придется второй раз сделать запрос. Ну, или третий даже. Вот, если больше, чаще всего, ну, на практике можно просто обрываться и говорить, пользователь, перенажми на кнопочку снова, пожалуйста. Ну, это вот очень тупое решение. Просто будем долбиться, короче, пока не получится. Ну и чуть более умное решение — это валидировать ответ с помощью самой модели. Эту идею можно развить.

Сейчас у нас простенький цикл, получается, сделали запрос, сделали вализационный запрос, потом вернулись или вышли. Или после вернулись, снова вализационный запрос, и вышли, или вернулись, и так далее. Это получается маленький граф. Что если этот граф сделать не маленьким, а большим? Что если сделать много запросов, потом вместе их координировать, потом много раз валидировать в разных моделях с разными промтами?

И потом в самом конце уже, если все ответило да, все окей, в самом конце выдавать ответ пользователям. Ну и этот граф задач, который вы отправляете в LLM, может быть какого угодно размера, с какими угодно промтами, они друг с другом как угодно могут интегрироваться.

Ну, собственно, в этом и заключается идея фреймворка лэнгчейн. Лэнгчейн — это буквально, ну, не знаю, честно говоря, мне кажется, что это буквально ничего. Это просто... какой-то клей на питоне, который позволяет вам в цикле задавать много разных вопросов в разные LLM с разными промптами.

В принципе, я, собственно, лангчейн разрабатывал, когда даже не знал, что лангчейн существует, просто написать на битоне код, который, типа, делает несколько запросов, вот и все. Вот вам и лангчейн. Ну, понятное дело, что разработчики лангчейна, они подумали об общении, там можно композицию делать, но, в принципе, это клей.

Это ничего, это вот какой-то склеивающий код, который буквально вот занимается тем, что туда-сюда гоняет эти запросы. Ну, довольно удобная штука, потому что когда я писал еще до того, как я вообще увидел, что есть лэнгчейн, я в какой-то момент писал себе ботика, который... умеет из разных мест вытаскивать статьи, там, из РСС-списков, из твиттер-листов, из реддита, откуда-то еще по тегам, потом по разным эвристикам выкидывает оттуда те, которые мне нерелевантны, а те, которые релевантны...

берет и суммаризирует. И там еще потом кое-какие операции тоже с LLM-кой с ними делает. Мне просто приходилось ручками довольно много вот этих вот рутинных запросов сидеть, писать, смотреть на API-шки этих сервисов, а потом я увидел лонгчейн, и... такой, блин, вообще можно типа тремя строчками кода удобненько, все как мы любим. Ну, есть и такое мнение. Ну, это правда, да, несложное.

задача сама по себе просто рутинная. Моё мнение полностью противоположно. Наверное, возможно, потому что я не знаю, какой у тебя вагграунд, но я-то разработчик, вот, очень много лет. Мне, наоборот, хочется контроля. Мне хочется знать конкретно, какие запросы я отправляю, в каком последовательности запросы отправляю. Потому что я пытался пользоваться лангчейном, но я просто забил очень быстро, потому что был у меня запрос на валидацию чего-то там.

И он был как бы захардкожен в лэнкчейне. А я теперь хочу чуть-чуть по-другому его сдать. Ну окей, я могу там с помощью какого-то конфига передать параметр, другой запрос и так далее. Но тогда уж проще самому написать. Это, во-первых, и понять не будет. А во-вторых...

Там же эти запросы шаблонные, и то есть там надо как-то... Этот запрос, он на самом деле принимает input от другого запроса, и там вот поле name, оно выпаршивается из предыдущего и перекачивает в новый, да? А что если у меня не только поле name? У меня поле name, запятая ff surname.

вот так вот. И все, и лэнгчейн разваливается. Он очень быстро разваливается. Поэтому мне прям очень неприятно было им пользоваться. Неприятно не в смысле эмоционально, а в смысле, чтобы мне все время приходилось его пытаться обойти. И я буквально пару дней на это потратил. Я понял, что я оставлю мою систему, которая вручную написана, и она...

полностью гибко, я могу что угодно с ней делать в любой последовательности. Да, я согласен, что это значит, мне придется больше строчек кода написать, но как бы строчки кода после 15 лет программирования не являются проблемой никакой.

Собственно, поэтому мне лейнгчейн не нравится, но в принципе, да, особенно если вы не технический человек, там какой-нибудь человек, который пытается у себя в качестве хобби проекта что-то сделать дома, да, действительно, это прикольная штука, но учтите, что шаг вправо, шаг влево расстрел. Он не позволяет креативным быть.

Он за вас подумал, если это работает, то, что он подумал. Обычно подумал, а то он статист копирует. Если это работает, буквально как в статье написано, то окей. А если это не работает, то у вас не получится его достаточно хорошо изменить. Плюсы и минусы фреймворков, типа, любых на самом деле. Терпеть не могу фреймворки. Включай лангчейн.

Смотри, а есть же еще один способ увеличивать консистентность и увеличивать правильность запроса. Он, наверное, применим не ко всем задачам, но, например, мы его очень активно используем при использовании Yaya для... кода когда ты комбинируешь вызов л.л.м. и валидацию ответа какими-то классическими инструментами условно говоря тебе л.л.м. к сгенерировала код ты его прогоняешь там через компилятор если у тебя выдаются какие-то ошибки ты

Возвращаешь под капотом это LLM-ки и говоришь, вот тут у тебя ошибка, перегенерируй мне код еще раз заново. То есть, короче, еще один способ это комбинировать с какими-то дополнительными, более классическими инструментами анализа. Для того же JSON какой-нибудь валидатор поставить.

выходе. Да. То есть вот такой, кажется, еще способ есть. Я уже рассказывал историю про моего бывшего коллегу, который SQL-запросы генерирует, и он, собственно, как и делает. Он использует компилятор SQL-запросов, и пока он не скомпилируется, он...

продолжать дрочить модель, чтобы она что-то другое сгенерировала. Более того, вы же можете ошибку компиляции взять и отправить ее в модель, и она типа с помощью этой ошибки поймет, что она сделала неправильно. Ну, это очень теоретически круто звучит, но на самом деле...

На самом деле это сложно, скажем так. Да, и у нас, если вам стало интересно, у нас есть выпуск ровно про это, где мы говорим про то, как LLM-ки используются для написания кода. Там мы в том числе как раз говорили про то, как комбинируются такие... классическими инструментами. Ну, на самом деле справились ради. Сегодня мы очень много говорили про комбинацию с классическими инструментами, а конкретно с классическим инструментом нейронной сетью в вашей голове.

Добавлять к этой нейронной сети можно много другого, в том числе и софтверные продукты, например, компиляторы. Очень классно. Это я согласен. Ну и в лэнгчейне, я, кстати говоря, не помню. Когда я им пользовался, это было больше года назад, по-моему, там не было ничего такого, там, по-моему, были только вызовы API всяких OpenAI, в принципе, но, возможно, действительно, это добавилось.

Если оно работает, то классно. Еще был прикольный проект, я его сам, правда, руками не трогал, от Microsoft, TypeChat называется, где они, по сути, на базе TypeScript'а сделали что-то типа DSL'ки для того как раз, чтобы писать... запросы к LLM не на Natural Language, а как раз-таки с использованием этой DSL, и ответы тоже у тебя соответствуют тем типам, которые ты задал. Ну вот, опять же, я его сам не трогал, за что купил, зато продаю. Круто, круто.

Ну, Tool Use — это отдельная тема. Мы можем отдельно, в общем, рассудить. Tool Use — это классно, это правда. Но пока мы еще до этого не дошли. Значит, мы поговорили про лангчейн, что это такое, как он работает. Но проблема лангчейна в том, что он... Ну, опять же, лонгчейн это фундаментальная система, которая снижает вероятность нежелательного ответа. Ну, потому что, например, вы валидируете, или там несколько раз валидируете, или голосуете, выбираете лучший вариант из нескольких.

Все это как бы снижает вероятность нежелательного ответа, но не обнуляет ее. А вы теперь, допустим, дорожите своей репутацией и совсем не хотите, чтобы у вас не было неправильных ответов или плохих, нежелательных для ваших пользователей. Что делать? Лангчейн вам поможет, но он не решит проблему, он только какие-то шажочки сделает к снижению вероятности.

Сейчас будет эксклюзив небольшой, потому что я нигде такого не видел, но я это придумал. Я уверен, что я не один такой, но я такого не видел нигде больше. Это офлайн LLM. Можно применять идею лэнгчейна, но не в процессе. когда пользователи задают запросы оффлайн. Конкретно я, где-то год назад, разрабатывал приложение для изучения языков, потому что я живу в Швейцарии, и здесь мне хочется выучить немецкий язык, а я нифига не выучил его, потому что у меня...

Ну, я работаю на американские корпорации, мы все по-английски говорим, очень сложно. Учить язык, когда-то не с кем говорить. Я хотел изучить немецкий язык, поэтому я сделал для себя маленькое приложение с использованием OpenAI API.

для изучения языков. Почему я решил сделать что-то свое? Потому что мне хотелось, чтобы не просто там слова учить по карточкам, а чтобы слова в контексте приложений были. Ну и я вот буквально спрашивал, hey, chat.gpt, сгенерирую мне приложение на немецком языке со словом mother.

Ну, точнее, я говорю слово по-английски, а она, значит, должна была перевести его, сгенерировать слово, а потом она должна была сгенерировать версию предложения без этого слова, чтобы я мог его напечатать. Ну, там же обычный софт проверяет, что я напечатал правильное слово. Когда я сделал лэнгчейн у себя...

Во-первых, так. Сначала я не сделал никакого лэнгчейна, и это было очень плохо. Она генерировала какой-то полный бред все время. Потом я сделал лэнгчейн, и бреда стало меньше, но она, во-первых, стала гораздо медленнее работать в несколько раз. Ну и, соответственно, это транслируется еще и в цену, которую я должен заплатить за генерацию, все это. Но помимо этого, в бред-то он не пропал, его просто меньше стало. И периодически, все еще периодически он какую-то полную чушь мне писал.

Очень хочу заметить, почему я решил рассказать про этот пример, потому что это пример, максимально хорошо ложащийся на LLM идею, что мы генерируем просто текст. Не вот конкретный JSON, не конкретные SQL-запросы, а вот текст мы генерируем.

Человек и читаемый текст. Это именно то, для чего училась ЛЛМ. То есть это максимально простая задача, по идее, должна быть для нее. Ну, здесь немножечко есть усложнение тем, что она должна на нескольких языках одновременно уметь говорить. Но, тем не менее, именно для этого ЛЛМ лучше всего и подходит. И даже так, даже в такой задаче, которая максимально хорошо ложится, было много-много проблем с мусором, который она мне пыталась впарить.

Было медленно, плохой был юзер-экспириенс, ну и вообще отстой полный. Поэтому я придумал делать то же самое, только офлайн. Я собрал большую базу данных, слов. Ну, собственно, собрал, скачал базу данных слов. Там на A1, на A2, на B1 и так далее. У меня была аккуратненькая база по всему. А потом я делал те же самые запросы в OpenAI API, но...

Оффлайн. Просто вот поставил сервер, который в цикле крутился по всем словам и заполнял мою базу данных примерами. Ну и понятно, что мне хотелось разнообразие примеров, поэтому для каждого слова я генерировал там 20 примеров, допустим. Ну понятно, что если я 20 примеров правильно ответил.

Тут, скорее всего, я запомнил это слово, и можно на другие слова заниматься, поэтому этого достаточно. Но, в принципе, если это было бы недостаточно, я бы мог сколько угодно сгенерировать. Это просто вопрос цены. Ну, и не такой уж очень большой. И что было сделано?

То же самое, что мы обсудили с лангчейном онлайн, только оффлайн. Я спрашивал, хей, сгенерируй мне пример. Я брал этот пример, разбивал его на кусочки, с помощью софта проверял, что это JSON валидный, во-первых. Потом обратно отправлял кусочки этого JSON. А правильно ли это предложение? А точно ли оно на немецком языке?

А точно ли оно содержит такое-то слово, которое я задумал, что оно содержит? Потом брал второе приложение с дыркой, которое показывается пользователю, и которое он должен заполнить. И спрашивал, а точно ли вот это приложение с дыркой такое же, как приложение без дырки, кроме того, что в нем дырка есть?

Из этого объяснения вы, наверное, понимаете, какие проблемы у меня были с выхлопом. И вот я просто видел проблему, брал такой, говорил, ну окей, я добавлю еще один валидатор. Валидатор — это еще один запрос в ChatGPT с валидацией того, что она мне вернула изначально.

Ну и тут надо понимать, что ответы на все эти валидационные запросы — это да или нет, правильно или неправильно. И это гораздо проще для HTTP, чем какую-то генерацию сложного. Поэтому у меня была идея, что вот она выполнила сложную работу, а потом, поскольку валидационные... запросы будут гораздо проще, потому что это данят вопрос, то они будут более правильными, и поэтому они отфильтруют много трэша.

И эта гипотеза сработала действительно, и действительно отфильтровалось очень-очень много трэша, почти весь трэш, то есть мне практически не нужно было вручную ничего потом чистить. И это очень хорошо сработало, поэтому оффлайн-лайн-чейн целее валидатора, когда вы не просто делаете какие-то разные запросы к LLM и передаете куски данных между друг с другом, а когда вы делите на сложные запросы, которые вам реально нужны, и простые, и максимальные запросы.

в которых большой контекст, потому что там много текста. Но ответ такой типа да, нет. Хорошо работает, отлично. Ну и... Помимо этого, мне еще было интересно, я попробовал Chain of Thought, когда я сказал не просто скажите да или нет, а сказал, опиши процесс. Ну и, собственно, я сделал one-shot learning.

в котором я написал пример Chain of Thought, пример мысленного процесса, который приводит к ответу да или нет. И это тоже сработало, но, правда, не очень хорошо. Точнее, не то, что не очень хорошо. У меня было и так все хорошо, поэтому это, типа, микроскопический профит дало. Вот такой у меня большой эксклюзив, как на пустом месте можно новые технологии придумывать. И если бы я был академиком, то я бы, скорее всего, статью на это написал.

и опубликовался бы, и все бы меня знали. Но я не академик, а я инженер, поэтому я просто зафигачил и забыл. А потом, значит, я... узнал, что есть лонгчейн, что и это есть, и что, и что. А на самом деле это целая индустрия в ресерче, как вот разрабатывать инструменты для повышения надежности выхлопа LLM.

Круто. Если нас смотрят какие-то инвесторы, которые, значит, хотят инвестировать в мой крутой продукт по изучению языков, пожалуйста, обращайтесь, потому что пока что еще инвестор не найден. А продукт работает хорошо. По крайней мере, в прототипном варианте. Окей, moving on. Значит, мы поговорили про снижение вероятности проблем.

И даже офлайн-валидация, после которой можно сделать еще и human-валидацию, кстати говоря. То есть я-то сделал валидацию с помощью нейросетей, но можно еще и с помощью биологических нейросетей потом это повалидировать.

что я тоже, в общем, имплементировал, но оказалось, что в последней версии это даже не особо нужно, потому что и так все хорошо. Тем не менее, это все-таки снижение вероятности, даже для очень маленькой какой-то, но когда у вас миллион пользователей, понятно, что маленькая вероятность каждый день случается. Что делать, если мы совсем-совсем не хотим сказать какую-то фигню? И более того, что если у нас есть какие-то контрактные обязательства перед пользователем?

Даже если это контрактное обязательство, не формально контрактное, но выборожаемый контракт. Например, вы пользуетесь Google, вы делаете запрос в Google, и Google вам выдает какие-то ответы. И у вас с Google есть такой вот контракт в каком-то смысле, что он вам выдает настоящий ответ, а он не придумывает какой-то bullshit, он вам выдает, что на этом сайте есть вот такие-то слова.

И да, там может быть глупая информация, но Google вам не обещал умную информацию, но он обещал вам, что он выдаст вам ссылку на источник, на котором точно есть текст, который вы запросили. И в этом смысле вы можете на него полагаться. Вы, может быть, не полагаетесь на конкретную информацию, но вы полагаетесь на что-то, на какие-то аспекты вашей интеракции с Google, вы полагаетесь и вы думаете, что он надежен.

И вообще вот эта вся идея надежности, идея в том, что от того, что можно на что-то положиться, она очень крутая, она... Цивилизация на этом стоит, на то, что у нас люди друг на друга могут положиться, потому что если вы не можете, то вам надо свою частную армию нанимать и так далее. Вся цивилизация держится на то, что у нас есть надежные агенты.

Ну или достаточно надежные агенты. Не обязательно во всем надежные, но в каких-то аспектах они надежные. И что делать в таком случае? Если мы берем выхлоп LLM и показываем его пользователю, мы не можем положиться на этот выхлоп. Да, он часто хороший и так далее, но мы не можем на него положиться. У нас все время сердце сжимается и волнение, что он один раз на миллион выдаст какую-то бред.

А еще хуже оскорбительный бред. Поэтому люди задумались, что с этим можно сделать. Как сделать так, чтобы мы могли гарантированно положиться на ответ от LAM. Ну и придумали модель, которая называется Retrieval Augmented Generation. В сущности, это вот то, что... уже о чем много лет поют нам главы поисковых компаний о том, как скрестить искусственный интеллект и поисковые движки. Retrieval Augmented Generation — это, по сути, не решение, это как бы задача. Задача — снабдить.

Ответ от LLM, ну или на самом деле от любой машинно-обычной модели, но особенно популярной это стало в век LLM. Снабдите этот ответ с ссылками на источник, чтобы ответ был сгенерирован. не из воздуха галлюцинация, а чтобы он был ссылкой на документ, который, возможно, даже подписали и поставили печать.

Какой-то ответственный человек поставил печать на документ, и вот мы его добавили в базу данных, и теперь этот документ мы можем кому угодно показывать, потому что на нем печать стоит. К этому подойти можно с двух сторон. Можно подойти, сказать, что вот есть база данных, мы найдем куски документа из базы данных и покажем их пользователю. Это, в общем, классический Google. Просто для Google база данных — это веб.

но, в принципе, можно сделать и поменьше базы данных. Ну и внутри Google там много-много поисковых внутренних движков, которые, значит, с другими базами данных работают. Значит, этот поисковый процесс можно улучшить тем, что вы возьмете 10 результатов Google, первую страницу, скормите их в OLM, и получите какой-то красивый текстик. Но все еще со ссылками, что вот этот текстик имеет ссылки на все эти 10 результатов. Можно пойти в обратную сторону и сказать, вот у нас есть выхлоп LLM.

А теперь LLM, а найди-ка нам к нему, ну, цитаты, короче, ко всем этим вещам. Ну и, как повелось, первый вариант, конечно, гораздо проще, потому что LLM сначала может какую-то фигню сгенерировать, а потом ты будешь искать цитаты к ним, это глупость какая-то.

Поэтому сейчас все Retrieval Augmented AI модели, они работают по первому варианту, когда у нас сначала есть база данных, в ней может быть много документов, например, миллиард. Мы находим кандидатов, например, по твоему запросу, мы находим 5 самых лучших кандидатов.

Вот документы, которые, скорее всего, содержат ответ. Но он не один, потому что мы не знаем это, мы не уверены. Но может быть их 5, может быть 10, может 50. Это уж сколько вам позволит ваш карман, да? Сколько вы можете компьютер сделать. А потом... Вы эти 10 документов, которые вы выбрали с помощью обычного поискового движка, загружаете в LLM. LLM их суммаризирует в сущности, и из них создает вам ответ текстовый.

Вот как вы обычно в чат GPT разговариваете, вот обычный текстовый ответ, она такое сделает, только в нем будут вот эти ссылочки, и внизу будут урлы на документы, которые были кандидатами. Один момент, который я не сказал, это что такое обычный поисковый движок. На самом деле максимально популярно сейчас использовать не обычный как раз поисковый движок, а новый вот эти вот векторный поиск, как это называется. Файс от Фейсбука системы, но есть другие системы у разных компаний.

компании, которые занимаются векторным поиском, который, ну, обычный поисковый движок что делает? Он берет ваши слова в запросы и пытается сопоставить слова запроса со словами документа. А современные поисковые базы данных, векторный поиск, он работает по-другому. Он берет у вас весь запрос, кодирует его в какой-то вектор, а потом этот вектор ищет в базе данных векторов.

А в базе данных есть куча документов, и каждому свой вектор присобачен. И вот какой вектор ближе, такой и будет. То есть мы ищем не точное совпадение, а мы ищем... семантическое совпадение Ну непонятно как он определяется но вот векторное произведение как бы математически понятно но вот эти как это называется они

как бы теоретически кодируют смысл документа. Но что в них есть, на самом деле, мы не знаем. Мы каждый документ прогоняем через языковую модель, она нам выдает вектор, описывающий этот документ. Все эти документы мы загружаем в базу данных. Потом мы для вашего запроса точно так же читаем вектор и ищем похожие документы на запрос.

с помощью просто близости векторов. Это самая популярная система, но мне она не очень импонирует, честно говоря. Ну, возможно, потому что это синдром того, что все так делают, надо сделать по-другому. Лично я как раз занимаюсь последние полтора года активно. Альтернативным вариантом, когда мы на самом деле используем классический поисковый движок.

для поиска кандидатов. Это значит, ну вот вехтайный поиск называется dance search, он dance, потому что там dance вектора. Ну я даже, короче, это долгий разговор, мне, наверное, сложно будет сейчас это пытаться объяснить. А классический поиск, он называется Sparse Search, потому что он очень спарс вектором ищет. Ну, Sparse почему? Потому что, ну, Sparse — это разряженный по-русски. Вот у вас есть вектор из всех слов, слов там миллион, да, и только пять из них...

заполнены, а большинство из них не заполнено, поэтому он как бы разреженный. А dense, он как бы запакованный, он там, весь вектор, он гораздо меньше, он не миллион по одному размерности на каждое слово, но он меньше, но он запакованный, там все, там все числа не нулевые. И вот я сейчас как раз занимаюсь с помощью спарс поисковых движков вместо поисковых движков. У этого есть плюсы, у этого есть минусы. Ну, минусы понятно, что если у вас в документе вообще нет слов, которые есть в запросе,

то вы не найдете документ. Но, с другой стороны, у этого есть плюсы, потому что зато вы найдете документы, с которых есть слова. Вот этот семантический поиск, ну, это тоже суперсовременная технология, которая как бы иногда работает, иногда не работает, непонятно. Она, по сути, тоже вероятностная. А вот Sparse поиск, если у вас есть синхрофазотрон в запросе и синхрофазотрон в документе, то вот вы точно найдете этот документ. Поэтому он гораздо надежнее, чем векторный поиск.

Но в то же время он, да, он пропускает какие-то из документов, которые семантически близки, но в них нет общих слов. Классически с этим борются с помощью синонимов, ну, собственно, лингвисты. В поисковых компаниях они занимаются тем, что говорят, ну вот для такого слова, вот какие-то синонимы, мы их добавим в запрос как бы за курицами. Пользователи этого не видят, но мы на самом деле добавили какие-то слова, которых в запросе не было, потому что они синонимы существующих слов и так далее.

Это как бы приближает вас к более dance поиску, но тем не менее это все равно даже близко не dance. Это все еще, да, чуть более семантики здесь, но все еще все-таки слова индивидуальные матчицы. И, ну, здесь нет хорошего и плохого решения, это оба решения хорошие, просто у них разные сильные стороны, разные слабые стороны. Ну, и я занимаюсь, собственно, спарс-поиском, именно потому что все занимаются дэнс-поиском, а мне хочется быть, ну, выделиться, в общем, выпендривая себя таким образом.

видимо. Ну, и это очень интересно, это очень прикольно. Значит, что здесь важно? С помощью Retrieval Augmented Generation можно полностью избавиться от галлюцинаций. Почему? Потому что мы... Можем вообще ничего не генерировать с помощью LLM, а просто показывать найденные документы. То есть, ну, а в документах нет галлюцинации по определению, потому что мы их, как бы, печать на них поставили. Они хороши, мы их запрулили. Можно не избавляться от галлюцинации, а можно...

двигать рычажок, сколько галлюциаций мы хотим. Ну, например, если мы все-таки хотим генерировать с помощью LM суммуризацию и так далее, мы можем это сделать, но поскольку это рак задачи, мы все-таки сопровождаем всю эту суммуризацию ссылками на документы. А значит, что даже если мы...

какую-то фигню написали в summary, все равно есть ссылка, и пользователь на нее может кликнуть и найти правильный ответ. Вот, поэтому в данном случае мы как бы не полностью избавляемся от галлюцинации, но мы снижаем их эффект. Даже если они как бы есть, то и черт с ними, ну ничего страшного. Все равно есть ссылки, самое главное, что вот есть ссылочки, все аккуратно аннотировано. Это очень многообещающее решение именно для вот...

юзкейсов, которые требуют надежности. Когда требуется, чтобы мы могли положиться на ответ от LLM. Мы можем положиться именно потому, что часть этого ответа на самом деле не является ответом от LLM, а часть этого ответа является ссылками на канонические источники, которые были проверены экспертами условно.

Понятное дело, что с помощью такой системы нельзя решить вообще все проблемы, да, если вы хотите сгенерировать пост для социальной сети, то тут никакого retrieval augmented use case нету. Но если вы хотите выдавать какие-то ответы пользователю в условиях, когда... ответы должны быть из пула заопрованных ответов, то это идеальная ситуация. Это не для креативных использований.

Это для использования в бизнесе и в каких-то серьезных процессах, в которых нужна надежность. Даже не только фактическая надежность, а просто даже ощущение надежности, что мы не можем нафокапить. Пример. Мы сейчас как раз рак, например, как раз такие сосылки.

именно источники, пытаемся прикручивать к боту, который будет помогать тебе в котлинской документации ориентироваться. И документации, собранные из других источников, где как раз очень важно не просто дать ответ, а еще в этом случае нам важно дать источник на конкретный

ссылку на конкретную страницу, откуда конкретно он это взял, чтобы ты мог пойти и это перепроверить, если что. Я еще подумал, что такая технология может помочь заменить на самом деле большинство современных информационных агентств, потому что что они делают? Они находят источники и компилируют из них...

новость и выпуливают ее куда-нибудь, а дальше ты уже по ссылке на источники можешь проверить. И на самом деле даже перспективная технология, потому что большинство информационных агентств сейчас, мне кажется, занимаются довольно-таки... Мусором приходится перепроверять, что они написали, а здесь хотя бы можно этот параметр подтюнить на стороне своей модельки. Жень, тебя сейчас в Твиттере отменят. Упс. Ну, что поделать.

Ну и да, и действительно, если вы показали какую-то глупую документацию, то вы же еще и ссылку дали, и поэтому, ну, бывает, глупо, ну и что, да? Чаще всего пользователь сможет пойти по ссылке и найти точно корректный вариант, который запрулен разработчиками языка программирования. То же самое делается и в других компаниях, скажем так. Это значит RAG.

Это то, чем как раз я занимаюсь. Это вот мой личный домен, в котором я пытаюсь какие-то инновации придумывать прямо сейчас. Именно в контексте корпоративной моей работы, а не личных проектов. Есть еще... такой целый домен, это tool use, это использование инструментов LLM. Это, наверное, действительно часть такого ланчейн-подхода, но в данном случае инструменты, они...

не вероятностные, а детерминированные. Ну, сейчас мы про компилятор поговорили, но кроме компиляторов есть и другие инструменты. Можно, например, вызвать API прогнозы погоды в каком-то конкретном месте и... точную погоду знать, а не просить LLM угадать погоду, и так далее. Tool Use это тоже круто, это повышает вероятность хорошего ответа, но, опять же, оно либо повышает вероятность, но не полностью искореняет от проблемы, либо...

оно может полностью искорить проблемы за бесконечное время, потому что вам приходится в цикле бесконечно, пока не получится хорошо. Ну, понятное дело, что бесконечное время на самом деле никогда не случается, но в любом случае мы растягиваем количество... и компьютера, и времени, которое мы потратили на то, чтобы получить ответ. Потому что если компилятор у вас отрежектил код, который генерирует языковая модель, то...

Но у вас нет никакого выбора, кроме как либо сказать, ну, извини, типа, сдаться, либо сказать, ну, давайте мы еще раз попробуем сгенерировать. И вот вы делаете еще раз, еще раз, еще раз, пока не получится. Ну, и это... Не очень масштабируется. Вот, поэтому Tool Use — это, значит, такая...

Тоже технология, в общем, классная, но она все-таки в скоуп больше снижения вероятности, чем решение проблемы, в принципе. Вот в отличие от RAN, которая все-таки пытается решить проблему на корню. Но только, конечно, в тех случаях, в которых подходит такая модель. взаимодействия с продуктом. Ну и на этом, наверное, я хочу закончить, говорить про качество. Мы поговорили про целую кучу инструментов, от того, чтобы делать ретра и ретра, и до того, чтобы рак-систему построить.

И в зависимости от вашей задачи разные из этих инструментов будут оптимальными. Давай тогда, раз с качеством разобрались, у нас еще был один небольшой блок, про который хотелось поговорить. Тут, ну, я даже не знаю, насколько есть смысл на нем надолго задерживаться, потому что, кажется, все ответы и так очевидны, но все же. Вот мы там...

понимаем, как извлечь пользу из LLM, сделать наш какой-то продукт, который базируется на LLM. Есть ли какие-то отличия в процессах построения разработки, в том, как вообще разработка должна быть устроена, подход к написанию таких систем по сравнению

с обычным написанием обычных систем, обычных там, привычных нам приложений и всякого тому подобного. Короче, посмотреть на это с точки зрения того, вот мы как разработчики, например, должны ли как-то свое мышление повернуть в другую сторону и подходить к разработке иначе. Классно. Это тема, которой я тоже занимаюсь, только, опять же, не в моей корпоративной среде. Я занимаюсь этим как адвайзер для стартапов. Эта тема называется Software Engineering in AI. Как мы...

в новый век AI, продуктов и систем, можем адаптировать наши software engineering практики, которые были десятилетиями разработаны в крупных гигантах, ну и даже в маленьких компаниях. Это очень интересно. Опять же, это суперновая тема, поэтому для нее нет ответа. Но у некоторых людей на нее есть ответы. Возможно, они не идеальные, но они есть. Допустим, мы сделали кейс, у нас есть какой-то...

Мы придумали идею, значит, мы разработали наш софтверный продукт, в котором мы интрирули ЛЛМ, мы занимались промт-инжинирингом, сделали там рагни, раг, все такое. Классно сделали, оно работает. Запускаем. Окей, что дальше? А дальше что-то непонятное и сложное для типичного разработчика софта. Потому что, ну, типа, это LLM, а что с ней делать-то? Она, ну, как тут, ну, баг, у меня есть баг-репорт, а что мне сделать с баг-репортом?

LLM что-то сгенерировало. Поэтому большинство людей не понимает, что с ним делать. Но в мире есть такие люди, которые уже очень давно понимают, что с ним делать. Люди, которые занимались даже не машинным обучением, а вообще продуктами, основанными на данных и на качестве. к качестве системы с точки зрения данных. Самый простой пример, который я знаю, это вот Google PageRank. В 90-х годах гуглеры придумали PageRank и на этом построили свой поисковик.

Но если подумать, PageRank — это суперпростой код. Вся суть там в данных. И это алгоритм, который на данных работает. Полностью конфигурируется данными. И это как бы не машинное обучение. Но это очень близко по духу к машинному обучению, когда у нас вся система конфигурируется больше данными, чем кодом. Кода там чуть-чуть, а вот данных там дофига. И именно от них зависит в первую очередь качество, а не от кода.

Это такой контраст, например, с классическими алгоритмами. Есть сортировка. Классический алгоритм сортировки в основном зависит от алгоритма, от кода, а не от данных. В то время как, ну там любые данные отсортируют. В то время как вот PageRank, а также и любые машины обычной модели, они в основном зависят от данных, а не от кода. И есть в этом мире карманы таких вот команд, в которых уже десятилетиями разрабатываются сложные большие продукты, которые...

В первую очередь основан на данных. Ну, я вот из Гугла и из Яндекса, поэтому мы вот этим занимались всегда. Apple занимается этим последние несколько лет, а до того не занимался, а вот большие поисковые компании занимались с самого-самого первого дня основания их, даже еще, наверное, до первого дня.

Именно поэтому я, собственно, и начал заниматься адвайзингом разнообразных маленьких в основном компаний, потому что у меня есть такой уникальный бэкграунд, когда я, по сути, имею доступ к десятилетиям. суперкрутых людей, которые эти проблемы решили уже давно. Ну и, собственно, мы сейчас поговорим о каких-то общих вещах. Понятное дело, что...

Ну, специфика проблемы такая, что в основном это поисковые компании были, а это значит, что все эти инструменты, все эти подходы, они как-то вот заточены под конкретный юзкейс, да? А сейчас мы все подряд делаем с помощью машинообычных моделей. Все эти юзкейсы, все эти процессы, которые были разработаны, их надо как-то массировать и впихнуть в новые индустрии и новые модели интеракции с пользователем. Но, тем не менее, подходы есть. И начать я хочу с того, что...

Ну вот типичному человеку, программисту, да, вот у нас была большая кодовая база и база данных. И мы эту кодовую базу взяли, удалили и поставили на нее LLM. И как бы LLM для них... Интуитивно. Это как код. А входы и выходы — это данные. Как обычное веб-проложение. Есть база данных с данными, а есть код с серверами. Интуитивно для...

типичного разработчика, кажется, что LLM — это и есть аналог кода. Это очень важная мысль, и поэтому я повторяю несколько раз, но это неправда. Надо просто взять и забыть об этой идее. На самом деле, аналог кода — это тренировочные примеры для LLM. Если вы получили баг, то вы чините его не изменением LLM в обычной софтерной системе баг, вы чините его изменением кода, правильно? В этом случае LLM вы чините баг добавлением новых тренировочных примеров в тренировочный датасет.

Ну или если у вас нет доступа к модели, то это one-shot learning, да, как мы уже обсуждали, мы добавляем в контекст вашего запроса эти тренировочные примеры, ну или там какими-то другими способами. Но это очень важно. В данном случае, в этих машинообученных системах, аналог кода — это данные.

на которых мы тренируемся, или промпты, которые мы собрали, а не, значит, сама модель. Саму модель мы не можем менять, поэтому мы ее не можем программировать. По сути, мы ее программируем с помощью изменения тренировочного тестера. И вот это такое вот... сдвиг в мышление, которое нужно совершить у себя, чтобы успешно, итеративно мочь улучшать свои продукты с помощью LL. Это называется quality engineering в нашей индустрии. Это когда вы не software делаете, а...

quality engineering. Вы разрабатываете процессы для литеративного улучшения качества каких-то систем. И под качеством обычно понимается именно качество в таком виде, что есть precision, recall, метрики и все такое. Качество по достижению нужных показателей в метриках. Ну и да, вот... Это такое, в некотором смысле, это некий аналог. Тест-драйвинг-девелопмент. Да, когда вам пришел баг, пользователю выдалось какой-то бред. Ой-ой-ой, плохо все.

Вот у нас логи. Вот мы находим этот пример. И мы берем этот пример и добавляем в наш eval set, в наши тесты. Unit test, короче. Делаем каждый валиниционный пример в нашем eval set. Это, по сути, unit test. И мы добавляем новый пример в unit test. Потом мы генерируем...

с помощью, обычно, там, человеков, да, с помощью... Люди, которые пишут, ну, создают аналогичные примеры, там, Amazon Mechanical Turk, вот это вот, Талака, Яндекс и так далее. Они могут создавать вам... примеры тренировочные, вы просите людей, которые генерируют вам несколько тренировочных примеров, которые похожи на ваш пример, который вы в тест добавили.

А потом вы берете и дообучаете свою модель на этих новых примерах. Ну или переобучаете со старыми включительно, или добавляете их в prompt, или еще что-то делаете. Но в любом случае вы меняете данные, которые теперь код. Вот это самый главный сдвиг, который нужно совершить. В машинном обучении в каком-то смысле необходимо test driving development. Потому что все основывается на конкретных кейсах, которые можно считать тестами в каком-то смысле.

Так что если кто-то не любит test-driven development, я знаю, что много людей максимально негативно к нему относятся, то вам придется полюбить его, если вы захотите заниматься quality проектами, которые в первую очередь в которых данные главные, а не код. Ну, это вот поверхностная ситуация. Можно пробудиться чуть глубже. Мы уже много раз сегодня сказали, что вот эти все машины обычной модели, они вероятностны. Поэтому, в принципе...

добавление тренировочного примера, который сломался, это не починка бага, это вероятностная починка бага, мы снижаем вероятность этого бага, да. Поэтому тут можно подумать, что, ну да, эти тренировочные датасеты, они могут до бесконечности расти, просто у вас будут, двигаю примеры, в которые попытаются все кейсы покрыть.

Плюс для каждого кейса там достаточно одного, надо несколько, плюс несколько может и тысячи быть, если вы какой-то такой неуверенный себе человек, которому точно нужно, чтобы этого вага не случилось никогда. Их там может бесконечно быть, это, короче, не масштабируется. С этим что-то тоже надо делать. Наивный подход к решению вопроса масштабирования в том, что...

просто закрыть глаза и предоставить, что проблемы нет. Ну, окей, мы добавили три кейса, скорее всего, это починило проблему. И это самый распространенный подход, естественно. Но, конечно, в зависимости от ваших требований, иногда вам... Будет плохо, если вы, значит, плохо решаете проблемы. Иногда есть регуляторы, иногда есть какие-то другие контрагенты, которые требуют гораздо больших вложений в то, чтобы было хорошее качество. Поэтому люди пытаются придумать способы.

как сделать, чтобы ваши тренировочные десеты не были бесконечными. Условно, да. Бесконечное количество багов, бесконечное количество новых тестов у вас будет, бесконечное количество новых примеров надо добавить в тренировочные сеты. Если мы говорим не о файн-тюнинге, а о промпт-инжиниринге, то там же промпта тоже бесконечного размера не может быть, поэтому там тоже есть бюджет на сколько вы можете примеров добавить. Очень сложно. Ну и...

Это совсем cutting edge. Тут совсем нет ответов конкретных. Есть конкретные ответы, которые конкретные команды в конкретном Гугле придумали за 20 лет разработки Гугла для себя в своем конкретном узком кейсе. Но вот для общих... Для широкой индустрии непонятно, что делать. Есть, тем не менее, попытки. Есть даже стартапы, которые пытаются, собственно, продавать лопаты или кирки, и конкретно делают тулзы для того, чтобы продавать их другим компаниям.

чтобы они устраивали себе какой-то более оптимальный процесс итерации по качеству машинобычных моделей. Ну вот с одним из таких стартапов я немножко работал как консультант.

Еще раз, тут, наверное, идей может быть много, но я, поскольку это совсем Катя Нейдж, тут я не могу перечислить какой-то скоуп, который, значит, уже сделан. Я могу только говорить о том, что эксперты считают максимально... адекватным, и о том, что я в том числе считаю максимально адекватным, и то, что хоть как-то работает и показало какие-то свои, значит...

положительные качества. Возможно, через два года окажется, что все, что сегодня скажу, начинается с текущего момента, это бред какой-то был, и мы в другую совсем русло пойдем. Но, к сожалению, такова специфика домена, который очень молодой. Это правда, проблема вообще всех выпусков про EA, которые мы пытаемся готовить или писать. Мы задаем себе вопрос, а точно ли надо его писать, если через месяц, короче, все будет по-другому.

черта. Ну да, ну что же поделать. Посмотрим, посмотрим. Тем не менее, самый лучший вариант, который я вижу на сегодняшний день для того, чтобы масштабировать проблему модифицирования, по сути, программирования LLM с помощью тренировочных примеров. это погрузиться еще больше в аналогию с обычными софтвердными системами. Что это значит? Представим, что у нас есть конкретный пример, который зарепортил пользователей, но баг...

В данном случае это не вот этот пример, на котором плохо сработало, а некий кластер запросов и, соответственно, ответов, которые вокруг этого примера есть. Мы его как бы не знаем весь, но он как бы есть там, кластер. Нам предоставили один пример этого кластера.

Но мы предполагаем, что там есть целый кластер. Из этого предположения можно много чего сделать. Ну, например, можно взять ваш эволюционный сет, ну, как-то по-русски-то, эволюционный сет, на котором вы тестируете свою модель. Точнее, даже не совсем модель, а... end-to-end продукт в каком-то смысле. И посчитать ошибки. Обычно на нем есть какие-то положительные примеры, а есть отрицательные. И вот вы пытаетесь повысить процент положительных примеров. Но есть обычные ошибки.

И вот с этими ошибками можно тоже представить, что каждая ошибка — это не конкретный пример плохой, а вот есть какой-то целый кластер гипотетический, из которого эта ошибка была засемплирована, но, в принципе, там больших. И эта идея приводит нас к тому, что, а давайте мы возьмем все ошибки на нашем каком-то сети, который валидационный наш, и кластеризуем их. Ну вот я рассказывал про приложение, которое генерирует предложение на немецком языке, да, с дырками.

Вот я, значит, смогу сделать 10 миллионов запросов в chat GPT, сгенерировать 10 миллионов примеров с разными словами, с разными, значит, темами и так далее. А потом провалидировать все эти примеры и все ошибки, которые, ну, неправильные примеры, которые плохо сработали.

Кластеризировать. Опять же, каким образом? Ну, я могу, например, задавать обратно в OLM-запросы. Типа, а вот в чем здесь была ошибка? Ну, и в зависимости от ответов, я могу там посчитать, например, статистику по словам какую-то. Где-то будет там...

про дырку что-то сказано, про вот закрытое слово, где-то будет еще что-то про что-то сказано. И вот я просто как-то вот так вот с помощью каких-то эвристик посчитаю и кластеризирую на несколько типов ошибок. И дальше я могу решать, опять же, в предположении, что...

баг — это не конкретный пример, а целая какая-то облачка, кластер какой-то, я могу сказать, ну, я возьму пять примеров из этого конкретного кластера и добавлю их в тренисет. И внезапно мне не нужно бесконечное количество примеров. На каждый конкретный провал мне не нужен пример.

Мне нужно понять, с какого кластера этот пример, и сказать, ну вот я с этим кластером справляюсь с помощью добавления нескольких примеров в этот кластер. Итого у нас есть бесконечное количество проблем, возможно. У нас есть теперь конечное количество кластеров.

Ну, оно тоже может быть большое, их может быть тысяча, но их уже не будет миллиард, правильно? Скорее всего. Надеюсь. Ну, и опять же, да, я надеюсь. Это единственное, что я могу сказать. Пока что такие системы, они разрабатываются, они тестируются, у них есть какие-то...

Promising свойства, которые помогают компаниям действительно, но, как бы, может быть, это частный случай. Хрен знает. Из этой идеи, значит, мы можем разобрать систему. Когда вы регулярно проводите... анализ качества вашей модели, ну что, в принципе, просто сделать, у вас есть датасет, на котором вы проверяете модель, плюс у вас все время баг-репорты, которыми вы пополняете этот датасет, вы регулярно в нем тестируетесь, а потом CI-система ваша, она как бы не просто репортит, вот...

Она их берет, собирает в датасет, работает с ними, например, использует другие машины обычной модели, использует какие-то простые алгоритмы, эвристики, которые классифицируют и кластеризируют эти проблемы. вам выдается репорт, что типа, ну вот, ваша модель компьютерного зрения не работает в тумане. Вот мы сделали кластер провальных примеров, на которых везде туман.

Мы вызвали API, или какой-нибудь API классификации картинок, и эта API нам сказала, что у нас есть 50 примеров, на которых на всех есть туман, и они все ошибки нашей модели. Ну и вот мы их... скажем, ну, кажется, что мы идентифицировали, что наша модель не работает на тумане. Давайте мы сгенерируем нам 100 фотографий с объектами в тумане, значит, и добавим их в наш тренировочный уже датасет. Ну, это с компьютерным зрением, то же самое можно с языковыми моделями делать.

Да, например, я разрабатываю приложение для изучения языков, и, может быть, окажется, что у меня там на испанском, значит, оно очень плохо себя генерирует, и у меня будет кластер. Испанские примеры, короче. Вот они, значит, и мне будет отправлено.

Ну, вся система у меня сделает репорт, в котором скажет, что вот сфокусируйся на испанском языке. Ну и дальше вопрос, что с ним делать. Если бы у меня была своя языковая модель, то, конечно, я могу просто взять и зафантюнить ее или дообучить ее с помощью больших примеров на испанском языке.

Когда я использую API, у меня меньше возможностей, но, по крайней мере, я могу уже потом пойти в компанию в OpenAI, скажем, и если у меня с ними контракт, то я могу с ними начать говорить о том, как бы они улучшали модель для моего юзкейса. Такие пироги.

Примерно так сейчас есть некоторые стартапы, которые пытаются разрабатывать что-то подобное. Ну, я пытаюсь предложить такие системы внутри больших компаний тоже. Наверное, где-то в Гугле кто-то уже тоже придумал это. Вот здесь у нас я пытаюсь это построить. Круто. Спасибо очень подробно. Мне кажется, мы готовы переходить к закрывающей части нашего выпуска.

Мне кажется, мы суперподробно разобрались в теме, насколько это возможно вообще сейчас сделать за двухчасовой выпуск. Как мы разобрались? Макс рассказывал, а мы с тобой слушали. Да, ну, в смысле, послушал, тоже разобрался.

Честно скажу, я тут готов подхватить наш старый-старый мем, который я никогда не использую, но есть у нас мем про то, что перспективная технология, надо обязательно пойти попробовать что-нибудь сделать. Правда, захотелось пойти что-нибудь попробовать сделать. И я подозреваю, что я такой не один.

Наш слушатель послушает и тоже, скорее всего, загорятся. Поэтому давай попробуем сейчас абсолютно по верхам хотя бы просто задать направление, может быть, какое-то. В общем, послушает какой-нибудь слушатель наш этот выпуск. загорится, такой все, я теперь LLM энтузиаст, я хочу что-нибудь такое прикольное сделать, вот у него есть какая-то там идея, например, что делать-то вообще, потому что есть API всяких разных там OpenAI или кого-нибудь еще.

Есть лама, которую выкладывает в Facebook, еще говорит, вот есть с таким-то количеством параметров, с таким-то количеством параметров. Есть там энтузиасты, которые регулярно постят в Twitter, как они купили себе очередную видеокарту, из нее собрали себе специальный мощный... комп, чтобы...

сделать оффлайн систему видеонаблюдения домашнего на базе локального LLM. Привет, Артем Зинатулин. Энтузиасты в скобках Артем Зинатулин. Да, да. Ну, короче, кажется, есть целый зоопарк решений, которые мы... можно делать, они все абсолютно разные, опять же, начиная с облачных API, заканчивая какими-то локальными штуками.

И еще и непонятно, то есть вот есть лама с таким-то количеством параметров, с таким-то количеством параметров, что достаточно, что недостаточно. Давай попробуем здесь какой-то очень базовый гайд дать слушателям, как разобраться, с чего начать, на что смотреть, на что не смотреть. Короче, такой быстрый.

способ вкатиться и начать разбираться. Ну, вы мне предлагаете, значит, рассказать примерно, не знаю, миллион человек или от опыта индустрии все из последних нескольких лет. Все так, да. За пять минут. Делать можно что угодно. Делать можно что угодно. Окей, ладно, давайте с чего начать. Начать с того, что есть API, а есть модели. Вот вам надо выбрать, вы хотите модель или API. Трейдов здесь понятные, за API надо платить, но зато они все делают за вас.

За модели платить тоже надо, потому что где-то надо их хостить. Но, конечно, выйдет, может быть, дешевле, а может быть, нет, кстати говоря. Но зато тут дело даже не в цене, а в том, что вы можете с моделями гораздо больше всего делать. Это может быть плохой вещью, потому что вы можете испортить ее. Но в то же время вы, как я уже сказал, можете добавлять тренировочные примеры и фонтюнить, вместо того, чтобы...

промптом инжинирингом заниматься, вы можете файн-тюнить модель. Это гораздо более мощная штука, потому что вы один раз потратили компьютер, а потом у вас все промпты лучше стали. Ну, по крайней мере, в вашем конкретно муском юзкейсе. Ну и да, это первое решение, которое вам надо сделать. Вы хотите API или вы хотите модель. В зависимости от того, нужно ли вам фонтюнить или нет, это будет разное решение.

Дальше есть решение, ну как с этим работать. Но если вы уже, предположим, что вы уже умеете разрабатывать софт, то вам нужны конкретные только дополнительные навыки. работы с LLM и интеграции их в софт. Ну, вот сегодняшний подкаст, я думаю, был хорошим подспорьем в том, чтобы, по крайней мере, понять вообще, что бывает, какие вещи можно делать.

Но, как еще раз мы несколько раз повторили, это очень новая индустрия, поэтому, ну, на самом деле, наверное, есть куча всего, что вы можете вообще сами изобрести. Вот я, например, изобрел свой лангчейн, даже когда еще не было лангчейна. Мне даже в голову не пришло, что я что-то изобрел. Я просто код написал, который несколько запросов делал. Ну и то же самое, скорее всего, случится с вами.

Это не какой-то rocket science. Там есть и rocket science, но многие вещи не rocket science, выполняя себе просто такие практики, которые можно изобрести с нуля. Я думаю, что мы очень хорошо начали наш сегодняшний подкаст с того, что...

Самое главное — это идею придумать. Если вы придумаете идею, то стопудово вы что-то сделаете, потому что если даже у вас нет непосредственных навыков, вы всегда можете найти энтузиастов и разработчиков, которые с удовольствием с вами поработают и с удовольствием что-то запустят совместно.

Сейчас попробую так сформулировать совсем по-простецки. Допустим, решили... Потому что проще затестить какую-нибудь облачную API, потестили, поняли, что чего-то не хватает, не хватает гибкости, вот после этого идти, допустим, прям заморачиваться, усложнять, разворачивать у себя где-то, то есть брать именно уже модель, а не API.

это нормальная ментальная модель для вкатывания, чтобы как бы снизить порог вхождения. Да, я задаю странные вопросы, я понял. Тут больше гораздо размерности, чем то, что было упомянуто. Потому что, например, есть...

Вопрос. Окей, а можешь ли ты вообще данные своих пользователей отправлять в OpenAI? А согласились ли они на это? Вопрос. В зависимости от твоего юскейса, ответы на этот вопрос могут быть очень разными. В зависимости от твоих пользователей, ответы на этот вопрос очень могут быть разными. И так далее. Поэтому решение обычно исходит из ограничений. Я не знаю ограничений в гипотетическом сценарии моего слушателя.

Поэтому в зависимости от них у вас будет разное решение. Я могу вам подсказать, если вы ко мне придете и спросите, вот у меня есть такие-то ограничения и такие-то задачи, которые я хочу решить. Я в конкретной ситуации могу подсказать, какие из этих инструментов... больше подойдут, какие меньше подойдут, но какие вообще нельзя использовать, запрещено. Да, вот, например, как раз недавно я работал с коллегой, который занимается регуляторами, то есть он вообще юрист.

Вот, и у нас даже есть европейский AI-акт, недавно приняли. Это законодательная платформа для регулирования AI-продуктов. Причем определение AI вас шокирует, определение AI, которое у них есть, короче. Там написано, что это программные системы, которые принимают решения. Вот, то есть, if, да, if, значит, x больше нуля, то а, иначе b, это программные системы, которые принимают решения. И это как бы AI.

То есть там очень тяжело все с этим делом, и что такое вообще я, и как ваши юзкейсы с регуляторами будут алайниться. Ну, сейчас это только Европа, но Штаты тоже не с горами, я уверен. и так далее. И, скорее всего, весь мир будет потепенно прижимать это все. Вот, поэтому слишком сложный этот вопрос, чтобы на него в общем ответить. На него надо отвечать в частных конкретных случаях.

и обсуждать уровни рисков, уровни договоров, которые есть, всякие разные ограничения, которые есть у конкретного юзкейса. На самом деле, на мой взгляд, ответ супер, потому что как раз... Сложные ответы на такие вопросы дают понять...

как надо про это думать, и с какой стороны нужно подступаться, и дальше уже в какую сторону копать самому и разбираться. Допустим, там про всякие регуляции, на мой взгляд, не самая очевидная штука, то есть не всем в голову придет сначала вообще разобраться, что, наверное, OpenAI не подойдет, потому что, блин, тебе

придется сильно упороться, чтобы получить разрешение. Короче, соблюдать все регуляции по privacy и вот этому всему. Я тут хочу, наверное, еще такой момент сказать. Если вы чат-интерфейс делаете, то пользователь ваш... может в ваш чат-интерфейс ввести номер своей карточки банковской, а вы ее в OpenAI отправили. И тут на вас может обрушиться целый шквал проблем. Если это так случится, и это раскроется, и, в общем, это в прессе осветится, то это будет бомба.

Поэтому это очень-очень-очень нюансная и важная тема, сделать все хорошо. Поэтому, да, мне, конечно, хочется сказать лучше свои модели, потому что, типа... стрёмно работать с внешними провайдерами. Ну да, да. Супер. Вот на этом... Предлагаю подводить черту под этим выпуском. И давайте буквально в двух словах вспомним, о чем мы сегодня поговорили. Мы сегодня говорили про разработку приложений над LLM, вокруг LLM, как угодно называйте его.

в общем, приложение, которое базируется на использовании больших языковых моделей. И начали мы с того, что, собственно, поговорили вообще про... качество результатов и выхлопа, который дает LLM, и какие там есть проблемы, и как с этими проблемами бороться, и пошли снизу вверх, начиная от того, как с этими проблемами можно справляться на уровне самих моделей, то есть как-то добучая их.

занимаясь alignment этих самых моделей, и потом перешли уже непосредственно с точки зрения потребителей этих моделей, что можно делать, когда ты используешь какую-то уже настроенную The FineTuning модель и пытаешься ее ответ подстроить под нужды своего продукта.

И там, на самом деле, было очень много всего разного, начиная от простецкого сэмплинга, когда ты регенерируешь выдачу модельки, заканчивая сложными, ну как сложными, мы уже поняли, что это, на самом деле, очень простая история, лэнгчейн, но которая позволяет делать... логику намного более мощную

комплексную и чуть лучше решать ваши задачи. И дальше, дальше, дальше поговорили про оффлайн-сценарий. Собственно, очень крутой кейс Макса с его приложением для изучения немецкого. Собственно, подумал, что кажется, я свое хобби, которое у меня очень давно тянется по изучению. испанского. Могу таким образом попробовать бустануть. Идея мне очень понравилась. И заканчивая так называемым RAG, я аббревиатуру, к сожалению,

Не запомнил. Но, в общем, вы можете это вспомнить, потому что когда мы совмещаем, грубо говоря, логику... поисковика и, собственно, выдачи языковой модели, когда мы сопровождаем выдачу какими-то референсами, которые можно саму прокликать, посмотреть. Ну и все это дело зафиналили... обсуждением того, как нужно пересмотреть свои подходы к software engineering, то есть к тому, как вообще разрабатывать такие системы, что там есть интересного. Много чего. Спойлер. Просто...

Просто надо взять и послушать, и все будет понятно. И зафиналили тем, как вкатиться в LLM, если вы LLM энтузиаст. Здесь тоже спойлер, простых ответов нет. Нужно садиться, нужно разбираться, понять, что для вас подходит, что для вас не подходит. в каких случаях локальные модели, в каких случаях API. В общем, это все не так просто. Очень много корнер-кейсов, про которые вам нужно будет обязательно подумать.

Макс, спасибо большое, что к нам пришел. Это был очень крутой, на мой взгляд, очень плотный выпуск. Мы прям хорошо, последовательно, структурно пошлись и, мне кажется, раскрыли очень много всего. И самое прикольное, что он, на мой взгляд, правда, побуждает пойти...

какие-то штуки с того, что мы обсудили, попробовать, потестить, потыкаться, посмотреть, как оно работает. Очень круто. Спасибо, что согласился к нам прийти. Спасибо за приглашение. Да, учитывая твой опыт в работе в Фанге, мы, я думаю, еще придумаем тем, куда... тебя можно позвать, потому что ты у нас такой гость многообещающий. Я смотрел, недавно был выпуск про это. Ваш выпуск недавно смотрел, у меня был Батхёрд. Сколько людей в фанге, столько мнений.

Спасибо тебе большое Женя, можно задать тебе вопрос? Да, конечно Что тебе нравится больше, чем понимать, что есть еще одна категория пэт-проектов или стартапов, которой ты никогда не займешься, потому что ты, Женя, офисный червь, как и я. И нет времени на пэт-проекции.

Сейчас дисклеймер, если я выдам неподходящий для тебя ответ, ты можешь перегенерить свой... Ну, все повторно вкинуть в меня вопрос, я выдам какой-нибудь другой ответ. Но больше этого, дорогие друзья, мне нравится, когда вы ставите нам 5 звезд в iTunes и твитите-ретвитите, это все... Понятно, но еще теперь вы заходите к нам на YouTube-канал, подписывайтесь, жмете там колокольчик, пишите нам комментарии под нашим выпуском, что понравилось, что не понравилось. Заходите к нам в Telegram.

чат, подписывайтесь на наш телеграм-канал. В телеграме обязательно приходите и пишите ваше мнение про наши прошедшие выпуски. Опять же, что понравилось, что не понравилось. Если есть какие-то вопросы нашим гостям, не стесняйтесь их там задавать. Мы эти вопросы перейдем. дадим нашим гостям. В некоторых случаях постараемся гостей убедить вступить в наши чаты и поотвечать на эти вопросы. Who knows? Вдруг сработает. Что еще? Да на самом деле самое главное...

Слушайте подкаст Подлодка, рассказывайте о нас своим друзьям и коллегам. Да, в общем-то и все. Это был выпуск подкаста Подлодка про приложение на LLM. Всем спасибо и всем до новых встреч. Пока-пока. Пока.