FlameTree Technical: Agents, NLP, LLM и Python backend

На вход подаются token ids, модель строит контекстные представления и возвращает logits по словарю для следующего токена. Decoding превращает logits в выбранный token id, он добавляется к контексту, и цикл повторяется.

На inference текст сначала токенизируется в token ids. Модель получает последовательность токенов, прогоняет ее через transformer blocks и на последней позиции выдает logits по словарю: для каждого возможного токена есть score следующего шага.

Дальше logits превращаются в вероятности или ранжирование: temperature, top-k/top-p, greedy decoding или beam search выбирают следующий токен. Выбранный token id добавляется к уже сгенерированной последовательности, после чего модель снова предсказывает следующий токен. Цикл заканчивается по special token, лимиту длины или stop condition.

Важно не говорить, что модель "сразу пишет весь ответ". Даже если API возвращает текст потоком, под капотом autoregressive LLM генерирует его пошагово.

Autoregressive модель предсказывает следующий токен по всем предыдущим. KV cache хранит key/value tensors прошлых токенов, чтобы на каждом новом шаге не пересчитывать attention для всего префикса заново.

В autoregressive generation вероятность ответа раскладывается как произведение вероятностей следующего токена при уже известном префиксе. На шаге t модель видит prompt и ранее сгенерированные токены, строит распределение следующего токена, выбирает его и переходит к шагу t+1.

Без кеша каждый новый шаг заново прогонял бы весь префикс через attention. KV cache сохраняет key/value представления прошлых токенов в каждом attention layer. Для нового токена достаточно посчитать query/key/value для него и attention к уже сохраненным key/value.

Trade-off: KV cache сильно ускоряет decoding, но занимает память пропорционально длине контекста, batch size, числу слоев и hidden size. Поэтому длинные контексты и много параллельных запросов быстро упираются в GPU memory.

Токенизатор переводит текст в последовательность token ids. Частые алгоритмы: BPE, WordPiece, Unigram/SentencePiece. Его обучают, когда нужен лучший coverage и меньше токенов на конкретном языке или домене.

Токенизатор разбивает текст на единицы, с которыми работает модель. Символьная токенизация слишком длинная, словарная плохо работает с редкими словами, поэтому современные LLM обычно используют subword tokenization.

BPE начинает с маленьких единиц и итеративно объединяет частые пары. WordPiece похож по идее, но выбирает merges через likelihood. Unigram/SentencePiece строит вероятностный словарь subword units и умеет работать без предварительного разделения на слова.

Обучать свой токенизатор имеет смысл, если готовый плохо покрывает язык, домен или формат данных. Например, для русского текста или специфических документов плохой токенизатор может давать слишком много токенов, повышать стоимость и ухудшать context efficiency. Но новый токенизатор усложняет совместимость с pretrained моделью.

Нужен fixed eval set под продукт, сравнение качества/latency/cost, проверка совместимости tokenizer/prompt/fine-tuning, затем canary или A/B с guardrails.

Сначала нужно понять, что значит "лучше": качество ответов, меньше hallucination, лучше retrieval usage, ниже latency, дешевле serving, больше throughput или проще self-hosting. После этого собирается fixed eval set из реальных запросов и edge cases.

Сравнение должно быть воспроизводимым: одинаковые prompts, одинаковый retrieval context, одинаковые параметры генерации, human/LLM-as-judge с калибровкой, regression tests на критичных сценариях. Отдельно проверяются latency, memory, GPU utilization, quantization compatibility, tokenizer и возможность дообучения.

Если offline результат хороший, модель выкатывают через canary или A/B с guardrails: ошибки, жалобы, fallback rate, latency p95/p99, стоимость, product metrics. Не стоит менять модель только потому, что она сильнее в публичном leaderboard.

Agent — это не только LLM, а цикл: цель/инструкция, состояние, планирование, tool calling, observation, память, guardrails и остановка. Модель выбирает действия, система выполняет их и возвращает наблюдения.

Обычный вызов LLM получает prompt и возвращает текст. Agent добавляет цикл принятия решений: есть задача, состояние, набор доступных инструментов, политика выбора следующего действия, выполнение tool call, observation и решение продолжать или остановиться.

Минимальные компоненты: LLM, prompt/system policy, tool registry с описанием интерфейсов, executor, память или state, механизм проверки результата, лимиты итераций и guardrails. В production также нужны логирование, retries, idempotency для действий, sandboxing инструментов и мониторинг стоимости/latency.

Хороший ответ обязательно говорит про ограничения: agents нестабильны на длинных горизонтах, могут зациклиться, вызвать неправильный инструмент, сделать небезопасное действие или потратить слишком много токенов. Поэтому их нужно ограничивать, тестировать на сценариях и иметь fallback.

Нужны четкая роль и задача, входные данные отдельно от инструкции, формат вывода, few-shot примеры, decomposition, запрет на догадки, schema validation и regression set для промптов.

Сильный ответ начинается не с "напишу красивый prompt", а с контракта: какие входы, какой формат выхода, что считается ошибкой и как это проверяется. Инструкции должны отделяться от пользовательских данных, особенно если есть риск prompt injection.

Практичные техники: system instruction с ролью и границами, явная структура ответа, JSON/schema output, few-shot примеры на типичных и edge cases, decomposition сложной задачи на шаги, request for citations/grounding при RAG, запрет на выдумывание и fallback "не знаю".

В production prompt engineering нельзя считать разовым ручным тюнингом. Нужен фиксированный eval set, версия prompt, сравнение метрик качества/latency/cost и мониторинг регрессий после изменения модели или retrieval pipeline.

Prompt/RAG выбирают для знаний, формата и быстрых итераций. Fine-tuning нужен, когда нужно устойчиво изменить стиль, доменную процедуру или поведение на большом наборе примеров, и это подтверждено eval set.

Сначала нужно проверить более дешевые варианты: prompt, few-shot, RAG, reranking, structured output и post-processing. Они проще откатываются, не требуют обучающего пайплайна и часто решают проблему, если модель уже умеет делать нужную операцию.

Fine-tuning имеет смысл, когда нужен устойчивый доменный стиль, формат, классификация, tool-use pattern или специфическая процедура, которую сложно удерживать prompt-ом. Нужны качественные пары input-output, train/validation split, метрики и проверка, что модель не деградировала на общих сценариях.

LoRA/PEFT снижает стоимость адаптации: базовые веса заморожены, обучаются небольшие adapter matrices. Это удобно для нескольких доменов и ограниченного железа, но все равно требует контроля данных, eval и serving compatibility.

LoRA замораживает исходные веса и добавляет к выбранным матрицам обучаемое low-rank обновление. Вместо полной матрицы обучаются две маленькие матрицы, поэтому параметров и optimizer state сильно меньше.

В обычном fine-tuning обновляются большие weight matrices модели. LoRA предполагает, что нужное изменение весов можно приблизить матрицей низкого ранга: вместо обучения полного delta W обучаются две меньшие матрицы A и B, произведение которых добавляется к исходной проекции.

Базовые веса остаются замороженными, поэтому меньше обучаемых параметров, меньше gradient/optimizer memory и проще хранить несколько доменных адаптеров. На inference adapter можно подключать отдельно или иногда слить с базовыми весами.

Ограничение: LoRA не магия. Качество зависит от данных, выбранных слоев/проекций, ранга, регуляризации и eval. Низкий ранг может не хватить для сложной адаптации, а плохие данные ухудшат модель так же, как при обычном fine-tuning.

Quantization хранит веса или активации в меньшей точности, например int8/int4 вместо fp16/bf16. Это уменьшает память и может ускорить inference, но дает риск деградации качества и требует eval.

Цель quantization — уменьшить memory footprint и bandwidth. Если веса хранятся в int8 или int4, модель занимает меньше GPU/CPU memory, можно поднять больший batch или модель на более дешевом железе. Иногда ускоряется и сам compute, если runtime хорошо поддерживает нужный формат.

Бывают post-training quantization и quantization-aware training. Можно квантизовать только weights или также activations/KV cache. Практические схемы отличаются granularities: per-tensor, per-channel, group-wise; часто используют calibration data, чтобы подобрать scales и снизить ошибку.

Главный trade-off — качество и стабильность на edge cases. Поэтому после quantization нужно прогонять доменный eval set, latency/memory benchmarks и проверять, не появились ли регрессии на длинных контекстах, редких языках или чувствительных задачах.

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

Single Responsibility: у класса или модуля должна быть одна причина для изменения. Open/Closed: поведение лучше расширять через новые реализации, а не постоянно править старую. Liskov Substitution: наследник должен быть заменяем базовым типом без сюрпризов для клиента.

Interface Segregation: лучше несколько маленьких интерфейсов, чем один большой, который заставляет реализовывать лишнее. Dependency Inversion: высокоуровневый код зависит от абстракций, а не от конкретных реализаций, чтобы можно было заменить БД, API-клиент или модель.

Важно подать SOLID как практические правила, а не религию. В Python это может быть выражено через модули, протоколы, композицию, dependency injection и тестируемые boundaries, а не обязательно через тяжелую OOP-иерархию.

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

Код с двумя декораторами:

@a
@b
def f():
    ...

эквивалентен f = a(b(f)). Значит, при объявлении сначала применяется b, потом a. Итоговая переменная f указывает на результат a(...), то есть на внешнюю обертку.

При вызове порядок выглядит наоборот с точки зрения входа в wrappers: сначала вызывается wrapper от a, внутри него может вызываться wrapper от b, и только потом исходная функция. Если wrappers делают код до и после вызова, важно отдельно проговорить enter/exit порядок.

asyncio дает cooperative concurrency для IO-bound задач. Корутина сама отдает управление на await, event loop переключает готовые задачи, но CPU-bound код без await будет блокировать loop.

async/await в Python нужен, когда много ожидания внешних операций: сеть, БД, файловые операции, timers. Корутина выполняется до await, затем отдает управление event loop. Loop может запустить другую готовую корутину, пока первая ждет IO.

Это concurrency, а не автоматический parallel CPU execution. В одном event loop код обычно выполняется в одном потоке, поэтому тяжелый CPU-bound цикл заблокирует все остальные корутины. Для CPU-bound нужны multiprocessing, native extensions, worker pool или вынос работы в отдельный сервис.

Плюс asyncio — высокий throughput для большого числа одновременных IO-запросов без большого числа потоков. Цена — нужно не блокировать loop, правильно обрабатывать cancellations/timeouts и использовать async-compatible клиенты.

Lock защищает критическую секцию для одной корутины, Event будит ожидающие корутины по сигналу, Semaphore ограничивает число одновременных операций, например запросов к API или соединений.

Threads делят память процесса и удобны для IO-bound задач, но GIL мешает параллельно исполнять Python bytecode на CPU. Processes имеют отдельную память и обходят GIL, но дороже по запуску и обмену данными.

Потоки внутри одного процесса разделяют память, поэтому между ними проще передавать объекты, но нужен контроль race conditions. В CPython GIL разрешает исполнять Python bytecode только одному потоку за раз, поэтому CPU-bound Python-код обычно не масштабируется на несколько ядер через threading.

Для IO-bound задач threads могут быть полезны: пока один поток ждет сеть или диск, другой может работать. Многие native операции освобождают GIL, поэтому детали зависят от библиотек.

Multiprocessing запускает отдельные процессы с отдельной памятью и своим GIL. Это подходит для CPU-bound Python work, но у процессов выше overhead, сложнее shared state, нужна сериализация данных, IPC/queues/pipes/shared memory и аккуратное управление worker lifecycle.

Fixture переиспользует setup/teardown логику в тестах: подготовить данные, клиент, БД, mock или конфиг. Scopes: function, class, module, package, session.

Fixture в pytest — это способ вынести повторяемую подготовку теста в отдельную функцию. Например, создать тестового пользователя, поднять соединение с БД, подготовить client, замокать внешний сервис или очистить состояние после теста.

Scope определяет, как часто fixture создается. function — на каждый тест, class — на класс, module — на файл, package — на пакет, session — один раз на весь запуск. Чем шире scope, тем быстрее может быть тестовый прогон, но тем выше риск shared state и зависимостей между тестами.

Хороший ответ: fixtures улучшают читаемость тестов, убирают duplication, позволяют управлять teardown через yield, а scope нужно выбирать по стоимости setup и риску загрязнения состояния.

Merge сохраняет историю ветвления и создает merge commit, если нужно. Rebase переносит commits ветки на новую базу и переписывает их, делая историю линейнее.

Практичное правило: локальную feature branch можно rebase-ить перед PR, чтобы убрать лишние merge commits. Общие опубликованные ветки лучше не переписывать без договоренности команды.

Multistage build разделяет этап сборки и финальный runtime image: в финальный образ попадает только нужный артефакт, без build tools, кешей и лишних зависимостей.

В первом stage обычно ставятся build dependencies, компилируется приложение, собирается frontend или wheel. Во втором stage берется чистый runtime image, куда копируются только готовые артефакты и минимальные runtime dependencies.

Плюсы: меньше размер образа, меньше attack surface, быстрее pull/deploy, меньше случайных зависимостей в production. Для ML/DS это полезно, когда нужно не тащить компиляторы, dev headers, notebooks и временные файлы в serving image.

Важно понимать, что multistage build не заменяет нормальный dependency management, но помогает сделать production image компактнее и безопаснее.

Нужен базовый набор: cd/ls/pwd, find/rg/grep, cat/less/tail, ps/top/htop, df/du/free, systemctl/journalctl, ss/lsof, env и chmod/chown. Важно объяснять, что именно диагностируешь.

Для навигации и файлов: pwd, ls -la, cd, find, rg или grep, cat, less, head, tail -f. Для места и ресурсов: df -h, du -sh, free -h, top или htop.

Для процессов и сервисов: ps aux, pgrep, kill, systemctl status/restart, journalctl -u service -f. Для сетевой диагностики: ss -tulpn, lsof -i, curl -i, иногда nc. Для окружения и прав: env, printenv, chmod, chown.

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