Первые шаги при реализации умного поиска (AI Search) по документам компании.

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

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

(см другие вариации этого кейса)

1. Identify scope and get statistics

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

2. Get data

Потом я выгрузил релевантную часть документации в файловую систему. В сумме ~8GB и 45344 документов. Причем выгружал я сам скрейпингом, предварительно согласовав с IT. Так оказалось проще и быстрее всего. Enterprise 🤣

Все документы сжаты в gzip и хранятся в content-addressable storage (CAS), ради дедупликации и простоты работы (выглядит, как содержимое .git/objects в ваших проектах). Там дикая смесь файлов, начиная от XLSX c PDF до MSG и PUB.

3. Basic data extraction

На следующем шаге мы прогоняем все документы через unstructured и сохраняем полученные фрагменты текста обратно в CAS. Потом эти фрагменты мы загрузим в БД с полнотекстовым поиском.

В ней будет две таблицы, первая - список всех документов и их иерархия, вторая - все фрагменты для каждого документа (общим счетом 6690323 штук). На вторую таблицу включаем full-text search.

Базу данных раздует при этом до 15GB. Скриншот с примером поиска в ручном режиме - в комментариях.

4. Knowledge map

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

В него мы положим всю ту информацию, которую собрали на первом шаге. Например: “Информация по срокам поставки лежит в папке X, бери файлы не старше 2х недель” или “Про внутрикорпоративные соревнования смотри в папке Y, бери файлы не старше года. Если ищут определенный отдел - выбирай по заголовкам внутри файла в двухбуквенном формате” итп

5. Edge cases + GUI

На четвертов шаге прописываем вариант поиска для “не знаем, как искать” и приделываем GUI для демонстрации возможностей клиенту. В подобных кейсах я люблю использовать BulmaCSS для красоты и HTMX для динамичности c минимумом усилий. Спихиваем написание GUI на ChatGPT.

6. Gather feedback

Много ли можно сделать с подобным поиском? На самом деле он уже будет работать лучше существующего текстового поиска, т.к. GPT будет сильно сокращать список документов в выборке по эвристикам из knowledge map.

Но качество в этой итерации и не имеет значения. Главное показать клиенту как можно быстро и, главное, прозрачно улучшить качество поиска. Во время демки мы поковыряем вместе Knowledge Map и попробуем вместе “научить” систему находить новые типы документов.

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

Ваш, @llm_under_hood 🤗

Update: продолжение про агентов написано тут.

Новый инструмент для дообучения LLM от авторов PyTorch - TorchTune 🚀

Разнообразных моделей сейчас становится все больше. А Sam Altman и вовсе обещает нам скачки в возможностях LLM и персонализацию (Youtube: Which Companies Will Be Steamrolled by OpenAI?)

Авторы PyTorch не отстают от трендов. Они хотят сделать простую и доступную библиотеку для дообучения и запуска своих моделей. Это пока альфа версия, но смотреть уже можно сейчас.

Announcement | Github | Tutorials

TorchTune сделана на базе PyTorch и из коробки поддерживает LLama2 7B/13B, Mistral 7B и Gemma 2B. 70B и MoE на очереди.

Авторы постарались сделать один раз и нормально реализацию таких вещей, как:

- интеграцию с Hugging Face
- логгирование и метрики для отслеживания процесса обучения
- квантизация
- оценки полученных моделей на популярных бенчмарках
- запуск моделей локально
- совместимость чекпоинтов обучения c популярными методами запуска моделей

При реализации всего этого, они пытались оптимизировать потребление памяти так, чтобы большая часть скриптов и рецептов влезала в GPU с 24GB VRAM.

С PyTorch у ребят получилось очень хорошо. Посмотрим, что будет с TorchTune.

Ваш, @llm_under_hood 🤗

Вебинар “Проектируем и внедряем AI-ассистенты с LLM под капотом”: 25 апреля в 11:00 GMT+3 (московское время)

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

В следующий четверг я проведу четвертый поток вебинара про проектирование AI-ассистентов.

Я расскажу о принципах построения и внедрения адаптируемых AI-ассистентов на примере небольшого end-to-end кейса. Мы поговорим о том, как проектировать подобные системы, собирать для них данные, контролировать качество, выстраивать работу с пользователями.

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

Вы сможете принести свои кейсы для обсуждения и задать вопросы.

Содержание вебинара то же, что и для предыдущих трех потоков. Отличаются только кейсы, которые приносят участники. Про Knowledge Map как раз на этом вебинаре я и рассказываю.

Длительность - 2 часа. Язык - русский. Стоимость участия в вебинаре - 80 евро (нужна будет карточка для оплаты через Stripe, российские карты не сработают).

Как оплатить?
Понадобится карта, работающая за пределами России. Оплатить можно вот здесь.

Там же есть ответы на частые вопросы:
- Можно ли оплатить участие другого человека?
- Будет ли запись? Можно ли ее купить отдельно?
- Как принести свой кейс для разбора на вебинаре?

После оплаты вам придет email с деталями и персональной ссылкой в чат потока.

До встречи на следующей неделе!

Ваш, @llm_under_hood 🤗

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

Как выяснилось, спрос на информацию о создании систем на базе Knowledge Maps - несколько больше, чем ожидалось. Больше всего он интересует тех, кому важно строить AI ассистентов без галлюцинаций, с возможностью заглянуть под капот и улучшить качество.

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

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

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

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

Когда? Переработка материалов и запись займут какое-то время. Ориентировочно Май-Июнь. Напишу в канале.

Ваш, @llm_under_hood 🤗

LLM Бенчмарк Mistral 8x22 - заметный скачок качества 🎉 #bench

Mistral AI начали фиксить свою проблему с болтливостью второго поколения своих моделей!

Недавно вышедшая модель Mistral 8x22 есть в открытом доступе. Теперь она на наших продуктовых LLM бенчмарках работает лучше, чем закрытый Mistral Large.

Более того, она настолько хорошо стала следовать инструкциям, что побила рекорд ChatGPT-4 Turbo (v2024-04-09) в категории integrate. Стоит при этом раз в 10 меньше, чем Mistral Large.

Что за категория Integrate? Это работа с API-шками, таблицами, функциями и внешними системами. Детальнее описано в лабах.

Хочется надеяться, что этот скачок качества распространится на все модели этого нового поколения.

Ваш, @llm_under_hood 🤗

Бенчмарки Llama 3 на продуктовых задачах #bench

Начнем с хорошего. Llama 3 - 8B совершила гигантский скачок по сравнению с прошлой версией. Она обогнала Claude 3 Sonnet, Cohere Command R и даже Mistral 8x22B. Еще и разные языки неплохо понимает!

Тем обиднее плохие очки модели в категории Integrate, чисто из-за невнимательности. Так и хочется сказать модели "читай инструкции внимательно! Вон ChatGPT смог же больше 90 очков набрать!"

Кстати, если кто эту модель запускает локально, не забываем читать внимательно про их instruct format и eos_tokens - они поменялись с прошлой версии.

А вот Llama 3 - 70B ведет себя у меня отвратительно. Во-первых, в куче ответов почему-то начинает ответ с assistent\n\n. Но даже если закрыть глаза на это, качество ответов ниже плинтуса. Иногда модель попросту срывает в белиберду прямо в ответе.

Update: на HF из коробки косячные конфиги трансформеров, но это быстро пофиксится.

Дружно радуемся прогрессу Llama-3-8B! 🎉

Ваш, @llm_under_hood 🤗

State of the Art не обязательно означает качество

Чуть выше я писал про первые бенчмарки новых Llama 3 моделей на задачах из продуктов с LLM под капотом.

Llama 3 8B повела себя очень хорошо, а ее старшая 70B версия страшно глючила при запуске из HF Transformers по инструкции от Meta.

В ретроспективе можно было даже не искать ошибки в своем коде, а просто оценить число жалоб на промпт tokeniser в обсуждениях Llama-3 моделей на Hugging Face- 8B и 70B 🤣

В общем, пару деньков эти модели можно не трогать. Пусть эти ковбои из Meta перепроверят и дополируют свои конфиги.

Но 8B уже точно лучшая в своем классе, и это до всяких тюнов.

Ваш, @llm_under_hood 🤗

#вы_спросили про суммаризацию больших таблиц для LLM

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

Это классный вопрос мне задал AI/ML инженер Fortune 200 компании после вебинара.

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

В такой ситуации нам первым делом надо классифицировать входящие запросы по характеру необходимой для ответа информации, а потом - предобработать (суммаризовать) соответствующим образом входные данные. Это подход Knoweldge Mapping, вид сбоку.

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

А теперь напиши такой SQL/Pandas запрос, который выберет необходимую для ответа информацию из таблицы. Я прогоню его, а потом скормлю результат тебе же для интерпретации.

Но все эти оптимизации в итоге зависят от характера вопросов и доступных данных. Бывает даже так, что посмотрев на предметную область, получается подобрать такие Knowledge Maps, что можно быстро и точно ответить на ~80% входящих вопросов (в абсолютном соотношении)

Ваш, @llm_under_hood 🤗

В полку RWKV моделей прибыло - 🦅 EagleX v2.

Я про проект RWKV уже писал раньше. Ребята дерзают и хотят создать новую архитектуру LLMок, чтобы сгладить основные недостатки классических трансформеров (требовательность к железу и ограниченный контекст).

Они выпустили новую версию RWKV-v5 Eagle v2, которая обучена на 2.25T Tokens. Мультиязычная, работает примерно на уровне Mistral 7B v0.1 и Llama 2 7B. В области English Perplexity - даже лучше.

Эта модель - самая энергоэффективная среди 7B моделей. 5x эффективнее на 1k tokens и 100x эффективнее на 20k tokens. Подробнее написано тут.

Announcement | Hugging Face | Gradio demo | Recursal AI | Fine-tune

Понятно, что модели еще далеко до State of the Art, но скорость прогресса в RWKV меня очень радует. У recurrent LLM моделей теоретически неограниченный контекст на входе и выходе (и встроенная суммаризация).

Ваш, @llm_under_hood 🤗

PS: Кстати, в нашем чатике уже обсуждают обучение RWKV моделей с нуля.

LLM Benchmark Updates. #bench

Выкладку Llama 3 70B на Hugging Face пофиксили, теперь модель не спотыкается на формате. Про проблему писал раньше. Но качеству LLama 3 70B это не очень помогло. Модель пока на уровне Anthropic Claude v2 в продуктовых бенчмарках.

Хотя, если задуматься, год назад казалось немыслимым, чтобы в открытом доступе лежала LLM уровня Claude 2.

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

Это улучшило очки в Integrate у некоторых моделей, но на TOP-10 это никак не повлияло. Там модели и так слушаются хорошо.

Самые большие ожидания у меня к тюнам Meta Llama 3 8B Instruct. У модели очень хороший Reason, а уж instruction following можно всегда подтянуть.

Ваш, @llm_under_hood 🤗

Прогресс LLM-ок одной картинкой.

Ваш, @llm_under_hood 🤗

#вы_спросили Какие есть примеры Knowledge Maps?

Knowledge Map - это такая предобработка данных, которая упрощает работу c ними для LLM и делает прозрачным для людей.

Отличительные особенности:
- Эксперты могут проинспектировать качество предобработки и внести коррективы
- При галлюцинациях на выходе можно отладить процесс, найти причину ошибки и попытаться ее исправить
- Можно использовать методологию создания domain models из DDD

Технические реализации Knowledge Maps могут различаться от проекта к проекту. Даже в рамках одного проекта по мере его развития.

Примеры Knowledge Maps в проектах (для каждого кейса - краткая структура Knowledge Map в текущей версии)

Микро-ассистент, для ответа на вопросы про ликвидность на основе отчетов компаний (описание): табличка с тремя колонками - название компании, год, ликвидность.

Marketing Content Generator (кейс): дерево папок с файлами о компании, маркетинге, внутренних процессах и продуктах. Плюс процесс на 5-6 шагов (промптов), который описывает LLM, как со всем этим работать и проводить человека по нему.

Кейс с ChatGPT про 10.000 € в месяц (кейс): внутренний словарик специфичной терминологии, особенностей перевода и форматирования, по словарю на язык. Словарь подставляется в промпт в зависимости от нахождения слов в тексте

Умный поиск по документам в компании (кейс): в самом начале интерфейс для структурного FTS поиска по всем документам со шпаргалкой про особенности компании. Впоследствии развивается в классификатор запросов, который подгружает дополнительные подсказки, промпты и конкретные документы в зависимости от типа вопроса. Большая часть подсказок и индексов к этому моменту хранится в таблицах, которые отражают процессы в компании. Edge cases по-прежнему отрабатываются при помощи структурного FTS поиска с query expansion + feedback loop.

Нишевые B2B генераторы лидов (кейс): в исходниках все выкаченные документы про потенциальных клиентов (годовые отчеты, посты, новости, видео итп), формализованное описание каждого документа/компании с указаниями на источники, FTS интерфейс и пошаговое описание процесса поиска возможных лидов (Wizard). Процесс повторяет то, как работают с лидами эксперты. Ассистент проходит с пользователем по этим шагам, извлекая информацию и обрабатывая ее. Человек проверяет выводы, корректирует выкладки.

Платформа для автоматизации бизнес-процессов в компании (кейс). Тут Knowledge Map уже разрастается до описания процессов компании, описания интеграций с внутренними системами компаний, описание внутреннего DSL для доступа к LLM, а также библиотекой примеров. Каждый пример - это выполняемый скрипт, который какой-то сотрудник сделал для автоматизации внутреннего процесса и выкатил для использования. Эта библиотека используется при развитии DSL дальше (чтобы не сломать скрипты), а также в качестве входа для помощника по автоматизации. Это wizard, который на базе описания проблемы и похожих кейсов пытается сразу написать готовый скрипт для автоматизации.

Ваш, @llm_under_hood 🤗

LLM Бенчмарк Microsoft Phi 3 Mini 4K instruct 😣 #bench

В чатике несколько раз просили протестировать новую Microsoft Phi 3. К сожалению, результаты плохие (в моих продуктовых бенчмарках). Модель инструкций совсем не слушается. Подробнее можно прочитать, например, на HuggingFace discussion

Но, как это нынче модно с выкладкой моделей, Microsoft тоже накосячили с chat template.

Возможно проблемы из-за конфигов. Подожду пару деньков, пока не сделают нормальную выкладку.

Пока эту модельку пропускаем. И заодно ждем выкладки старших моделей этой линейки.

Но модель потенциально очень хороша для своего размера! 🚀 Главное только поправить ее ответы и instruction following.

Ваш, @llm_under_hood 🤗

Update: Microsoft подтвердили проблемы с этой моделью. Будут исправлять 🤝

LangChain - это достаточно сложная и вредная библиотека.

Thoughtworks, даром что медленные мамонты, наконец проснулись и обнаружили это.

В предыдущем выпуске Radar мы уже упоминали о некоторых из появившихся критических замечаний в адрес LangChain. С тех пор мы стали относиться к нему еще более настороженно. Хотя фреймворк предлагает мощный набор функций для создания приложений с большими языковыми моделями (LLM), мы обнаружили, что он сложен в использовании и чрезмерно усложнен. LangChain рано завоевал популярность и внимание в этом пространстве, что сделало его стандартным для многих разработчиков. Однако, поскольку LangChain пытается развиваться и идти в ногу с быстрым темпом изменений, разработчикам становится все труднее ориентироваться в этих изменениях концепций и паттернов. Мы также обнаружили, что дизайн API непоследователен и многословен. Поэтому он часто скрывает то, что на самом деле происходит под капотом, затрудняя разработчикам понимание и контроль того, как LLM и различные паттерны вокруг них на самом деле работают. Мы переводим LangChain в кольцо Hold, чтобы отразить это. Во многих случаях мы обнаружили, что достаточно реализации с минимальным использованием специализированных фреймворков. В зависимости от вашего случая использования, вы можете рассмотреть и другие фреймворки, такие как Semantic Kernel, Haystack или LiteLLM.

Они предлагают избегать LangChain и, если уж очень нужно использовать какой-то framework, обратить внимание на Semantic Kernel, Haystack or LiteLLM.

Но мы же помним, что они же и советовали смотреть на LangChain в прошлом? :)

Ваш, @llm_under_hood 🤗

PS: Спасибо Николаю за наводку в чате.

Реализация продвинутого поиска (AI Search) на документах компании

Помните я писал про первые шаги при реализации умного поиска по документам?

Мы начали со сбора документов и примерных вопросов, а закончили - сбором feedback о сделанном прототипе. А что там дальше?

А дальше там - агенты-специалисты. История развивается так.

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

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

Если ничего не понятно - смотрим на то, как оно работает на практике у клиента. Берем блокнотик, находим специалиста и задаем вопросы.

- А как мне планировать отпуск на лето?
Хм, я не знаю, сейчас спрошу у Нины. Сек

или

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

Вот оно! Один человек не знает все детали в компании, но знает тех, кто может про это знать. Мы можем взять эту концепцию людей, ролей и моделировать в виде данных и кода. Все, как завещал Эрик Эванс из DDD.

Вместо классификатора по категориям вопросов у нас будет оператор первой линии. Он берет входной запрос и смотрит на список доступных AI агентов. Каждый - представлен как на ярмарке вакансий. Один знает все про маркетинговые матриалы, другой - специалист по отпускам и отдыху. Еще есть последний, он просто умеет искать хорошо. И один - "секретный", про него - в конце.

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

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

Чем отличается такой подход cо “специалистом” от простого LLM pipeline из нескольких шагов? Технически - ничем. Но “pipeline” клиентам без IT-бэкграунда объяснить сложно - они не будут понимать, как их готовить и организовывать. А вот “виртуального специалиста” они поймут хорошо - так выстроена работа в любой организации. И сразу представят, как это можно развить и применить.

Особенно, если им показать "секретного" специалиста, который на основе инструкции (и примеров всех существующих агентов) может набросать и задеплоить нового агента. Или подправить существующего.

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

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

(терминальный отладочный экран подобной сессии - в комментах)

Ну а то, что все это очень похоже на ChatGPTs, но только работает со своими документами и почти полностью локально - это только комплимент в стороную OpenAI.

Ваш, @llm_under_hood 🤗

PS: Субъективно, ChatGPT работает лучше с ролями специалистов, чем с абстрактными категориями вопросов.

Microsoft Phi-3 Mini Instruct действительно недокрутили

В бенчмарке этой модели я писал:

модель потенциально очень хороша для своего размера! 🚀 Главное только поправить ее ответы и instruction following.

Это и подтвердили авторы (см скриншот с HF). Отзывчивость у них хорошая, поэтому теперь будем ждать новые версии.

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

Ваш, @llm_under_hood 🤗

А когда в RAG-ах применимы GraphDB?

Я не один раз говорил, что графовые базы данных работают плохо в RAG-aх. Просто потому, что не видел случаев, когда они работают хорошо 🤪

Мне сейчас рассказали кейс, где они могут встать идеально. А если есть один кейс, то может быть и еще куча.

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

Сейчас туда очень активно начинают привинчивать AI.

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

Плюс туда можно докидывать зависимости вроде версий кода, деплойментов и сервисов.

И если дать LLM-ке вопрос вроде "Слушай, а какие системы могут поломаться, если я в этом коде выкину вот этот класс?", то ей будет сильно проще написать Cypher query, чем многоходовую рекурсивную портянку для SQL.

Ваш, @llm_under_hood 🤗

Все думают, что OpenAI выкатит свой поиск на домене search.openai.com

Они зарегистрировали домен с сертификатом, возможно там выставят наружу сервис аналогичный Perplexity.

А между тем, на домене https://search.chatgpt.com уже не только подключен сертификат, но и стоит CloudFlare ;)

Ваш, @llm_under_hood 🤗

PS: Про поиск хорошо расписано у Игоря в Сиолошной

Список R&D проектов с LLM под капотом

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

1. Сравнение архитектур RAG систем на business задачах.

Как? В рамках Enterprise RAG Challenge, где мы будем по-дружески меряться силой своих RAG-ов. Заявок на участие уже больше 20. Среди них - как начинающие команды, так и довольно крупные. Одна из них недавно запилила AI ассистента по данным на половину петабайта без галлюцинаций. Причем это веселье работает под ISO 27001, внутри периметра безопасности в каком-то горном data-center. Надеюсь, не Скайнет.

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

2. Сравнение эффективности GraphDB, SQL DB и NoSQL в решениях на базе Knowledge Map.

Как? Внутреннее исследование на базе партнерства между несколькими компаниями. Результаты будут публиковаться тут и в блогах TimeToAct (former Trustbit).

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

Если кому хочется поучаствовать - пишите в личку. Я пришлю модель данных и список вопросов. Можно ее загрузить в свою любимую систему. Задача - посмотреть, насколько хорошо LLM (GPT-4 и прочие) справляются с написанием правильных queries для ответов на эти вопросы. Данные потом собираем в кучку, а выводы - публикуем.

3. Подходы к генерации синтетических данных при обучении специализированных LLMок на бизнес-задачах.

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

Хочется иметь маленькие, быстрые и энергоэффективные модели, которые хорошо заточены под работу в локальном каскаде LLMok на бизнес-задачах (Knowledge-mapping архитектуры). А самое главное - с кристально чистой родословной, без утечек данных за периметр безопасности.

Общие выводы и выкладки будут публиковаться в канале и статьях.

Ваш, @llm_under_hood 🤗

Дайджест с цифрами про SEQUOIA, GPU Deploy и количество GPU у OpenAI 🤯

Что есть у популярных и относительно небольших LLM моделей, но чего нет у гигантских “леворезьбовых" моделей вроде Grok или Snowflake Arctic? Правильно, сообщество исследователей и энтузиастов, которым хочется запускать их на слабом железе.

Появился новый способ запускать Llama2-70B на GPU RTX 4090 со средней скоростью в пол-секунды на токен без квантизации (16bit). Он называется SEQUOIA. Ребята используют speculative decoding (когда маленькая моделька предсказывает варианты, а большая модель большими пачками проверяет их) и выгрузку части вычислений на CPU. Под капотом - планировщик дерева предсказаний, который оптимизирует их под возможности железа в наличии. Подход работает и для других комбинаций железа.

Прочитать можно на сайте проекта.

На рынке аренды GPU появился еще один стартап GPU Deploy. Первоначально это была компания доставки при помощи дронов, но что-то у них не взлетело, а GPU остались. Вот они и решили сделать AirB&B для GPU. Похоже на vast.ai, но с бОльшей придирчивостью к железу в наличии.

Заявленные цены - < $0.49 / hr за RTX 4090 (на котором можно запускать Llama 70B) до < $26.55 / hr за восемь Nvidia H100 SXM.


Правда, если посмотреть на картину по рынку в целом - это все капля в море. Скажем, по состоянию на Март 2024, у OpenAI есть 720000 H100 только на модель SORA. А в целом они планируют использовать 10 миллионов GPU для новейших AI моделей. Это можно, если сам Дженсен (директор NVidia) доставляет вам лично новейшую DGX H200. Чего только не сделаешь для любимого клиента?

Про это можно почитать в статье AIM тут.

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

Ваш, @llm_under_hood 🤗

#aicase - свой ChatGPT для муниципалитетов

Давно не было разборов проектов с LLM под капотом, поэтому вот вам еще одна история.

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

Что и было сделано. Реализация - это свой интерфейс к популярным моделям, со своей обвязкой в виде Full-text-search RAG-ов, поиска в интернете и генерации картинок. Тут используется смесь OpenAI моделей по API (в рамках своего региона Microsoft Azure) и локальных моделей для особенно чувствительных задач.

Истории чатов и данные хранятся в зашифрованном виде (encryption-at-rest). Естественно, что при обращении к OpenAI в Azure Microsoft используется opt-out из их 30-day data retention.

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

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

В принципе, под капотом нет ничего сверхъестественного с точки зрения технологий: поиск данных и вызовы моделей. Очень много сил вложено было как раз в продуктовую составляющую - работа с формами, аудит и права, функции, картинки и базы знаний. И это описывает подавляющую часть LLM-driven продуктов, которые я вижу на практике: ~5% работы делается в области AI/LLM, а все остальное - обычная продуктовая разработка.

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

Ваш, @llm_under_hood 🤗