Учимся понимать мультиагентные LLM-системы
Главное правило при работе с LLM: воспринимать публично доступные LLMки как мозги, а не глаза и уши. LLM ничего не знает, просто генерирует что-то похожее на ответ. Поэтому нам, как разработчикам, нужно добавлять много валидаций на пути от пользовательского запроса до получения ответа от LLM. Придерживаемся простого правила: если человек бы смог накосячить, то LLM точно накосячит, так как никакого здравого смысла у LLM нету.
Общий процесс получения ответа от LLM следующий: indexing > retrieval > generation. Пользователь вбил промпт, он векторизировался, ушел в БД в поисках релевантных данных. Но как проверить факты? Для фактов мы используем внешние инструменты, а не LLM. LMM из коробки обычно плоха для точных фактов, LLM это не rule-engine. Поэтому, если мы серьезны в своих намерениях касательно LLM-продукта, то никогда не вызывайте LLM без валидации. А валидация преобразовывает наш LLM в полноценного агента.
Работа с промптом
Простой способ, как уменьшить вероятность некорректных ответов, это добиться от пользователя явного промпта. Самое первое для проверки это валидация пользовательского ввода. Мы должны точно знать, что запрос соответствует тем данным, что мы готовы предоставить. Другая стратегия это методы no-shot, single-shot, few-shot, и multi-shot: позволяют LLM понять, в каком формате вам нужен ответ. No-shot это метод, когда LLM сама решает, как решить поставленную задачу. Больше шотов — больше контекста для модели, что именно от неё ожидается.
Вы также можете внедрить примеры ответов в контекст, используя RAG. RAG позволяет получить доступ к up-to-date знаниям, и может уменьшить галлюцинации. Примеры ответов могут строиться на популярных промпт-техниках, вроде:
- Персона — «Представь, что ты финансовый аналитик…»
- Chain-of-thought — «Разбей задачу на подшаги…»
- Chain of density — «После подготовки финального ответа, пройдись по информации еще раз и убедись, что ничего важного не было упущено…»
- Tree of thoughts — «Дай мне несколько вариантов ответа, выбери лучший, повтори»
- Graph prompting — графы, как в ComfyUI
- Knowledge augmentation — «второй агент, оспорь ответ первого агента…»
- Всегда хорошая идея попросить LLM в явном виде составить план действий. Последовательный reasoning работает через zero-shot CoT.
В промптах, нужно быть кратким. Одна задача — один промпт. Если вы хотите получить оценку ситуации, то задайте вопрос LLM с вариантами оценки: positive, negative, или neutral. Начинайте с простых промптов и постепенно накидывайте контекст, это будет своего рода fine-tunings. Именно поэтому и нельзя смешивать контекст ТЗ для разработчиков и продуктоваой части, это должны быть разные хранилища. Так вы не запутаете LLM, какой контекст верный. Придерживаемся SDD-фреймворков: Superpower, GSD, grill-with-docs, OpenSpec.
А если пользователь перестарался и сделал огромный запрос? Выслал в наш небольшой агент весь output из консоли, чисто посмотреть, а что нейроночка на это скажет. Больше глаголов, лучше результат, так ведь все думают? Тогда запрос декомпозируется агентом в серию подзапросов, так мы найдем много чанков, которые отвечают на небольшие подзапросы. Это называется Demonstrate-search-predict (DSP). Сначала LLM сгенерирует общий ответ на главный вопрос, и далее множество вопросов сформируют вектор для лучшего retrieval. Вы можете найти детальное описание такого рода техник под названиями Query expansion, Query transformation, Step-back prompting, Query rewriting. Также помним, что множество шагов для извлечения, обработки, проверки данных это всегда больше ресурсов и больше времени на ответ. Что верный путь к плохим значениям метрики tail latency.
Чуть более техническим языком, дело не в количестве токенов, которые вы потратили за раз, а в размере контекста. Количество токенов не равно количеству слов. Токены включают знаки препинания, символы, цифры и другие элементы текста. Разные схемы токенизации варьируются в разных LLM. Но как общее правило, в большинстве случаев фраза «кот убежал» займет 2 токена. Отсюда следует ограничение контекста — для ChatGPT 3.5 контекстное окно объемом 4 096 токенов, что соответствует примерно пяти страницам текста. С выходом ChatGPT 4 контекстное окно было увеличено до 8 192 токенов (10 страниц), а также появилась версия ChatGPT 4-32k с контекстным окном объемом 32 768 токенов (40 страниц). Модель Gemini 1.5 же работает с контекстным окном объёмом 1 миллион токенов, или более 1 000 страниц. Можем ли мы взять старые модели и дать им огромный контекст? Нет, это верный путь к галлюцинациям. Я пытался.
И осторожно давайте пользователям взаимодействовать с параметром top-p, который управляет распределением вероятности, это сфокусированная рандоминазация. Обычно не рекомендуется корректировать top-p вместе с температурой. Помним, что top-p это терминология ChatGPT, другие модели могут называть это по другому. Температура выше = больше креатива от модели, но на самом деле это банальная меньшая степень предсказуемости следующего токена. Если мы попросили удалить файлы и поставили высокую креативность…. чтож, кто тут виноват?
Оркестрация агентов
Если у вас всего один агент (LLM + Harness), и он делает все задачи, то он быстро сломается. Это называется role-overload. Решение простое, как и при работе с живыми сотрудниками: делим ответственность. Один человек сможет в одиночку затащить весь проект, но не сможет это делать на потоке. Поэтому и существуют бизнесы и профессии, команда с ролями позволяет системно решать задачи. Как минимум, это позволит агентам работать после возникновения ошибок. Логика «если ошибся -> попробуй еще раз», скорее плохая практика (всё как и в менеджменте сотрудников). Мы получим вечный loop, агент будет по кругу собирать одну и ту же ошибку и потратит все деньги. Помним про лимиты.
Также, если вы просто вызываете напрямую LLM, то это не агент. Это просто интерфейсная обертка вокруг LLM. Агент работает в цикле, думает о лучшем действии/инструменте для решения задачи, использует эти инструменты, обновляет состояния. Одна из популярных структур такая: observe -> decide -> act -> update state — repeat или stop. Все эти шаги нужны в том числе и для дебага. State может быть как промпт от пользователя, так и результат работы инструментов, история неудач.
У агентов должны быть некие правила, например, здравый смысл (существует гравитация, значит, люди не могут летать), лингвистические знания (синтаксис языка), предметные знания (знает тему медицины). Знания условно «замораживаются» на этапе pre-training. Но здравый смысл может быть отдельным агентом.
Какие будут агенты, решаете лишь вы. Но есть сформированные best practice по индустриям. Стандартная «команда» будет состоять из reasoning (ресерч, планирование) > инструменты/интеграции (API) > память (помним все действия, планы, переписки) > и непосредственно агенты для работы (написать контент, отправить письмо, выполнить код). Например, вы делаете агентов для red teaming, точно нужен отдельный агент для отсечения запрещенный, опасных, или необратимых действий. Или же контролирующий агент курирует несколько локальных агентов управления. Его основная функция будет устранение конфликтов целей между локальными агентами управления путем корректировки их целей в соответствии с глобальными приоритетами. В общем, агент-начальник, кто держит курс на цель.
Monitor Agent отвечает за мониторинг интеграции внешних API в рабочей многоагентной системе. Команда обычно хочет, чтобы он выявлял признаки ухудшения качества API и координировал меры по устранению проблем. Это можно отслеживать в цифрах, например, частота превышения времени ожидания для каждого внешнего API во временных окнах. Как пример, при просмотре могло быть замечено, что агенты-исполнители часто ожидают решений от агентов-планировщиков. Значит, нужно оптимизировать очередь обмена данными и добавить backpressure routing. Или в крупной многоагентной системе, мониторинг показывает, что задержка end-to-end запросов резко возрастает при любом всплеске трафика, хотя средняя загрузка CPU в кластере остается ниже 50%. Тогда, уведомляем другого агента или человека.
Еще один пример из практики, когда в моей мульти-агентной системе агент мониторинга обнаружил, что внешний API планирования показывает задержку и периодические таймауты в определенные часы. Для стабилизации поведения, была сделана адаптивная отсрочка и динамическое снижение качества ответов, временно упрощая обработку запросов на планирование, когда задержка превышала заданные пороговые значения. И когда агент завершает работу с ошибкой, то я возвращал структурированные коды ошибок и машиночитаемые сведения о причине сбоя и нарушенных ограничениях.
Само собой, отдельный агент для работы с MCP. Если MCP имеет доступ к БД, то важно ограничивать запросы заранее определенным набором параметризованных операций со строгой проверкой входных данных. Каждый инструмент должен быть изолированным, и если они умеют только в чтение данных, то их можно запускать параллельно. Но если вызовы могут изменить изначальные данные, то их следует выполнять последовательно. Агентам опять же важно понимать, когда обращаться к внешним инструментам, а когда полагаться на встроенные знания.
В многоагентной производственной системе агент-координатор координирует вызовы нескольких инструментов MCP: прогнозирующего спрос, оценивающего производственные мощности и планирующего. Верная стратегия это использовать общую модель домена и сопоставляйте схемы входных и выходных данных каждого инструмента с этой моделью до и после каждого вызова инструмента
Описанное выше деление на агентов по ролям помогает в дебаге. Вы можете дебажить только между шагами/агентами, инструментами. Обязательно подумайте про tracers, чтобы знать, какое было состояние системы и в какой момент времени. Это не про логирование, а про ответы на вопросы, когда что-то пойдет не так. Инпуты, аутпуты, ошибки валидации, изменения состояния и финальные решения. Нам нужно уметь объяснить менеджменту, почему агент повел себя так или иначе в определенный момент времени. Добавление новых агентов должно происходить по Blue-Green деплойменту. А если агенты чему-то научились за свою работу с определенной когортой сотрудников, то этот новый навык должен быть передан в агентскую систему только после проверки в оффлайновом режиме.
Также, мы говорим про использование разных LLM на разных ролях. На примере DeepSeek — у них много моделей, таких как v3, v1, Janus Pro. DeepSeek хорош в обработке неструктурированных данных, может показать логическую цепочку рассуждений. Работает на Neural Network Layer. Принято использовать DeepSeek-V3 для генерации и рефакторинга кода, а DeepSeek-R1 для рассуждения и декомпозиции сложных задач, которая построена на трансформерах. Каждой LLMке своя роль, при выборе учитываем архитектуру модели: CNN, Transformer, RNN, смотрим на функцию потерь. Также, V3 годится для генерации возможных вариантов исправления багов, а R1 — для определения, какое из исправлений наилучшим образом устраняет первопричину. R1 умеет формировать условно правильные выводы на основе сложных датасетов. Модуль inference призван делать обоснованные выводы, что является одной из основных функций R1.
По удачным комбинациям, это GPT + Codex, Claude + Claude Code, Gemini + Antigravity (без Claude тут не справиться), DeepSeek + Kimi + GLM + OpenCode.
Для оркестрации агентов используется CrewAI, и его основная задача — сделать систему предсказуемой. CrewAI назначает агентам роль: маркетолог, разработчик, оператор тех поддержки, именно отсюда следует предсказуемость, как и меньшая гибкость. AutoGen же больше про коммуникацию LLM друг с другом, что дает высокую гибкость и более высокий шанс проблем. В AutoGen, обычно требуется очень активное участие человека на каждом из этапов работы агентов, когда задачки небольшие и итеративные. Тут же можно встроить и RLHF, когда человек помогает моделям выдавать результаты в соответствии с ожиданиям людей. Для этого нужна прямая обратная связь от человека. И AutoGen быть очень прожорлив на токены, может уйти в долгие и сложные диалоги. А если требуется сложная логика оркестрации, то лучше посмотреть в сторону LangGraph. LangGraph в плане токенов получше AutoGenа, особенно при хорошо сделанном Critic Agent. Более продвинутые и визуальные инструменты включают n8n. Можно обойтись попросту всех «LangChain-экосистемой»:
- LangServe: этот компонент позволяет превратить вашу систему в API
- LangChain: различные модули позволяют интегрировать большие языковые модели с дополнительным объёмом памяти, подсказками и другими инструментами
- LangSmith: этот компонент используется для анализа, мониторинга и оценки вашего приложения
И нет необходимости строить самописного монстра из тысячи компонентов. Вы можете использовать DeepSeek из GrokAPI, Cursor AI, Perplexity, а для создания ассистентов https://www.make.com/en . Можно обойтись и своими силами, создать ендпоинт бэкэнда для аутентификации через API DeepSeek, и пересылать в DeepSeek запросы пользователей после санитизации.
RAG
RAG это просто дополнительная информация для лучшего ответа, добавленная в существующую LLM. RAG изначально сделан для одной простой задачи: вытащить информацию и суммаризировать. Сложные вопросы требуют от модели еще и подумать, что уже за пределами стандартного RAG. Обычный RAG это «retrieve and read», а так называемый modular RAG больше про retrieve, read, и rewrite. В целом, есть два ключевых способа, как научить существующие LLM новым знаниям: fine-tuning и RAG.
Когда выбирать RAG, а когда fine-tuning:
- RAG хорош для прямого накачивания в LLM новых знаний, и это возможно динамически в реальном времени. Fine-tuning же статичен.
- RAG допускает работу небольшим семплом данных, а fine-tuning требует хороший, большой, правильный датасет. Тут важно подчеркнуть, что неструктурированные данные вроде статей, историй переписок, конспектов митов, отчетов — не друзья ни для RAG, ни для fine-tuning. Как и полу-структурированные данные в форматах JSON, XML, HTML, для работы с данными из файлов нужны отдельные пайплайны. А вот структурированные данные, такие как Excel, SQL databases, в определенных случаях даже PDF (на моем опыте, самый проблемный), GitHub респозиторий — самый желанный выбор. И разные модели лучше работают с разными типами данных. Так, Claude-3 предпочтет XML, Llama3 же выберет SYS и INST.
- С RAG легче отследить, что ответы пришли именно из нового слоя знаний. RAG хорош для поиска фактов. И как будто, RAG выигрывает… Но! Fine-tuning позволяет изменить поведение модели, стиль написания, добавлять новые навыки, уменьшать галлюцинирование, вместе с span extraction.
- Fine-tuning это смена весов модели, базируясь на добавленных данных. Fine-tuning похож на нашу долгосрочную память: если мы прослушали долгую лекцию в универе, то скорее всего вспомним общую суть лекции, но без деталей. Модель с Fine-tuning работает аналогично, она не очень хороша в деталях. Так что, fine-tuning лучше подходит для генерализации информации, в сравнении с RAG. Из инструментов, я могу рекомендовать Unsloth для fine-tuning. Вы можете изменить все веса модели с помощью full-model fine-tuning (FMFT) и лишь небольшую часть параметров parameter-efficient fine-tuning (PEFT).
Продолжая тему датасета, помним, что дедупликация данных — ещё один важный аспект при работе с LLM. Дубликаты данных негативно влияют на обучение LLM, а также приносят вред, если обнаруживаются в процессе генерации ответа. По мере увеличения объёма данных риск появления дубликатов растёт линейно. Существуют такие методы, как неточное сопоставление и дедупликация на основе хешей, которые можно использовать для устранения дубликатов. В целом, следует создать конвейер для контроля качества и управления данными в системе. Эти конвейеры должны включать правила и системы отслеживания, позволяющие выявлять проблемные данные и их происхождение.
Для более продвинутого RAG, нужно побольше метаданных для точного поиска. Метаданные должны лаконично содержать информацию, которая в противном случае была бы разбросана по всему документу. Один из вариантов решения это индекс по иерархии: для каждого уровня иерархии формируется краткое описание.
Для проверки нашего RAG можно использовать Self-RAG, который позволяет взглянуть на свой же ответ и оценить его. Self-RAG итеративно проверяет достоверность источников информации в готовом ответе. Либо техника Corrective RAG — используется для решения проблем с некорректным извлечением информации. Corrective RAG проверяет качество извлеченных данных перед генерацией ответа для пользователя. Система извлекает документ/информацию, анализирует и если результат неудовлтеоврительный, либо переписывает query, либо идет в поисковые системы. Очень популярный подход для ботов, которые должны выдавать точную информацию.
БД и чанки
Векторная база данных это специализированная база данных, предназначенная для хранения многомерных векторов. Таким образом, данная база данных оптимизирована для работы с неструктурированными и полуструктурированными данными, такими как векторы. Ее задача заключается в обеспечении эффективного хранения, индексирования и поиска. Выбор векторной базы данных также оказывает значительное влияние на производительность RAG. На сегодняшний день существуют десятки возможных вариантов векторных баз данных, поэтому выбор оптимального решения может оказаться сложной задачей. По умолчанию, наша векторная ДБ это chromaDB, но существуют и другие способы хранения данных, например RDBMS, NoSQL, NewSQL. Даже в PostgreSQL можно докинуть pgvector, так вы получите векторное хранилище. Векторное хранилище обычно состоит из трех сущностей: уровень индексации, уровень хранения и уровень обработки.
Почему векторные ДБ, а не привычные? Библиотеки, такие как FAISS (Facebook AI Similarity Search), не предназначены для операций создания, чтения, обновления и удаления (CRUD), поэтому они не являются хорошим выбором для динамических систем, в которых несколько пользователей получают доступ и выполняют операции. Напротив, если наша база данных неизменяема и мы предоставляем только доступ, FAISS может стать хорошим решением. Существуют базы данных SQL, которые поддерживают векторы (расширение классической базы данных). Эти базы данных позволяют эффективно индексировать связанные метаданные. Однако эти базы данных не масштабируемы и часто имеют ограничения по размеру вектора, а производительность ниже. Базы данных SQL — хороший выбор для внутренних проектов, которые должны быть подключены к существующим корпоративным базам данных (которые, вероятно, уже будут в формате SQL), но не являются хорошим выбором, когда важны масштабируемость и производительность.
Для выбора типа хранения данных, важно понять, какие вопросы потенциальные пользователи будут задавать системе с RAG. Например, если пользователь будет задавать вопросы, требующие от модели поиска нескольких фактов, лучше использовать стратегию с небольшими чанками, но содержащими прямой ответ. А если система будет носить более «рассуждающий» характер, то лучше использовать чанки с большим контекстом. Когда слишком много чанков, падает скорость и шансы найти нужный кусочек информации далеко не 100%.
Чанки можно сделать более семантически похожими. Скорее всего, чат-бот будет получать на вход вопросы, и значит на каждый чанк генерируются гипотетические вопросы, и эти вопросы представляют собой vectors (embedding). Embedding это просто кластеризация текста. Эмбеддинги нужны для выявления семантических связей и улучшения понимания данных. Скажем, у вас миллионы отзывов на продукт, и вы хотите найти все схожие отзывы. Или рекомендательные системы в соответствии с семантической связью между лайками/дизлайками пользователя. Embedding может использоваться не только для текста, но и для видео, фото. Embeddings позволяют преобразовать человеческие слова в векторы, которые могут анализироваться AI-системами. Семантическое сходство поймет, что два равных предложения на самом деле имеют единое значение.
Нужен семантический поиск. В семантике, благодаря учету смысла и контекста данных, поиск и рекомендации становятся более релевантными. В семантическом поиске чем ближе расстояние, тем больше схожесть, работает евклидово пространство. Другой алгоритм это Dot product, который скорее про схожесть векторов, чем про расстояние. И множество других вариантов, например Lin similarity, Jaccard similarity, Hamming distance, Manhattan distance. И поверх используются техники, вроде Hypothetical Document Embeddings (HyDE) — на пользовательский запрос сначала генерирует гипотетический ответ, похожий по семантике на изначальный вопрос от человека. И по этому ответу ищутся соответстующие чанки. Вообще, модели embedding models плохо справляются с ответами на темы, с которыми плохо знакомы. Поэтому гипотетический ответ больше про паттерн ответа, чем про верность.
Для вычисления степени сходства между двумя векторами вложения очень часто применяется косинусная схожесть, которая измеряется косинусом угла между двумя векторами и широко используется для расчета их схожести. Косинусное сходство используется для анализа взаимосвязей между предложениями в векторах вложений путем измерения углового расстояния между векторами. Для векторизации есть много библиотечек, популярные Word2Vec, Sentence2Vec, and Doc2Vec. Вектора могут насчитывать тысячи измерений. Более глубокие измерения могут отразить более детальную семантическую информацию.
Отличаться будет, разве что Keyword-based search, где поиск происходит по ключевым словам. Эффективен, когда запрос про конкретное название: термин, имя компании. Популярная модель для такого поиска BM25, в противовес векторному поиску. BM25 позволяет найти документы с определенным термином. BM25 это пример рассеянных векторов, как и TF-IDF. В BM25 мы получаем строку типа scorehybrid=1−0.43∙scoresparse+0.32∙scoredense. На человеческом языке: есть каталог товаров на миллионы позиций, и пользователь ищет что-то вроде «Samsung Note», «Средняя ценовая категория: смартфон для мамы с хорошей камерой» или «восстановленный Xiaomi дешевле $300». В чистом виде BM25 с таким не справится: как и векторный поиск. Объединяем — и будет достойный результат.
Оценка качества
Самые базовые метрики валидации результата LLM это precision и recall. Точность (precision) — доля найденных документов, которые являются релевантными, а полнота (recall) — доля релевантных документов, которые были успешно найдены. Эти метрики дают понять, насколько часто правильный документ был высоко ранждирован и извлечен. Также, полезно взглянуть на Ranked List Quality как список, какие документы были в топе.
Хорошо бы иметь под рукой ground-truth data. Это идеальный ответ, который бы мы ожидали от RAG, и он же является бенчмарком качества LLM. А вот как создать ground-truth data — это вопрос. Самое простое это нанять эксперта, кто напишет эталонные ответы. Как пример, для чата поддержки, экспертами будут выступать сотрудники, чья задача сформировать ответы в формате To resolve [issue], you can try [solution]. Такого рода ответы могут оцениваться по метрикам Faithfulness — поддержан ли ответ документами, и Groundedness — насколько ответ соответствует запросу и данным, на которых был построен ответ. Другие метрики для сравнения сгенерированного ответа и эталонного, это Ragas как метрика для оценки RAG. Есть и BLEU, ROUGE, и оценка экспертом.
Другой тест это «Иголка в стоге сена» (needle in a haystack). Сам по себе он базовый, но в полной мере себя показывает, когда нужно найти множество иголок, и с этим справляются далеко не все модели.
Для оценки самой LLM, ключевые метрики это accuraсy — насколько много успешных предсказаний, или качество ответов и рассуждений. Как пример, в фильтрации спама, чем меньше вредоносных почтовых отправлений просочилось через LLM’ку, тем она лучше. И вторая метрика latency, т.е. скорость, как время до первого токена, или время до последнего токена.
Inference и скорость
В цикле жизни модели, сначала идет тренировка/обучение как процесс, когда модель обучается с нуля. Не было LLM > появилась LLM. Тренировка модели занимает от часов до недель и даже месяцев. Этап тренировки, это когда модель обучается, а inference это модель предсказывает, то есть, генерирует ответ. Inference это предсказание следующего токена, или попросту генерирует вам ответ на запрос в реальном времени. Ваша моделька обучилась, и теперь крутится на каком-нибудь NVIDIA A100, H100, или иных кластерах GPU. При inference, скорее всего вы ограничены доступной памятью, энергией, временем, и при всех этих ограничениях, Inference все равно должен работать эффективно для конечного пользователя.
У моделей в интернете (SaaS) веса фиксированны. Это большие модели с миллиардами параметров (GPT-4, Llama-70b), которые крутятся в облаках и для работы требуют 40GB GPU. Модели настолько большие, потому что они очень «глубокие», т.е. у них много уровней. Значит ли это, что чем больше модель, тем она лучше? Нет. Современные модели не могут масштабироваться бесконечно, в определенный момент увеличение кол-ва параметров не дает никакого прироста производительности, а то и вредит.
Большие модели весьма неповоротливые и медленные. Пользователям не нужна хорошая модель, им нужна быстрая. Для прода, обычно заложена задержка 200мс максимум (p99). 7B модель будет работать медленно, условно на 1 токен уйдет 3 секунды. 70B модель потребует 280GB GPU. Чтобы такие большие модели имели ценность на массовом рынке, требуется провести Inference optimization для ускорения работы. Первый метод называется квантование. Сразу скажу, что небрежно примененное квантование сильно сказывается на точности модели и ведет к галлюцинациям. Нужно добавлять RTN (round-to-nearest). Но при этом, квантование это самый быстрый метод уменьшения размера модели, что хорошо для быстрого выхода в прод. Квантование уменьшает структуру модели, что может привести к необходимости повторной тренировки.
Для улучшения качества квантования, одна из популярных техник это AWQ, использует маленький дата-сет для управляемого процесса квантования. Слой за слоем, результат работы оптимизированной и не оптимизированной версии приближаются к эталону. Некоторые веса более значимы и именно их мы стараемся не трогать. GPTQ квантование уменьшает ошибку при калибровке весов. Если у вас совсем слабое железо. то ваш путь это GPTQ. Метод GPTQ осуществляет послойную коррекцию ошибок второго порядка с использованием калибровочных данных, получая 4-битные веса LLM с минимальной потерей по перплексивности даже при масштабах от 7 млрд до 70 млрд.
AWQ использует иной подход: он выявляет небольшую долю значимых весов, квантование которых доминирует в погрешности, и масштабирует их для защиты точности, в то время как остальные веса подвергаются агрессивному квантованию. Оба метода поддерживаются в трансформерах, autoawq и auto-gptq, а также интегрированы с vLLM и TensorRT-LLM. AWQ работает быстрее и дает хороший баланс, GPTQ просто уменьшает ошибки квантования и более математически точный, и при экстремальном сжатии, показывает более высокую точность.
Еще один метод это destillation, который попросту обучает новую, уменьшенную модель, и требует много ресурсов.
Масштабирование
А что делает некоторые продукты на базе LLM лучше других? Множество интересных инженерных решений под капотом. Если агент помнит, о чем с ним говорили год назад, то пользователю будет проще вернуться в продукт. Память агента (window buffer memory) хранит лишь недавние сообщения, быстро читается и быстро стирается. Postgres memory — долгосрочная память, хранится даже после окончания сессии. Motorhead memory — централизированне хранилище для памяти, один общий уровень, что позволяет множеству агентов иметь доступ к единой памяти. Если говорить про память одного агента, то внимание модели полагается на две сущности: K-вектора и V-вектора. Каждый токен хранится в KV-кеше. Вот висит ваш древний чатик с первого запуска ChatGPT, и вы решили его поднять. Так вот, весь контекст разговора живет в KV-кеше. Всё это дело кушает очень много памяти, и каждому запросу требуется своё KV-кеширование, поэтому кеш надо иногда чистить. А если у вас 1000 пользователей, то вас ждет линейный рост (хорошо) и переполнение памяти (плохо). После переполнения памяти, система перестает работать. Так, для одного пользователя KV-кеш ок, на миллионы пользователей вам не хватит никакой GPU памяти.
Решение это специальные LLM-сервера с оптимизацией на многопользовательские сценарии и эффективным использованием памяти, один из которых vLLM. На винде вам его не запустить, но с WSL 2 — получится. Более взрослый и упорядоченный уровень это NVIDIA Triton Inference Server, который является inference-сервером для корпораций. Поддерживает несколько бекендов (TensorRT, ONNX Runtime, PyTorch, TensorFlow, Python, vLLM) через единый API. Inference сервер не просто пересылает запрос от пользователя к LLM, а добавляет оптимизаций. Предположим, у нас 100 пользователей, они отправили запрос в одно и тоже время. Их запросы группируются в batch, что уменьшает кол-во запусков GPU. Далее batch отправляются ждать своей очередь в планировщик. И переиспользование KV-кеша на схожие запросы. Не забываем всегда подключать Prometheus для мониторинга.
Я бы советовал проектировать агентов на ONNX. Так у вас будет один файл для всех моделей, который содержит информацию об архитектуре модели, и снижает зависимость от фреймворка, позволяя таскать модель между разными окружениями.
А для локального запуска модели вам нужна Llama.cpp, это C++ реализация для запуска LLM на CPU, просто находите GGUF-файл модели на Hugging Face, выбираете метод квантования и закидываете в Llama.cpp. Помним, что accuracy в лабораторных условиях это круто, но если кушает слишком много памяти и работает долго, то мало кому это нужно. Вот вы взяли модель после fine-tuning, и хотите использовать ее в llama.cpp на локальном CPU, тогда ваш путь это 4-bit GGUF. А если аналогичную модель на серверный GPU vLLM, то INT4 (AWQ/GPTQ). Модели поменьше могут крутиться даже на телефоне без доступа в Интернет. Или даже на IoT-устройстве, где очень мало памяти и тока. Для телефона, ваш пусть лежит к TensorFlow Lite, ONNX, Core ML.