response_format={"type": "json_object"}
Вам квиз со звездочкой на подумать, что-то из серии вопросов для собесов по LLM:
1. Как меняется время генерации при разном N?
2. Интуиция, почему так происходит, и как технически это реализовано?
Ожидаю рассуждения и обоснования. Предпочтительно чтобы ответ был с графиком.
Разыскивается толковый дизайнер который рисует иконки/логотипы как господь
Если вы таковым являетесь, либо есть кого-то порекомендовать, напишите пожалуйста в лс @uberkinder
Желательно сразу портфолио и стоимость
https://twitter.com/sama/status/1727207458324848883
Читать полностью…
Если вчера вы проснулись утром и open ai заблочил доступ к вашему API — вот что можно сделать.
Хотфикс инструкция на 5 минут:
1) купить европейский прокси (например тут: proxy.market)
2) подключить в нем socks5 (в коменте инструкция)
3) в определении клиента прописать креденшлы прокси
client = OpenAI(
api_key="sk-...",
http_client=httpx.Client(
proxies="socks5://username:password@ip_address:port"
),
)
4) Profit, теперь ваш трафик ходит в open ai
PS Эту инструкцию не воспринимать как секьюрную. Может ли снифить ваш траф провайдер — я не знаю. После норм решения (деплоя в евро сервер) лучше обновить api key
Илья Суцкевер рефлексирует о том, как зарождался OpenAI: как случилась легендарная встреча с Илоном, Сэмом и Грегом, его личные мысли о миссии OpenAI, про его Vision, а также о трудном решении покинуть Google Research.
https://youtube.com/watch?v=j_JW9NwjLF8
UPD для разработчиков: лимит запросов для GPT-4-Turbo существенно повысили, до 10,000 запросов в сутки (было 200). Лимит сохранился для vision-модели, обрабатывающей изображения.
За новость спасибо Богдану @bogdanisssimo
Co-Author 3/3: How?
Как работает Co-Author? Это простой streamlit-сервис, где ты можешь вписать какую задачу нужно создать (подходит сырая формулировка запроса от студентов), он выписывает ключевые уроки которым мы хотим научить, далее мы прокликиваем в каком домене и какой сложности хотим задачу, какого она типа (одношаговая "one-shot" задача / задача-challenge / длинный квест / и т.д.) – и Co-Author сперва декомпозирует задачу на шаги, затем пошагово генерирует каждый шаг (суммаризуя предыдущие страницы), включая решение, требования к решению и тесты в проверяющей системе для решения.
Пока это работает на уровне драфта и нуждается в большом объёме последующей редактуры, но костяк, фундамент задачи это уже закладывает, поэтому дальше – легче. Ребята (как непосредственные пользователи) сами находят, в чём им сейчас Co-Author неудобен, где хочется перейти в ноушен или ChatGPT, и сами же совершенствуют этот инструмент (что является вполне боевой практикой работы с LLM).
P.S. Через пару-тройку месяцев мы расскажем, как поживает наш AI-инструмент, вероятно со временем он из генерации контента эволюционирует в copilot-помощника для контент специалистов. Нам будет интересно почитать и ваши пробы пера с LLM внутри EdTech'ов, делитесь опытом в комментариях.
#LLMOps
Co-Author 1/3: Why?
Один из навыков, которому Меня научила книга Валеры и Арсения, – это "видеть лес за деревьями": смотреть на систему целиком (в контексте, а не в вакууме); думать о дизайне системы (и это касается не только ML-сервисов); да и вообще, документировать дизайн систем, с которыми работаешь или которые строишь. В частности, перенос этих знаний так или иначе происходит на менеджмент.
Я развиваю Симулятор ML почти 2.5 года, за это время мы с командой младших авторов (@avalexey @unipply0 @redpf) и project-менеджерами успели перестроить процессы несколько раз, попробовать много разного и прийти к некому более-менее устоявшемуся флоу, которого придерживаемся по сей день, и который продолжаем совершенствовать. Об одном недавнем кардинальном улучшении Я не могу умолчать...
Значит, решили мы в августе систематизировать весь процесс разработки контента от идеи до релиза. Мы написали Мастер-Документ на 7000 слов, который содержит, например:
• Какими принципами мы руководствуемся при написании задач? Каким мы дизайним опыт (UX) для студента?
• По каким метрикам мы определяем качество продукта? – у нас есть целая иерархия метрик от верхнеуровневых денег / костов – до числа багов, разнообразия по доменам и проектам, проходимости, качества текста / картинок / числа отсылок задач друг к другам (к слову, конкретно к этому подтолкнула глава книги "Loss functions and metrics");
• Какая анатомия задач? Какие подвиды задач? – чтобы вы понимали, задачи состоят из истории (мы в таком-то продукте, вот такая проблема, сходи туда, выгрузи то, подумай какую модель применить здесь), теории (и ссылок), требований к решению, решения и самой проверяющей системы, и наконец, картинок в нашем уникальном стиле;
• Как формируем и приоритезируем беклог спринта? Где берём идеи для новых задач? (часть предлагают студенты в нашем Upvoty, часть придумываем мы);
• Какой у нас Definition-of-Done? Как/когда мы релизим? Что делаем после? Где собираем баги?
...и многое другое.
P.S. В комментариях делюсь парой лайфхаков.
#management
Эмоциональный интеллект (EQ). Что для Вас означает эмоциональный интеллект, какой смысл Вы вкладываете? Как бы Вы оценили свой эмоциональный интеллект от 0 до 10? Как он менялся с течением времени? Над каким его аспектом, Вы думаете, Вам нужно больше работать?
Читать полностью…
LOGBOOK
Читаю Logbook по OPT-175B – документ, состоящий из сырых ежедневных заметок, которые писали инженеры по мере обучения модели. Он содержит статус-апдейты, возникшие проблемы и принятые решения по их починке, неожиданные находки, рекомендации и т.д.
Для понимания, тренировка модели заняла порядка 3 месяцев и длилась с 20 октября 2021 по 6 января 2022.
https://github.com/facebookresearch/metaseq/blob/main/projects/OPT/chronicles/OPT175B_Logbook.pdf
Logbook ценен с многих точек зрения:
1. Во первых, он отвечает на вопрос, а что такого сложного в обучении LLM (после того как архитектура модели зафиксирована)?
2. Во вторых, он даёт адекватное понимание, чем наполнены будни инженера из топовых персентилей. Вообще, было бы клёво иметь подобные логи по разработки разного типа и масштаба систем. Но их почти никто не ведёт. 🙃
3. В третьих, интересна сама дисциплина документировать всё что делаешь и логировать решения которые принимаешь (прямо как NPC в игре Sims – в углу экрана всегда видишь, а о чём он сейчас подумал, а куда он сейчас решил пойти, что сделать). Насколько Я знаю, в серьёзных местах вроде того же OpenAI и Anthropic эта практика весьма распространена.
Это позволяет другим быстро понять, а что было сделано, уловить контекст, понять, какие гипотезы попробованы, что лежало в основе тех или иных решений в дизайне системы (аналогично, можно вести логи менеджерских решений).
____
Сам Я последнее время (пока для себя), стал тоже всё чаще вести логи того, что делаю, какое препятствие встретил, в чем, как думаю, проблема, какая гипотеза по её решению и т.д. Это помогает входить в поток, одновременно проясняя разум, и в конце дня – оставляет артефакт прогресса который ты сделал за день. Логи веду в Session (приложение для трекинга времени, суммарно подобными штуками пользуюсь последние лет 6 на ежедневной основе). Заметки открываются прямо во время начала сессии, сразу удобно накидывать мысли.
Так, а вы балуетесь подобным?
Задумайтесь, что спустя целый год, всего 1.2% населения Земли пользуется ChatGPT (100M WAU).
Пользователей, у кого есть подписка Plus (и доступ к GPTs) – ещё на 2 порядка меньше.
Сколько возможностей открывают эти два факта? 😈
Лайфхак, как сэкономить деньги и время
Если паттерн использования вашего сервиса таков, что зачастую пользователю нужна повторная генерация чего-либо много-много раз (например, если ваш сервис помогает брейнштормить идеи), тогда имеет смысл воспользоваться правилом оптимизации №1:
Не делай 2 раза то, что можно сделать 1 раз.
Когда мы генерируем много ответов (через параметр n в API GPT), то можем выдавать первый (или лучший, если мы дополнительно прикручиваем оценку), а остальные сохранять в памяти. Когда пользователь нажимает кнопку "перегенерировать", ему мгновенно выдаётся второй вариант, а затем мгновенно третий и т.д. Благодаря этому мы экономим ту часть коста, которая относится к длине входа (например, это длинный промпт с инструкцией и примерами) – и время не повторную генерацию, что улучшает UX.
Здесь есть очевидный трейд-офф:
- с одной стороны, если мы генерируем с запасом 5-10-20 ответов, то пользователь может не расходовать все из них, отсюда деньги тратятся вхолостую;
- с другой стороны, если ему таки нужны эти 5-10 попыток, вероятно гонять каждый раз длинный промпт с инструкцией – выходило бы дороже (и дольше);
- наконец, если у вас есть оценка ответов, на основе которых можно отфильтровать топ-N, то генерацию холостых ответов можно воспринимать как необходимое зло, которое было нужно, чтобы засэмплить ответы лучше по качеству.
По большей части игра стоит свеч, когда у нас промпт сильно длиннее ответа (в десятки-сотни раз).
P.S. Да, и ответы на вопросы из предыдущего поста:
1. На практике считаем, что время генерации O(1) по отношению к числу ответов – за счёт этого при предгенерации десятка другого ответов, мы не добавляем времени
2. Свою интуицию, почему так происходит, описал здесь: /channel/bogdanisssimo/264?comment=3486
#LLMOps
А сегодня важнейшая дата, ChatGPT исполняется 1 годик, Я его искренне поздравляю с днём рождения. Ты такой маленький, а уже такой полезный в работе и в жизни. Нам стало трудно вспомнить, какой была жизнь без тебя 🤗
Желаю тебе дальнейшего роста capabilities, ускорения генерации и удешевления компьюта!
Citius, altius, fortius
Месяц назад Богдан решил уйти с основной работы и основать свой AI-стартап, поэтому в этом блоге будет расти число постов о том как же больно (но увлекательно) играть в фаундера.
Читать полностью…
У Игоря вышел краткий пересказ свежего подкаста с Ильёй Сутскевером про движение к AGI, open source модели, Superalighnment и то, насколько современные архитектуры моделей напоминают пластичность нашего мозга:
/channel/seeallochnaya/821
Рекомендую
Вчера был DevDay от openai, где представили несколько новых любопытных обновлений. Главное из них — GPT-4 Turbo! Еще более умная версия 😎
1. Размер контекста GPT-4 Turbo увеличили в 16 раз по сравнению с предыдущим. Для сравнения Сэм сказал, что это примерно 300 книжных страниц
2. В API завозят json mode аутпуты. То есть теперь не нужно будет выцеживать нужную информацию из текстового ответа, можно ее просто явно запросить
3. Знания модели не будут ограничены 2021 годом, сейчас модель знает про мир до апреля 2023го. И разработчики пообещали поддерживать модель актуальной
4. В API теперь можно будет прокидывать картинки (а не только url как было раньше), в GPT-4 turbo будет интеграция с DALLE-3. Кроме того, обещают скоро открыть Whisper v3, в котором будет еще больше языков
5. Откроют gpt-4 для файнтюнинга в экспериментальном режиме. Заверили, что на данных которые юзеры используют для дообучения они не учатся. Анонсировали b2b дообучение моделей под нужды клиента
6. Повысили лимиты токенов в минуту, сделали более приятный прайс. Если нужны еще более высокие лимиты, можно отправлять запросы
The legend scientist shaping our world. A deep thinker, a designer of the future and a source of inspiration for many of us.
https://youtu.be/9iqn1HhFJ6c
Co-Author 2/3: What?
Дописав мастер-документ, смотрю, значит, на него, перечитываю и такой: "блин... да ведь это же план!"
Когда ты описываешь любой бизнес-процесс целиком, то сразу замечаешь несовершенства, узкие места, паттерны, проблемы. Тут же приходят идеи что можно улучшить и автоматизировать.
В задачах Симулятора, в которых Я выступал исключительно в роли менеджера, самым проблемным местом были идея, план и драфт задачи. Долгое время мы пробовали работать в сетапе 1 человек = 1 задача. Позже (за идею спасибо Адаму Елдарову) мы перешли на сетап когда за разные части задач отвечают разные люди.
Я взял на себя часть с декомпозицией задачи на шаги и первым шагом с завязкой (напомню, задачи в виде многошаговых квестов, после каждого шага ты продолжаешь историю и узнаёшь больше) – она была для ребят самой сложной, занимала больше всего итераций ревью, и была блокером для последующей разработки задачи.
Тут Я пришёл к мысли. На самом деле, то, в чём Я помогаю ребятам, это, хоть и (Мне лично) не сложно, но всё равно занимает время. Эти начальные части задачи (план + завязка) требуют 2 ингредиента: (1) насмотренности в машинном обучении и ML-продуктах, (2) навыков письма. Как известно, ChatGPT умеет писать текст и имеет common knowledge, достаточные для того, чтобы научить новому – не только студентов, но и самих младших авторов. Так они по мере обучения студентов, учатся новому сами (как они признаются, они работают в Симуляторе ML не ради денег, а ради опыта).
Co-Author. Уже месяц как мы тестируем и улучшаем внутренний продукт, который уже сокращает время разработки контента уже на 20-30% для задач уровней Intern и Junior (не говоря уже о том, что он убирает из цепочки Меня). Ожидаемо, что эту долю (в ходе пошаговых улучшений и интеграции с Notion API) нам удастся увеличить, консервативно, до 50%, оптимистично, до 80%.
Показываю демку месячной давности.
#management
INTENT
Продолжаем в свободное от работы время баловаться с LLM. На этот раз поговорим о ещё одном паттерне LLM-систем.
При создании LLM-продуктов, особенно важно добиваться бескомпромиссно простого и интуитивного взаимодействия с пользователем. Для этого интерфейс должен быть максимально простым с одной, максимум, двумя точками входа. Но как запихать много разного полезного с таким жёстким требованием? Вариант с десятью кнопками отпадает сразу, глаза будут разбегаться и лишние фрикции в UX убьют продукт. Ведь через месяц кнопок придётся делать 11, а через год уже 20. Вариант не масштабируемый от слова совсем.
В блоге "LLM под капотом" прочитал про такую штуку как классификация интентов. Богдан человек простой: узнал новое – бегом пробовать. Сегодня затестил интенты.
Классификация интентов – это буквально чтение мыслей пользователя. Идея тривиальная: "давайте пользователь будет нам писать обычные сообщения, как он писал бы живому человеку, а бот сам разберётся" – на входе будет стоять LLM, которая поймёт, о чем он просит, и перенаправит запрос на нужный специализированный модуль (где, скажем, стоит отдельный RAG под свою задачу).
Очень напомнило Traffic Router (маршрутизатор трафика) в арбитражных платформах, который по IP тебя вычислит и перенаправит ("приземлит тебя") на нужный лендинг.
P.S. Прикрепил пример как может выглядеть промпт для такого LLM-маршрутизатора: мы банально перечисляем все доступные на текущий момент режимы работы (c XML-тегами) и просим классифицировать запрос пользователя. Затем if "<intent>" in response и поехали.
Батут работает.
#LLMOps
SLEEP DEBT
Взялся восстанавливать сон. Скачал приложение RISE (раньше уже пользовался, был доволен как слон). Кроме анализа сна, приложение прогнозирует твои пики энергии в течение дня, даёт советы, какое время лучше выделять под Deep Work (с учётом сна и времени пробуждения), а какое под Shallow Work. Учитывает прием кофе, мелатонина, тренировки; даёт план как нормализовать сон и сдвинуть подъём к желаемому времени (говорит, во сколько согласно плану лучше сегодня готовить ко сну, с какого времени избегать кофеин). В общем, ещё много других полезных фишек.
В основе приложения лежит исследование, главный вывод из которого в том, что самый важный предиктор того, насколько хорошо мы будем перформить в течение дня, это не число REM фаз или что-то ещё, а банально Sleep Debt (буквально, "займ сна" или "нехватка сна"). У каждого человека есть необходимое время сна, которое можно померить. Чем ты больше от него отклонялся за последние 7 дней, тем хуже реализуешь свой энергетический потенциал.
На их сайте RISE есть целый Sleep Guide, который будет ценен и без приложения. Приложение уже геймифицирует процесс поддержания гигиены сна и персонализирует советы на основе собираемых данных о тебе. Highly recommended, не могу не поделиться таким золотом. Отдельное внимание заслуживает дизайн, с точки зрения UI/UX редко когда встречаю такие приятные игрушки.
P.S. Не удивляйтесь, если вскоре вслед за одним старшим главным начальником начну писать посты про матрасы.
https://botharetrue.substack.com/p/every-app-that-adds-ai-looks-like
Читать полностью…
RASMUSSEN SYSTEM MODEL
Например, в одном месте Грег делится ссылочкой на лекцию о том, как он мыслит о сложных системах со словами "I think this is the best (and only, really) framework I've seen on how to think about running a complex system". Лекция короткая, на 19 минут, и будет полезна любому инженеру и техническому менеджеру.
Идеи из лекции:
Сложная система адаптивна: её состояние в каждый момент времени "танцует" между тремя границами:
1. окупаемость (хватает ли нам денег её поддерживать?),
2. поддерживаемость (хватает ли нам рук её поддерживать?)
3. работоспособность (выдерживает ли нагрузку? учащаются ли ошибки, поломки, проблемы?)
Мы стремимся сделать систему дешевле (экономически эффективнее), отодвигая от границы окупаемости – и "автономнее", чтобы починка багов не отвлекала от добавления нового функционала. Обе эти оптимизации не даются бесплатно и ведут состояние системы – ближе к границе работоспособности (соответственно, система работает "на пике", значит, выше риск проблем).
Что же делать? Очерчивать пунктиром красные линии для допускаемой работоспособности? Вводить новые регламенты и субъективные ограничения перед физическими ограничениями?
Нет. Как сказано в начале, мы строим адаптивные системы, которые несмотря на желание сократить косты у менеджеров и на лень инженеров – на удивление работают и даже... относительно редко падают. Что обеспечивает эту адаптивность? – Люди.
Здесь мы приходим к важности мониторингов, алертов, опережающего реагирования, наконец, нашего собственного обучения по мере работы с системой. Это контрастирует с идеей, что достаточно наперёд просчитать на салфетке все нефункциональные требования, собрать систему по лекалу и закрыть сервера в бункере, чтоб никто не трогал.
P.S. Впрочем, не исключено, что через пару лет мы придём к практике навешивать пару-тройку LLM-агентов, завязанных на мониторинги и алерты, для оперативных починок и корректив наших систем, и тогда точно можно закрывать в бункерах!
https://www.youtube.com/watch?v=PGLYEDpNu60
Highly recommended.