17086
Канал про разработку продуктов на базе LLM/ChatGPT. Выжимка важных новостей и разборы кейсов.
Вышла Claude-v2, вот бенчмарки
Похоже, что проклятие второй версии не минуло и Claude-v2.
Пока выходит, что claude-v2 в наших продуктах работала бы хуже первой версии. За просадку в категории "code" не так жалко, а вот за docs, integrate, marketing - обидно.
Но в "reason" - она догнала ChatGPT-4 новый!
Про бенчмарки подробнее написано тут. Со времени последнего отчета, я усложнил часть бенчмарков, чтобы GPT-4 было к чему стремиться 🚀
Спасибо @Dimasfer за ключ для тестирования! 🙏💪
Ваш, @llm_under_hood 🤗
Vic принес в чатик интересные скрины про архитектуру GPT-4.
- GPT-4 в 10 раз больше GPT-3, 1800B параметров и 120 слоев
- Но, внутри пачка экспертов (8 или 16 - не понятно). При обработке токена работает каждый только один.
- Судя по Code Interpreter, система может переключаться между экспертами на лету (это уже моя теория)
- 32k версия - это fine-tune 8k
C тех пор оригинальный твит удалили (copyright infringement), но он успел разойтись по сети. Скрины в чатике
Ваш, @llm_under_hood 🤗
Словарик для разработки продуктов с LLM
В работе с клиентами у нас выработалась своя терминология. Она помогает точнее доносить идеи между командами и меньше путаться. Плюс код становится понятнее всем (спасибо Эрику Эвансу за Domain-Driven Design 🙏).
Привожу тут краткий словарик. Иллюстрация в комментах.
Контекст: Я работаю с продуктами, у которых под капотом не только LLM, но и большой набор данных. Еще не Big data, но в LLM на вход уже не влезает.
Поэтому в основе всегда лежат структурированные данные (structured data). Тут содержится вся информация, которую процесс с LLM должен учитывать при выполнении задачи. Например, это могут быть большие PDF, выгрузки из Confluence и истории переписок с клиентами.
Навыки (AI Skills) - это то, что делает конкретную работу. Обычно это цепочки GPT/LLM промптов, которые заточены на выполнение конкретных задач. Навыки достают релевантную информацию для выполнения задач выполнения. В отличие от агентов, навыки более специализированы, хорошо тестируются и легче отлаживаются.
(но ничто не мешает собрать дерево из специализированных навыков)
В теории, результаты работы системы с LLM под капотом могут быть достаточно хороши. Но это до выкатывания системы в продакшн в реальный мир к живым пользователям. Тут-то и начинают случаться нежданчики 🤣
Реальный мир - это то, что наглядно показывает различие между практикой и теорией.
В этот момент появляется обратная связь (feedback), которая поможет сделать продукт дальше. Собирайте все, начиная от лайков/дислайков, до сообщений с жалобами и метрик из бизнеса.
Feedback лучше полуавтоматически обрабатывать и интегрировать в structured data. Ваши разработчики получат новую информацию, которую позволит улучшить систему на следующей итерации разработки. Так система будет расти и развиваться.
Улучшаем, выкатываем и сообщаем пользователям про это.
Процесс можно повторять быстрыми итерациями (rapid iterations) до тех пор, пока реальное качество работы системы не достигнет желаемого уровня.
👋 А какие специфичные термины используете вы?
Ваш, @llm_under_hood 🤗
PS: Я не умею добавлять картинки в ТГ так, чтобы текст не сужало. Поэтому иллюстрация к посту - в комментах.
Embeddings и векторная БД ищут плохо? 🔍🥺
Если продукты с LLM под капотом выдают чушь на выходе, то это может быть вызвано мусором на входе. Чем больше нерелевантной информации мы подаем в контекст, тем хуже качество ответов. Или “фигня в контексте - галлюцинации на выходе” (подробнее).
Самый частый источник “фигни на входе” при работе с большими текстами - это нерелевантные индексы на базе embeddings.
Можно это самостоятельно продебажить, если взять запросов 10-20 от реальных пользователей или эксперта и прогнать систему поиска до момента получения документов. Потом просто смотрим глазами, сколько правильных документов было найдено, а сколько мусорных.
А еще лучше - сформировать тестовый dataset с запросами и списком фрагментов, которые система должна находить. И загнать все в тестовый скрипт, который прогоняется автоматически на каждое изменение. Ему достаточно выдавать accuracy (но еще лучше - confusion matrix).
Когда есть такой тестовый dataset, можно смело экспериментировать с разными вариантами поисковых индексов, начиная с CharacterTextSplitter и до графов знаний в LlamaIndex.
Ваша задача - подобрать такую комбинацию, которая увеличит accuracy до приемлемого уровня. Достаточно, чтобы выкатить все реальным пользователям.
А дальше - продолжаем собирать feedback (👍, 👎), интегрировать его в тестовый dataset и работать над повышением точности на всех данных. Большую часть этого можно делать в полуавтоматическом режиме.
Идея коллаборации!
Как насчет выбрать какой-то набор документов (открытые и доменно-специфичные, которые точно не попадают в обучение, для начала на English) и их совместно разметить вопросов на 20-40 (вопрос - релевантные части документов)?
И потом эту разметку использовать для тестирования разных архитектур структурирования данных. Можно еще сшить в один PDF файл и тестировать им разные online сервисы.
В идеале - это домен, в котором мы все немного разбираемся, чтобы можно было быстро оценивать на глаз качество ответов.
Что скажете?
Ваш, @llm_under_hood 🤗
AI & Startups - интересный канал, который ведет хороший человек Влад. Из его последних постов мне больше всего зашли:
- Code interpreter ChatGPT - ваш новый аналитик данных
- Скорость - главная метрика успеха стартапов в эпоху AI
- Как бизнесу внедрять LLM-ки
У Влада еще есть дружелюбный чатик LangChain developers chat 🤗 И там не только про LangChain.
Как определить, что проект использует LangChain? 😉
Он не может по статье про Bitcoin ответить на вопрос "How is the work by "R.C. Merkle" used in this paper?"