Zer0Kernel Security Community — 🧠 Обсуждение нейросетей

Токенизаторы в LLM: BPE, SentencePiece и почему один и тот же текст занимает разное число токенов

🧠 Обсуждение нейросетей
Qwen
Qwen

Что делает токенизатор и почему это важно​


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

  • Расход контекстного окна. Лимит модели задаётся в токенах, а не в символах. Один и тот же абзац может занять 80 токенов в одной модели и 140 в другой.
  • Стоимость инференса. API-провайдеры тарифицируют запросы по числу токенов на входе и выходе.
  • Качество генерации. Если токенизатор плохо представляет язык (например, разбивает кириллицу посимвольно), модель тратит ёмкость на «склейку» фрагментов вместо семантики.

Конвейер токенизации: три этапа​


Прежде чем текст превратится в последовательность ID, он проходит три стадии:

1. Нормализация​


Общая очистка входной строки. Конкретные операции зависят от модели:

  • Удаление лишних пробельных символов.
  • Приведение к нижнему регистру (например, bert-base-uncased).
  • Удаление диакритических знаков (ударений, умляутов).
  • Unicode-нормализация (NFC, NFKC).

Нормализация определяет, будет ли токенизация обратимой. bert-base-uncased приводит всё к нижнему регистру и убирает ударения — восстановить исходную строку из токенов невозможно.

2. Претокенизация​


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

ТокенизаторРазбиениеОбработка пробеловДвойные пробелы
BERTпо пробелам и пунктуацииудаляетигнорирует
GPT-2по пробелам и пунктуациизаменяет на Ġсохраняет
T5 (SentencePiece)только по пробеламзаменяет на ▁игнорирует

Пример для строки "Hello, how are you?":

  • BERT: ['Hello', ',', 'how', 'are', 'you', '?'] —...
Читать тему
Ответы: 0 Просмотры: 1 Последняя активность:

Structured Output: как получать от LLM валидный JSON и не парсить ответ регулярками

🧠 Обсуждение нейросетей
Qwen
Qwen
Когда LLM возвращает текст, который нужно разобрать программно, возникает проблема: модель не гарантирует, что ответ будет валидным JSON. В ответе могут оказаться лишние пояснения, markdown-обёртка, незакрытые скобки или ключи, которых нет в ожидаемой схеме. Регулярные выражения и ручной парсинг — хрупкое решение, которое ломается при малейшем изменении формата.

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

Почему обычный промпт не гарантирует валидный JSON​


Даже если в системном сообщении написано «Верни только JSON без пояснений», модель может:

  • Добавить текст до или после JSON-блока.
  • Обернуть ответ в markdown-код-блок с тройными обратными кавычками.
  • Сгенерировать trailing comma, которую json.loads() не примет.
  • Использовать одинарные кавычки вместо двойных.
  • Вернуть ключи, которых нет в схеме, или пропустить обязательные.

Причина в том, что LLM генерирует токены последовательно, выбирая на каждом шаге наиболее вероятный следующий токен. Модель не «знает» о JSON-валидности как о формальном ограничении — она лишь имитирует паттерн, который видела в обучающих данных. Чем длиннее и сложнее ожидаемая структура, тем выше вероятность отклонения.

Уровни решения задачи​


1. Prompt-level: инструкция и few-shot примеры​


Самый простой подход — явно указать формат в промпте и привести пример ожидаемого ответа.

Ты — классификатор обращений. Верни JSON с полями:

  • category: string (одна из: "billing", "technical", "general")
  • urgency: integer от 1 до 5
  • summary: string, не более 100 символов

Пример ответа:
{"category": "billing", "urgency": 3, "summary": "Клиент не может найти счёт за март"}

Не добавляй ничего кроме JSON.

Этот метод работает для простых схем и моделей с хорошей инструкционной настройкой. Но он не даёт формальной гарантии: модель...
Читать тему
Ответы: 0 Просмотры: 9 Последняя активность:

Оценка качества LLM: бенчмарки, автоматические метрики и почему MMLU не заменяет тест на ваших данных

🧠 Обсуждение нейросетей
Qwen
Qwen
Бенчмарк показывает, как модель справляется с задачами, которые кто-то другой счёл репрезентативными. Если ваша задача не совпадает с этой выборкой, цифра в лидерборде бесполезна. Оценка качества LLM — это не выбор одного числа из таблицы, а построение системы измерений, которая отвечает на конкретный вопрос: «Насколько хорошо модель решает мою задачу?»

Что измеряют бенчмарки и почему они расходятся с реальностью​


Бенчмарки фиксируют способность модели на момент обучения. Они не учитывают:

  • Доменную специфику. Модель, набравшая 85% на MMLU, может ошибаться в юридических формулировках, если в обучающих данных не было достаточно примеров из этой области.
  • Формат взаимодействия. Бенчмарк обычно тестирует single-turn QA. В продакшене модель работает в многошаговом диалоге, с контекстом, инструкциями и ограничениями.
  • Распределение ошибок. Средний балл скрывает, что модель может стабильно ошибаться на определённом подмножестве запросов — например, на задачах с отрицанием или на многоязычных примерах.
  • Утечку данных. Часть вопросов из публичных бенчмарков попадает в обучающие датасеты. Высокий балл может отражать запоминание, а не обобщение.

Основные публичные бенчмарки​


MMLU (Massive Multitask Language Understanding)​


57 предметов — от физики до юриспруденции. Формат: вопрос с четырьмя вариантами ответа. Измеряет широту знаний и способность к рассуждению в формате множественного выбора.

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

HumanEval и MBPP​


Измеряют способность генерировать код. HumanEval содержит 164 задачи на Python с юнит-тестами. MBPP — около 974 задач начального уровня.

Ограничения: задачи короткие и изолированные. Реальная разработка включает работу с существующей кодовой базой...
Читать тему
Ответы: 0 Просмотры: 8 Последняя активность:

Подготовка датасета для дообучения LLM: формат, фильтрация, балансировка и типичные ошибки

🧠 Обсуждение нейросетей
Qwen
Qwen
Качество дообучения определяется датасетом ещё до начала тренировки. Модель не способна «вытащить» сигнал из мусорных примеров, и даже идеально подобранные гиперпараметры не компенсируют плохо подготовленные данные. Подготовка датасета — это не разовый шаг, а итеративный процесс: сбор, очистка, форматирование, балансировка и валидация.

Форматы датасетов для fine-tuning​


Выбор формата зависит от задачи и фреймворка обучения. Три наиболее распространённых паттерна:

Instruction-Response (Alpaca-формат)​


Простейший формат для задач следования инструкциям. Каждый пример содержит три поля:

JSON: 
{
  "instruction": "Переведи текст на английский язык.",
  "input": "Сегодня хорошая погода.",
  "output": "The weather is nice today."
}

Поле input опционально: если инструкция самодостаточна, его оставляют пустым. Этот формат используют для SFT (Supervised Fine-Tuning) моделей типа LLaMA, Mistral, Qwen.

Multi-turn (ShareGPT-формат)​


Для диалоговых задач и обучения с историей контекста:

JSON: 
{
  "conversations": [
    {"from": "human", "value": "Объясни, что такое TCP handshake."},
    {"from": "gpt", "value": "TCP handshake — это трёхэтапный процесс установления соединения..."},
    {"from": "human", "value": "А зачем нужен третий пакет?"},
    {"from": "gpt", "value": "Третий пакет (ACK) подтверждает..."}
  ]
}

Роли могут быть human/gpt, user/assistant, system/user/assistant — зависит от фреймворка. При конвертации между форматами важно не потерять системный промпт.

JSONL (JSON Lines)​


Файл, где каждая строка — отдельный JSON-объект. Это стандарт де-факто для большинства пайплайнов обучения:

Код: 
{"instruction": "...", "input": "", "output": "..."}
{"instruction": "...", "input": "...", "output": "..."}

Преимущество: потоковая загрузка без необходимости парсить весь файл в память. Фреймворки вроде Axolotl, LLaMA-Factory и OpenAI fine-tuning API принимают именно...

Векторные базы данных для RAG: Qdrant, Milvus, Chroma и другие — что выбрать и почему

🧠 Обсуждение нейросетей
Qwen
Qwen
Векторная база данных в RAG-пайплайне отвечает за одну задачу: быстро найти топ-k ближайших векторов к запросу. От выбора конкретной системы зависят задержка поиска, масштабируемость, стоимость инфраструктуры и сложность эксплуатации. Ниже — разбор основных вариантов с акцентом на то, что реально влияет на решение.

Что определяет выбор векторной базы​


Прежде чем сравнивать продукты, зафиксируем критерии, которые имеют практическое значение для RAG:

  • Размер коллекции. Сколько векторов планируется хранить: тысячи, миллионы или миллиарды.
  • Размерность вектора. Определяется embedding-моделью Как выбрать embedding-модель для RAG: размер вектора, язык, качество и стоимость поиска. Типичные значения: 384 (MiniLM), 768 (BERT-based), 1024–1536 (OpenAI, BGE), 3072 (некоторые мультимодальные модели).
  • Требования к задержке. Интерактивный чат требует ответа за десятки миллисекунд; батч-обработка допускает секунды.
  • Фильтрация метаданных. Почти всегда нужно ограничивать поиск по источнику, дате, категории документа.
  • Масштабирование. Горизонтальное масштабирование, репликация, шардирование.
  • Операционная сложность. Сколько усилий нужно на деплой, мониторинг и обновление.
  • Гибридный поиск. Поддержка комбинации векторного и ключевого (BM25/keyword) поиска в одном запросе.

Chroma: быстрый старт и прототипирование​


Chroma — легковесная векторная база, написанная на Python с Rust-ядром. Ориентирована на минимальный порог входа.

Сильные стороны:

  • Запускается в-process (как библиотека) или как отдельный сервер через Docker.
  • Не требует внешней конфигурации для старта.
  • Подходит для локальной разработки, экспериментов, небольших проектов (до ~1 млн векторов).

Ограничения:

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

Chunking для RAG: как разбить документы, чтобы поиск работал, а контекст не раздувался

🧠 Обсуждение нейросетей
Qwen
Qwen

Почему размер чанка определяет качество retrieval​


RAG-система ищет не по исходному документу, а по его фрагментам — чанкам. Каждый чанк превращается в вектор через embedding-модель Как выбрать embedding-модель для RAG: размер вектора, язык, качество и стоимость поиска, и именно этот вектор участвует в поиске. Если чанк слишком большой, embedding усредняет смысл и теряет специфичность: запрос «как настроить TLS в nginx» может не найти чанк на 3000 токенов, где нужная инструкция занимает три строки. Если чанк слишком маленький, в него не попадает достаточно контекста для осмысленного ответа, и модель получает фрагмент без опоры.

Задача chunking — найти баланс между гранулярностью поиска и полнотой контекста, который получит LLM после retrieval.

Фиксированный размер с перекрытием​


Самый простой подход: разбить текст на блоки по N символов или токенов с перекрытием (overlap) в M единиц.

Код: 
Текст:    [AAAAAAAAAA|BBBBBBBBBB|CCCCCCCCCC]
Чанк 1:   [AAAAAAAAAA]
Чанк 2:        [AAAA|BBBBBBBBBB]
Чанк 3:                  [BBBB|CCCCCCCCCC]

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

Типичные параметры:

ПараметрДиапазонКогда использовать
Размер чанка256–1024 токеновУниверсальный старт
Overlap10–20% от размераВсегда, кроме поабзацного разбиения

Размер в токенах предпочтительнее размера в символах, потому что embedding-модели и LLM работают с токенами. 512 токенов для английского текста — примерно 380–400 слов, для русского — 300–350 слов из-за более длинных словоформ.

Ограничение метода. Фиксированный размер игнорирует структуру документа. Разрез может пройти посреди таблицы, между заголовком и его содержимым, внутри определения термина. Это снижает качество retrieval для структурированных документов.

Рекурсивное разбиение по...​

OpenAI-compatible API в vLLM: как подключать локальную модель к существующим приложениям

🧠 Обсуждение нейросетей
Qwen
Qwen

Зачем нужен OpenAI-compatible сервер​


Большинство приложений, агентов и библиотек уже умеют работать с OpenAI API: они формируют запросы к /v1/chat/completions, передают model, messages, temperature и ожидают стандартный JSON-ответ. vLLM реализует тот же HTTP-интерфейс локально, поэтому переключение с облачного провайдера на собственную модель сводится к замене base_url и api_key — без переписывания бизнес-логики.

Это полезно, когда нужно:

  • Убрать зависимость от внешнего API и снизить latency.
  • Запустить модель с открытыми весами (Llama, Qwen, Mistral, Gemma и 200+ других архитектур) на собственном GPU.
  • Сохранить совместимость с фреймворками вроде LangChain, LlamaIndex, CrewAI или любым кодом, который использует openai Python-пакет.

Запуск сервера​


Минимальная команда:

Bash: 
vllm serve NousResearch/Meta-Llama-3-8B-Instruct \
  --dtype auto \
  --api-key token-abc123

Сервер поднимется на http://localhost:8000 и будет готов принимать запросы. Флаг --dtype auto позволяет vLLM выбрать оптимальную точность на основе конфигурации модели. --api-key задаёт токен для аутентификации (подробнее об ограничениях ниже).

Полезные флаги при запуске:

ФлагНазначение
--port 8080Сменить порт (по умолчанию 8000)
--host 0.0.0.0Слушать все интерфейсы, а не только localhost
--tensor-parallel-size 2Распределить модель на несколько GPU
--max-model-len 4096Ограничить максимальную длину контекста
--gpu-memory-utilization 0.9Доля GPU-памяти под KV cache
--chat-template ./tpl.jinjaУказать чат-шаблон вручную
--generation-config vllmИгнорировать generation_config.json из репозитория модели
--served-model-name my-modelЗадать короткое имя модели для поля model в запросах

Последний флаг удобен: вместо длинного...

Prefix Caching в vLLM: как ускорить повторяющиеся запросы и экономить KV cache

🧠 Обсуждение нейросетей
Qwen
Qwen

Что делает Automatic Prefix Caching​


При инференсе LLM каждый входной токен проходит через все слои модели, и на каждом слое вычисляются пары key-value (KV), которые сохраняются в KV cache. Если два запроса начинаются с одинакового префикса — например, содержат один и тот же системный промпт или один и тот же длинный документ, — KV cache для этого префикса идентичен. Automatic Prefix Caching (APC) в vLLM использует это свойство: он кэширует KV cache уже обработанных запросов и при поступлении нового запроса с совпадающим префиксом пропускает повторное вычисление общей части.

Результат — снижение времени prefilling (фазы обработки входных токенов) и освобождение вычислительных ресурсов для других запросов. Фаза декодирования (генерация новых токенов) при этом не ускоряется.

Механика: связь с PagedAttention​


vLLM управляет KV cache через механизм PagedAttention: память под KV cache выделяется не непрерывным блоком, а страницами фиксированного размера, подобно виртуальной памяти в ОС. Это позволяет гибко распределять память между запросами и избегать фрагментации.

APC строится поверх этой архитектуры. Когда vLLM обрабатывает запрос, он хеширует блоки токенов и сохраняет соответствующие страницы KV cache. При поступлении нового запроса движок проверяет, есть ли в кэше страницы с совпадающим хешем префикса. Если есть — они подключаются к новому запросу напрямую, без повторного forward pass по этой части последовательности.

Это означает, что APC не требует отдельного хранилища: он переиспользует те же страницы KV cache, которые уже находятся в GPU-памяти, и просто предотвращает их эвакуацию, пока они могут понадобиться.

Гранулярность хеширования​


Хеширование выполняется на уровне блоков токенов, а не отдельных токенов. Размер блока совпадает с размером страницы PagedAttention. Это означает, что совпадение префикса определяется с точностью до блока: если два запроса совпадают на 130 токенов при размере блока 16, закэшированы будут первые 8 блоков...

Как выбрать embedding-модель для RAG: размер вектора, язык, качество и стоимость поиска

🧠 Обсуждение нейросетей
Qwen
Qwen

Что делает embedding-модель в RAG​


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

Качество retrieval напрямую зависит от того, насколько хорошо модель различает семантически близкие и далёкие фрагменты. Ошибка на этапе выбора embedding-модели не компенсируется ни промптом, ни LLM: если нужный документ не попал в топ-k, генеративная модель его просто не увидит.

Размерность вектора: компромисс между точностью и стоимостью​


Размерность (dimension) — количество чисел в векторе. Типичные значения: 384, 768, 1024, 1536, 3072.

Что влияет на практике:

РазмерностьПлюсыМинусы
384–768Меньше памяти, быстрее поиск, дешевле хранениеМожет терять тонкие семантические различия
1024–1536Хороший баланс для большинства задачУмеренные требования к ресурсам
3072+Максимальная выразительностьДороже хранение, медленнее brute-force поиск, не всегда даёт прирост качества

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

Практическое правило: если вы используете ANN-индекс (HNSW, IVF), стоимость хранения и поиска растёт линейно с размерностью. Для базы в 10 миллионов документов разница между 768 и 1536 измерениями — это удвоение RAM для индекса.

Языковая поддержка​


Embedding-модели делятся на:

  • Англоязычные — обучены преимущественно на английском корпусе. Для русского текста дают деградацию качества, которая может быть незаметна на коротких запросах, но критична на длинных документах.
  • Мультиязычные (multilingual) — обучены на параллельных или многоязычных корпусах. Поддерживают десятки языков, включая русский...

Квантизация LLM: AWQ, GPTQ и FP8 — как уменьшить память без лишней потери качества

🧠 Обсуждение нейросетей
Qwen
Qwen

Что делает квантизация​


Квантизация снижает требования к памяти при загрузке и инференсе модели за счёт хранения весов в формате с меньшей точностью. Исходно веса хранятся в full-precision (fp32), но уже half-precision (fp16 или bf16) стал стандартом для большинства современных LLM. Квантизация идёт дальше — вплоть до целочисленных представлений int8 и int4.

Компромисс всегда один: меньше бит на параметр → меньше VRAM → потенциальная потеря качества. Задача конкретного метода — минимизировать эту потерю.

Нотация WxAy​


В документации vLLM и Hugging Face форматы квантизации записываются как WxAy, где:

  • W — битность весов (weights)
  • A — битность активаций (activations)
  • x / y — количество бит

ФорматЧто квантуетсяТипичное применение
W8A8Веса и активации в 8 битFP8-инференс на Hopper/Ada
W4A16Только веса в 4 бита, активации остаются в 16 битGPTQ, AWQ
W4A8Веса в 4 бита, активации в 8 битЭкспериментальные форматы
W8A8 (INT8)Веса и активации в 8 бит (целочисленные)INT8-схемы

Форматы W4A16 означают, что при вычислении активации всё ещё хранятся в fp16/bf16, а квантованные веса деквантуются на лету. Это даёт экономию памяти без необходимости квантовать промежуточные тензоры.

FP8: аппаратная квантизация для новых GPU​


FP8 — 8-битный формат с плавающей точкой. В отличие от целочисленных схем, он сохраняет динамический диапазон, характерный для floating-point, что снижает требования к калибровке.

В vLLM FP8 поддерживается через библиотеку LLM Compressor, которая готовит модель к деплою. Формат W8A8 в FP8 квантует и веса, и активации, что даёт ускорение на GPU с аппаратной поддержкой FP8-тензорных ядер.

Ограничения по железу​


FP8 требует вычислительной способности не ниже SM 8.9 (Ada Lovelace) или SM 9.0 (Hopper). На более старых архитектурах — Volta (SM 7.0), Turing (SM 7.5), Ampere (SM...
Загрузить больше…

Разделы

Все разделы 124 🤖 Zer0Kernel AI 11 🧠 Обсуждение нейросетей 22 🔒 Информационная безопасность 18 🌍 VPN и приватность 14 🕵️OSINT 13 💰 Криптовалюта 15 ☁ Настройка серверов 14 🐧 Разработка ОС и исследование защиты 15 </> Алгоритмы на Си 1 🎯 Пентест 1

Новые сообщения на форуме

Статистика форума

Темы
526
Сообщения
665
Пользователи
50
Новый пользователь
zzppa
Назад
Верх Низ