Как работает LLM — минимум для инженера

Результат главы

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

Наивная модель: «умная база данных»

Пользователь спрашивает статус заказа. Приложение получает «уже доставлен» и считает это чтением БД. Но генерация текста не содержит обязательного обращения к источнику статуса. Причина ошибки — подмена статистического продолжения проверенным фактом.

Для типичной авторегрессионной LLM полезна схема:

Это упрощение текстовой генерации, не схема каждого возможного model service. Runtime вокруг модели отдельно отвечает за инструменты и источник истины.

Токен — единица представления, не обязательно слово

Tokenizer преобразует текст в последовательность ID. Токен может соответствовать слову, части слова, знаку или последовательности байтов; правила зависят от tokenizer. Поэтому подсчёт слов не даёт точного бюджета токенов, особенно для кода, разных языков и необычных идентификаторов. Нужно использовать tokenizer, соответствующий модели. Hugging Face: Tokenizers.

Инженерное следствие: проверяйте бюджет на реальных входах. В нём есть не только сообщение пользователя, но и инструкции, schemas инструментов, история, найденные документы и резерв под ответ. Конкретные правила учёта и лимиты проверяются у выбранного model service.

Векторы и embeddings

Вектор — упорядоченный набор чисел. В поиске документ и запрос можно представить в одном пространстве и сравнить направления через cosine similarity. Например, у [1, 0] и [2, 0] одинаковое направление; у [1, 0] и [0, 1] скалярное произведение равно нулю.

Но смысл координат зависит от способа представления. В TF-IDF они связаны со словарными признаками. У learned embeddings представление обучено; близость полезна только настолько, насколько обучение и метрика подходят задаче. Одинаковая размерность двух моделей не делает их пространства совместимыми.

Не смешивайте: входные embeddings токенов внутри LLM, меняющиеся в слоях контекстные представления и embeddings целых документов для retrieval. Это разные объекты, даже если все представлены массивами чисел.

В Helios lexical baseline использует TF-IDF и нормализованные векторы, а не нейросетевой embedding service. Его механику можно увидеть без загрузки весов. scikit-learn: text feature extraction.

Attention: информация из других позиций

В scaled dot-product attention запросы Q сравниваются с ключами K; после масштабирования и softmax получаются веса, которыми смешиваются значения V: softmax(QKᵀ / √d) V. В self-attention эти представления получены из одной последовательности. Для causal generation маска ограничивает доступ к будущим позициям. Это механизм из архитектуры Transformer; исходная работа изучала прежде всего машинный перевод. Attention Is All You Need.

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

Инженерное следствие: «документ помещается» и «система правильно использует документ» — разные проверки. Попробуйте одну задачу с полным документом и с выбранным разделом; измерьте ошибки, а не объявляйте короткий контекст заведомо лучшим.

Вероятность продолжения не равна истинности ответа

В авторегрессионной постановке модель оценивает следующий токен с учётом предыдущих. При генерации последовательность растёт шаг за шагом. Обучение на задаче предсказания текста и дальнейшая адаптация помогают получить полезное поведение, но сами по себе не превращают вывод в проверку внешнего мира. Hugging Face: How Transformers work.

Учебный пример: три продолжения имеют вероятности 0.6, 0.3, 0.1. Их сумма равна 1. Выбор самого вероятного даст первое продолжение, sampling может выбрать другое. Из 0.6 нельзя вывести «вероятность успешного возврата денег 60%»: это вероятность токена в конкретном распределении, а не откалиброванная вероятность исхода бизнес-операции.

Параметры sampling меняют выбор продолжения; они не добавляют отсутствующий источник факта. Повторные прогоны нужны для измерения вариативности. Не объявляйте весь удалённый сервис детерминированным только из-за одного параметра генерации.

Обучение, inference и контекст

Действие	Что меняется	Чего само по себе не обеспечивает
Обучение / fine-tuning	Параметры модели по данным и objective	Свежий статус конкретного заказа
Inference	Вычисления с выбранными параметрами на текущем входе	Обновление весов от каждого сообщения
Few-shot examples	Примеры в текущем входе	Долговременное сохранение навыка в параметрах
Retrieval	Документы, доступные текущему вызову	Корректность и актуальность документа без проверки
Domain tool	Наблюдение из внешней системы	Безопасность действия без авторизации

При обучении функция потерь измеряет ошибку, а оптимизатор меняет параметры. В простом градиентном шаге w_new = w_old - learning_rate × gradient: движение локально направлено на уменьшение loss. Уменьшение training loss не доказывает качество на новых данных; для этого нужны отдельные splits и evals. Реализация backpropagation не нужна перед первой главой runtime.

Как выбрать способ улучшения

Наблюдаемая проблема	Первое проверяемое действие	Цена / предел
Непонятен нужный формат ответа	Явный контракт и несколько примеров	Нужна проверка на новых случаях, не только на примерах
Не хватает актуальных правил	Версионированный retrieval	Ошибки ingestion, поиска и доступа
Нужен статус/баланс	Domain API через узкий tool	Интеграция и policy boundary
Повторяемая ошибка на размеченной задаче	Baseline и затем эксперимент обучения	Данные, leakage, serving и поддержка

Это эвристика диагностики. Меняйте один фактор и сравнивайте одинаковые случаи. Подробности — в выборе модели и выпуске, после главы об evals.

Reasoning и проверяемое объяснение

Не стройте audit log вокруг скрытого chain-of-thought. Для проверки сохраняйте входные ограничения, решение, аргументы инструмента, policy result и наблюдаемый outcome. Для человека полезно краткое обоснование со ссылками на evidence. Правдоподобное объяснение всё равно требует проверки результата. Граница описана в Model I/O.

Лаборатория: где заканчивается сходство

После подготовки Python-окружения из корня репозитория:

uv run --directory examples/helios_ml --frozen python scripts/compare_retrieval.py

Сравните word_form для методов word и char: первый не находит «посылки» по слову «посылка», второй находит за счёт совпадений частей слова. Это улучшение лексического представления, не демонстрация понимания смысла нейросетью.

Затем найдите missing_fact: документ о возврате найден, но точная сумма отсутствует. Ответ имеет статус evidence_only и содержит выдержку. Запишите, какой дополнительный tool нужен для суммы и какое наблюдение позволит ответить пользователю.

В Helios следующий шаг — get_order или отдельный API расчёта возврата. Реальный аналог — интернет-магазин: текст общих правил не заменяет запись о конкретной покупке. Лаборатория не запускает LLM и не проверяет её токенизацию или attention; она делает наблюдаемой границу между поисковым совпадением и фактом.

Self-check

• Почему число слов нельзя использовать как точное число токенов?
• Что общего у TF-IDF и embeddings, а что различается?
• Почему attention не гарантирует соблюдение найденного исключения?
• Чем few-shot отличается от fine-tuning?
• Почему уверенный текст не подтверждает успешную транзакцию?
• Какое изменение вы проверите до решения обучать модель?

Далее: Ментальные модели → Model I/O. Если формулы пока трудны, достаточно объяснить их инженерные последствия; вернитесь к вычислениям в Applied ML.

Источники и актуальность

Проверено 2026-09-07. Механика представлений: Hugging Face: Tokenizers, Transformers, scikit-learn: feature extraction. Историческое исследование: Vaswani et al., 2017. Инженерные последствия и порядок диагностики — синтез курса; конкретные API, лимиты и sampling parameters проверяются отдельно для выбранной версии модели.