Ответы: AI-инженерия<a class="headerlink" href="#ответы-ai-инженерия" title="Permanent link">&para;

Читать: Efficient Memory Management for Large Language Model Serving with PagedAttention · GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints

2. Выведите объём памяти KV-кеша декодера в зависимости от размера батча и длины контекста.¶

Знания · Основы LLM · Чек-лист

При одинаковых длинах объём считается как 2 × батч × слои × токены × KV-головы × размер головы × байты на элемент. Двойка — это ключи и значения; запросы не сохраняют, потому что Q текущего шага нужен ровно одну итерацию, а ключи и значения всех прошлых позиций читаются на каждом следующем шаге. Кеш растёт линейно и по батчу, и по длине контекста, поэтому на длинных диалогах он может ограничивать конкурентность сверх бюджета весов. К формуле обязательно добавляют веса, активации и рабочие буферы, запас аллокатора и потери на padding, если длины разные и память выделяется прямоугольником; страничное выделение как в PagedAttention снижает эту фрагментацию. Я бы посчитал бюджет на реальном распределении длин и сверил с измеренной памятью под нагрузкой. Формула не учитывает сжатие кеша, оффлоад и архитектуры с иной схемой хранения.

3. Сравните multi-head, multi-query и grouped-query attention по качеству и памяти при инференсе.¶

Знания · Основы LLM · Чек-лист

Все три варианта сохраняют все головы запросов со своим паттерном внимания и различаются только ключами и значениями: в MHA пара K и V на каждую голову запроса, в MQA одна пара на всех, в GQA одна на группу. Кеш сжимается во столько раз, во сколько голов запросов больше, чем KV-голов: при 64 головах запросов и 8 KV-головах он в восемь раз меньше, чем в MHA, а в MQA — в шестьдесят четыре. Окупается это там, где decode упирается в чтение KV, то есть при большом батче и длинном контексте; при малом батче и коротких промптах шаг ограничен чтением весов, и меньшее число KV-голов задержку почти не меняет. Платим качеством: MQA теряет больше, GQA с несколькими группами остаётся близка к MHA, а перевод MHA-чекпойнта требует усреднить KV-головы внутри групп и дообучить примерно на пяти процентах исходных шагов предобучения. Я бы мерил конкурентность при фиксированной памяти, пропускную способность decode на длинном контексте и качество против MHA. При tensor parallelism единственная голова MQA копируется на каждое устройство, поэтому GQA с одной группой на шард занимает там столько же памяти и сохраняет больше качества.

Читать: GQA: Training Generalized Multi-Query Transformer Models from Multi-Head Checkpoints

4. Как результаты Chinchilla меняют выбор размера модели и числа обучающих токенов при фиксированном бюджете вычислений?¶

Знания · Основы LLM · Чек-лист

Chinchilla показывает, что при фиксированном бюджете вычислений число параметров и число обучающих токенов надо наращивать согласованно, тогда как прежняя практика брала слишком большую модель и слишком мало данных. Зависимость эмпирическая, подобранная по множеству прогонов разного размера, поэтому переносить её коэффициенты на другую архитектуру, токенизатор или корпус стоит осторожно. Главный компромисс в том, что оптимум обучения не равен оптимуму эксплуатации: если модель будет обслуживать огромный поток запросов, выгоднее взять меньше параметров и обучать дольше на большем числе токенов, заплатив временем обучения и выиграв на каждом запросе годами. Я бы посчитал совокупную стоимость владения, то есть обучение плюс прогноз инференса на горизонт жизни модели, и отдельно проверил, хватает ли качественных данных без вредного дублирования. Закон ничего не говорит о post-training, об ограниченных корпусах и о том, достижимо ли нужное качество вообще.

Читать: Training Compute-Optimal Large Language Models

5. Как проверить и уменьшить склонность модели пропускать важные сведения в середине длинного контекста?¶

Знания · Основы LLM · Чек-лист

Проверяется это переносом: берём вопрос, ответ на который лежит ровно в одном фрагменте, и двигаем этот фрагмент по позициям входа, ничего больше не меняя. Проседание в середине при неизменном содержимом и есть позиционный эффект, а не нехватка контекста. Мерить надо на нескольких длинах входа, с разным количеством похожих отвлекающих фрагментов и отдельно на каждой модели: поведение зависит от обучения и от длины, а размер окна сам по себе ничего не обещает. Смягчают проблему тремя путями: точнее искать, чтобы нужного текста было меньше; переранжировать и класть сильных кандидатов ближе к краям; сокращать контекст, суммируя или отбрасывая лишнее. Я бы завёл позиционный срез в регулярный eval-набор и перепроверял его при каждой смене модели. Универсального решения нет: длинный контекст остаётся дороже по деньгам и задержке и не заменяет хороший поиск.

Читать: Lost in the Middle: How Language Models Use Long Contexts

6. Сравните prefill и авторегрессионное декодирование: когда узким местом становятся вычисления, а когда пропускная способность памяти?¶

Знания · Инференс, serving и стоимость · Чек-лист

Prefill считает все позиции промпта за один проход и заполняет матричные блоки, поэтому, если промпт не совсем короткий, упирается в вычисления. Decode идёт авторегрессионно, по токену за итерацию: на каждом шаге приходится прочитать все веса слоя ради арифметики над одним токеном каждой последовательности, так что при малом батче арифметическая интенсивность низкая и ограничением становится пропускная способность памяти. Батчинг сдвигает границу — чем больше последовательностей идёт одновременно, тем лучше переиспользуются прочитанные веса и тем ближе decode к вычислительному пределу, но растёт KV-кеш и чтение самого кеша. Поэтому до любой оптимизации я бы снял профиль на реальном распределении длин промпта и ответа и посмотрел раздельно по фазам на достигнутую пропускную способность памяти и утилизацию вычислителей. Граница: на длинных контекстах decode остаётся ограниченным пропускной способностью памяти при любом батче, потому что каждая последовательность читает собственный кеш и этот трафик не разделяется, так что батчинг перестаёт помогать и выручает только уменьшение кеша.

Читать: Optimizing inference

7. Объясните батчинг на уровне итераций: как запросы добавляются в выполняющийся батч и покидают его?¶

Знания · Инференс, serving и стоимость · Чек-лист

Батчинг на уровне итераций означает, что планировщик пересобирает состав батча на каждом шаге генерации, а не ждёт, пока доработают все: новая последовательность входит на ближайшей границе итерации, а выдавшая стоп-токен или упёршаяся в лимит длины уходит сразу и освобождает место. Так утилизация не проваливается из-за одного длинного ответа. Платим сложностью планировщика и риском, что часть запросов будет вытесняться или ждать дольше остальных. Ограничивать надо не количество запросов, а суммарные токены шага и доступную KV-память, иначе пул кеша кончится и начнутся вытеснения с пересчётом. Я бы следил не только за throughput, но и за временем до первого токена, распределением ожидания в очереди и долей запросов, простоявших дольше порога. Планировщик не лечит перегрузку: при устойчивом превышении ёмкости нужен отказ или деградация, а не более хитрая очередь.

Читать: Efficient Memory Management for Large Language Model Serving with PagedAttention

8. Объясните точное speculative decoding, проверку предложенных токенов и случаи, когда draft-модель лишь добавляет накладные расходы.¶

Знания · Инференс, serving и стоимость · Чек-лист

Схема такая: дешёвая draft-модель генерирует несколько токенов вперёд, а целевая модель проверяет их одним параллельным проходом и за свой единственный шаг подтверждает сразу несколько позиций. Точность сохраняется честно: каждый предложенный токен принимается по сравнению вероятностей целевой и draft-модели, а при отказе токен пересэмплируется из скорректированного распределения, так что итоговое распределение совпадает с распределением целевой модели. Выигрыш определяется тремя величинами: средней долей принятых токенов, стоимостью прогона draft и наличием свободных вычислений под проверку. Мерить я бы стал среднее число принятых токенов за проход и сквозную задержку с draft-моделью и без неё на собственной нагрузке, а не на демонстрационном примере. Большой compute-bound батч оставляет меньше свободных вычислений, а расхождение draft и целевой модели снижает долю принятия. Любой из этих факторов может свести выигрыш к нулю или вызвать замедление.

Читать: Fast Inference from Transformers via Speculative Decoding

9. Оцените память для обслуживания модели с 70 млрд параметров, явно задав точность, контекст и конкурентность.¶

Прикладной сценарий · Инференс, serving и стоимость · Чек-лист

Сначала задаю условную архитектуру: 70 млрд параметров, 80 слоёв, восемь KV-голов размерности 128. Веса BF16 занимают около 140 ГБ, то есть примерно 130 ГиБ; int8 — 70 ГБ, четыре бита — 35 ГБ без метаданных квантования. Для KV в BF16 число байтов равно 2 × конкурентность × слои × токены × KV-головы × размер головы × 2. Выбираю контекст 8192 токена и четыре одновременные последовательности: KV-кеш занимает 10 ГиБ. На двух условных ускорителях по 80 ГиБ tensor parallelism может разделить веса и KV-головы, оставив примерно по 9,8 ГиБ на активации, буферы, фрагментацию и запас. Проверяю реально доступную память и пиковые выделения, при необходимости снижаю конкурентность. Это оценка вместимости, а не доказательство выполнения SLO по задержке.

Читать: Efficient Memory Management for Large Language Model Serving with PagedAttention

10. Вам поручили снизить стоимость инференса на порядок. Расставьте меры по приоритету и объясните, как проверить достижимость цели.¶

Прикладной сценарий · Инференс, serving и стоимость · Чек-лист

Меры я бы ранжировал по тому, куда реально уходят деньги, начиная с разбивки в стоимости успешной задачи при нужном качестве и SLO по задержке: входные токены против выходных, повторяющаяся доля входа и утилизация ускорителей. Каждый выходной токен требует своего шага decode, поэтому если доминирует выход, кеширование промпта почти не помогает, и рычаги другие: модель поменьше или дистиллят для той части трафика, с которой она справляется, и более короткие ответы. Если доминируют длинные повторяющиеся промпты, первыми идут кеширование префикса и сокращение контекста. Если утилизация низкая, батчинг и подгонка мощностей под нагрузку могут дать больше любой смены модели. Квантование удешевляет каждый шаг, но не убирает работу, и его потолок — выигрыш в несколько раз, а не на порядок. Меры взаимодействуют: меньшая модель сокращает то, что ещё могут сэкономить кеш и квантование, так что произведение отдельных выигрышей завышает итог. Каждую меру мерил бы отдельно, а связку целиком проверял на воспроизведённом продовом трафике против планки качества и p99. Если стоимость — это в основном выход модели, которую нельзя уменьшить без провала по качеству, десятикратной экономии может не существовать, и сказать это надо заранее.

Читать: Optimizing inference · Site Reliability Engineering

11. После релиза p99 задержки удвоился, хотя веса модели не менялись. Как локализовать причину?¶

Прикладной сценарий · Инференс, serving и стоимость · Чек-лист

Раз веса не менялись, ищу вокруг модели и начинаю с того, на что медленные запросы тратят время: ожидание в очереди, prefill, decode и вызовы зависимостей, по трассам хвостовых запросов до и после релиза, потому что p99 отдельных этапов не складываются в сквозной p99. Каждая составляющая указывает в свою сторону. Выросла очередь — значит, упала мощность или выросла нагрузка: меньший лимит батча, пропавшая реплика или новый сосед по железу толкают утилизацию к единице, где ожидание растёт нелинейно, и небольшая потеря способна удвоить хвост. Вырос prefill — вероятно, изменённый системный промпт или шаблон сломал общий префикс и обрушил долю попаданий в кеш префиксов. Вырос decode — ищу удлинившиеся ответы или вытеснения KV с пересчётом. Выросло время зависимостей — это хвост поиска или инструмента. Ещё сравниваю состав трафика: новый клиент приносит длинные промпты без единой правки кода. Дальше проверяю гипотезы по одной и подтверждаю откатом или canary; canary доказывает причинность только при сопоставимом трафике и соседях, иначе прогоняю записанный трафик через обе версии.

Читать: The Tail at Scale

12. Выберите подход к разбиению технической документации на чанки, сохраняя смысл на границах разделов.¶

Прикладной сценарий · RAG и поиск · Чек-лист

Резал бы по структуре документа, потому что эмбеддинг — это один вектор на чанк: чанк, захвативший две темы, усредняет их и не совпадает ни с одной, а разрезанный посреди инструкции теряет, к чему относятся «этот флаг» или «шаг выше». Единица — раздел; разделы длиннее нескольких сотен токенов рекурсивно делятся по абзацам с небольшим перекрытием, а блоки кода и таблицы остаются целыми, причём таблица сохраняет строку заголовков. Каждый чанк несёт цепочку заголовков, идентификатор документа и позицию в нём, поэтому понятен в отрыве от страницы и даёт точную ссылку. Компромисс в размере: мелкие чанки точнее попадают в запрос, но теряют контекст, крупные сохраняют его, но размывают вектор и забивают промпт. Базой беру окно фиксированного размера с перекрытием и сравниваю на характерных вопросах с известными исходными фрагментами: полноту поиска в первых k результатах, затем качество ответов, отдельно проверяя таблицы и ответы на стыке двух разделов. Граница: подходу нужна настоящая структура, и на сканированных PDF или непоследовательных заголовках я бы откатился к рекурсивному разбиению по размеру.

Читать: Contextual Retrieval in AI Systems

13. Когда стоит объединить лексический и векторный поиск и как свести их ранжирование?¶

Знания · RAG и поиск · Чек-лист

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

Читать: Contextual Retrieval in AI Systems

14. Как отдельно оценить поиск документов и генерацию ответа в RAG-приложении?¶

Прикладной сценарий · RAG и поиск · Чек-лист

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

Читать: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks · Demystifying evals for AI agents

15. Спроектируйте поиск с соблюдением прав исходной системы, включая изменения разрешений и общие кеши.¶

System design · RAG и поиск · Чек-лист

Права задаёт исходная система, а поиск применяет их до передачи текста модели. Передаю в поиск идентичность пользователя и фильтрую кандидатов по доступу; если свежесть ACL индекса неизвестна, проверяю права в авторитетной системе. Постфильтрация может снизить полноту, а проверять доступ лишь после генерации поздно. Изменения прав и удаления должны распространяться с измеримой задержкой; отзыв разрешений инвалидирует кеши, а кеш ответов учитывает актуальный доступ вызывающего. Общий кеш эмбеддингов необязательно разделять по пользователям, если он не раскрывает закрытый текст и поиск сохраняет проверку прав. Проверяю отзыв доступа, удаление документов и пользователей без прав, включая цитаты, подсказки и логи. Устаревание содержания можно обозначить, но при неизвестном статусе полномочий доступ надо закрыть, а не просто показать предупреждение.

Читать: Document-level access control

16. Сравните точный поиск, HNSW и IVF-PQ для индекса эмбеддингов при ограничениях памяти, полноты и задержки.¶

Знания · RAG и поиск · Чек-лист

Начинал бы я с точного поиска на выборке запросов: он даёт эталон, относительно которого слово recall вообще имеет смысл. HNSW строит многослойный граф соседей и жадно спускается по нему: поиск быстрый и точный, вставка не требует переобучения, но удаления обычно лишь помечаются, а граф целиком живёт в памяти и дорого по ней обходится. IVF-PQ сначала делит пространство на грубые кластеры и смотрит лишь несколько ближайших, а векторы хранит сжатыми с помощью product quantisation: памяти нужно меньше на порядок, а то и больше, зато квантование само по себе теряет точность, а кластеризацию приходится обучать на репрезентативных данных. Выбор делал бы по замеру recall относительно точного эталона при целевой задержке, отдельно измерив объём памяти, стоимость обновлений и удалений и поведение при фильтрах по метаданным. Маленькой коллекции приближённый индекс не нужен вовсе, а плохие эмбеддинги никакой индекс не исправит.

Читать: Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs · Faiss indexes

17. Что даёт чередование рассуждений и наблюдений от инструментов по сравнению с одними рассуждениями модели?¶

Знания · Агенты, инструменты и протоколы · Чек-лист

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

Читать: ReAct: Synergizing Reasoning and Acting in Language Models

18. Спроектируйте восстановление после ошибок и тайм-аутов инструментов, включая случай, когда операция уже изменила внешнее состояние.¶

System design · Агенты, инструменты и протоколы · Чек-лист

Перед повтором различаю временную ошибку, постоянную и неопределённое завершение. Таймаут записи неопределёнен: операция может ещё выполняться или уже завершиться. Для записи сохраняю с задачей клиентский ключ идемпотентности и повторно использую его в рамках гарантий провайдера. Без такой гарантии одного чтения состояния недостаточно: оно может устареть, пока исходный запрос ещё выполняется. Требую авторитетного окончательного статуса или сверки результата, иначе прекращаю автоматические повторы. Безопасные повторы ограничиваю числом попыток, общим дедлайном и экспоненциальным backoff с jitter. После исчерпания бюджета передаю человеку историю операции и нерешённый статус. Идемпотентность зависит от семантики провайдера, срока хранения и области действия ключа: само наличие ключа не делает запись безопасной.

Читать: Designing robust and predictable APIs with idempotency

19. Как выбрать, назвать и описать инструменты, чтобы модель верно выбирала операцию и аргументы?¶

System design · Агенты, инструменты и протоколы · Чек-лист

Модель выбирает инструмент только по имени, описанию и схеме, поэтому каждая пара пересекающихся инструментов — это развилка, на которой она может ошибиться, а каждый аргумент свободным текстом — место, где можно выдумать значение. Инструменты я бы строил вокруг задач агента, а не эндпоинтов API: поиск вместо списка, вываливающего все записи, имена с префиксом сервиса, перечисления везде, где вариантов конечное число, и строгая схема, чтобы неверный аргумент отсекала валидация раньше, чем его увидит внешняя система. Настоящий компромисс — гранулярность: несколько высокоуровневых инструментов снижают ошибки выбора, но усложняют аргументы, а много тонких оставляют аргументы простыми, но делают выбор неоднозначным, а цепочки длиннее. Результаты разбиты на страницы и ограничены по объёму, а ошибка говорит, что именно исправить. На фиксированном наборе реалистичных задач я бы измерял долю вызовов с верным инструментом и корректными аргументами и токены на задачу — до и после каждого слияния или переименования. Граница: когда инструментов становятся десятки, выбор ухудшается даже при хороших описаниях, поэтому я бы подгружал инструменты под задачу.

Читать: Writing effective tools for AI agents—using AI agents

20. Задайте критерии завершения и остановки агентного цикла, исключающие бесконечные затраты на незавершённую задачу.¶

System design · Агенты, инструменты и протоколы · Чек-лист

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

Читать: Building Effective AI Agents

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

System design · Агенты, инструменты и протоколы · Чек-лист

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

Читать: Building Effective AI Agents · Designing robust and predictable APIs with idempotency

22. Разберите RLHF на предпочтениях и объясните роль reward model и штрафа за отклонение от опорной политики.¶

RLHF раскладывается на три этапа, различающихся данными. Сначала демонстрации: примеры желаемых ответов, на которых базовую модель дообучают обычным способом с учителем. Затем пары предпочтений: человеку показывают несколько ответов на один промпт и просят их упорядочить, и на этих сравнениях учится reward model — отдельная модель, предсказывающая, какой ответ человек выберет. На третьем этапе политика оптимизируется по этой награде уже на собственных траекториях, а к цели добавляется штраф за расхождение с опорной моделью, обычно KL-дивергенция: без него политика уходит туда, где награда высока, а текст деградировал. В этом и компромисс: сильнее давим на награду — быстрее ловим её переоптимизацию. Проверять нужно на отложенных человеческих предпочтениях, а не по самой награде, и смотреть, как расхождение с опорной моделью соотносится с реальным выигрышем. Граница: reward model наследует смещения разметчиков, а оптимизация их усиливает.

Читать: Training language models to follow instructions with human feedback

23. Сравните DPO с RLHF на PPO, включая предпосылки обучения по офлайн-предпочтениям и причины собирать новые траектории.¶

DPO исходит из той же цели с KL-регуляризацией, что и RLHF на PPO, но берёт её решение в замкнутой форме: награда становится неявной — β, умноженное на логарифм отношения вероятностей политики и опорной модели, плюс слагаемое, зависящее только от промпта. В модели предпочтений Брэдли–Терри это слагаемое сокращается, и функция потерь записывается прямо на политике: логистическая потеря от β, умноженного на разность логарифмических отношений для выбранного и отвергнутого ответов. β играет роль штрафа KL, а reward model, value-сети и цикла генерации нет. Цена — предпосылка: фиксированные пары должны покрывать то, что будет генерировать политика, ведь функция потерь формирует только ответы из пар и может снижать вероятность обоих ответов или сдвигать модель к длинным ответам. PPO оценивает свежие траектории текущей политики и ловит ошибки там, где они реально возникают, ценой reward model, которую можно обмануть. Сравнивал бы долю побед над опорной моделью на отложенных промптах, KL и дрейф длины. Простая функция потерь не означает лучшего выравнивания: если нужно крупное изменение поведения или награда проверяема, свежие траектории окупают свою цену.

Читать: Direct Preference Optimization: Your Language Model is Secretly a Reward Model

24. Выведите низкоранговое обновление весов LoRA и предложите эксперимент для выбора ранга.¶

LoRA замораживает исходную матрицу весов и учит вместо неё низкоранговую поправку: ΔW = BA, где B имеет размер d на r, A — размер r на k, а r много меньше и d, и k. Вместо d×k обучаемых параметров остаётся r×(d+k), то есть при малом ранге экономия на порядки, и при инференсе поправку можно сложить с базовыми весами, не платя дополнительной задержкой. Ограничение в том, что ранг задаёт выразительность: слишком малый r просто не вмещает нужное изменение поведения. Эксперимент прямолинейный — зафиксировать данные и набор модулей, менять только r по сетке значений и сравнивать качество на отложенных задачах, одновременно проверяя регрессии общих способностей. Граница: слияние адаптера удобно, но лишает возможности держать на одной базе несколько адаптеров и переключать их по запросу.

Читать: LoRA: Low-Rank Adaptation of Large Language Models

25. Как QLoRA сокращает память дообучения и какие тензоры остаются обучаемыми или требуют большей точности?¶

QLoRA экономит память тем, что базовые веса хранятся квантованными в четырёх битах и остаются замороженными, а обучаются только низкоранговые адаптеры в 16 битах: градиент проходит назад через деквантованные базовые веса, но градиенты по весам и состояния оптимизатора существуют лишь для адаптеров, а именно они съедали основную часть памяти при полном дообучении. Три приёма работают вместе: NF4 — формат квантования, рассчитанный на нормально распределённые веса; двойное квантование сжимает сами константы квантования; paged optimizers выносят состояния оптимизатора в память процессора при всплесках. Платим вычислениями: веса деквантуются в вычислительную точность на каждом матричном умножении, что может замедлить обучение в зависимости от реализации. Память активаций при этом никуда не исчезает и растёт с длиной последовательности и батчем, так что на длинном контексте она снова становится ограничением. Граница: это способ уместить дообучение в меньшую память, а не способ гарантированно получить качество полного дообучения на любой задаче.

Читать: QLoRA: Efficient Finetuning of Quantized LLMs

26. Выберите между изменением промпта, retrieval и дообучением для неудачной AI-функции; учтите свежесть данных, задержку и полную стоимость.¶

Прикладной сценарий · Дообучение и post-training · Чек-лист

Вмешательство я бы выбирал по диагностике: прогоняю выборку реальных провалов заново, вставив в промпт нужный документ. Если теперь получается, модели не хватало знаний, и подходит retrieval: факты остаются свежими без переобучения, ответы могут ссылаться на источники, а платим задержкой на лишнее обращение к поиску и индексом, который надо поддерживать. Если с нужными сведениями перед глазами модель всё равно ошибается, дело в инструкциях или поведении, и я ужесточаю промпт явными правилами и примерами; это дёшево и становится baseline, который остальное обязано обойти. Дообучение — для того, что остаётся после этого: формат, тон или схема решений, которые промпт не удерживает надёжно, и только когда набралось достаточно характерных примеров, чтобы обучить и ещё оставить часть на отложенную проверку. Его цена — весь жизненный цикл: разметка, обучение, оценка и повторение всего этого при смене базовой модели, хотя более короткие промпты могут снизить токены и задержку на запрос. Сравнивал бы варианты на одной отложенной выборке по стоимости успешной задачи. Дообучение не сделает факты свежими, а retrieval не исправит модель, которая игнорирует найденное.

Читать: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks · LoRA: Low-Rank Adaptation of Large Language Models

27. Спроектируйте LLM-судью и калибровку, выявляющую смещения из-за порядка, многословия и предпочтения собственных ответов.¶

System design · Оценка качества и наблюдаемость · Чек-лист

Судья начинается не с промпта, а с критериев: что именно считается хорошим ответом в этой задаче, сформулированное так, чтобы два человека сошлись. Дальше нужна отложенная калибровочная выборка с человеческой разметкой — она измеряет самого судью, иначе мы просто доверяем модели оценивать модель. Известные смещения проверяются экспериментом: прогнать каждую пару в обоих порядках и посмотреть, меняется ли вердикт; раздуть ответы повторами без нового содержания и посмотреть, не начнут ли они выигрывать, чтобы поймать награду за многословие; сравнить, как часто судья предпочитает ответы своего семейства и как часто их предпочитают люди на тех же парах, ведь судья может отдавать предпочтение своему стилю даже при скрытом авторстве. Я бы считал согласие судьи с людьми и долю пар, где перестановка меняет решение, а ненадёжные случаи отправлял экспертам. Граница: судья измеряет соответствие критериям, а не пользу для пользователя, и там, где ответ проверяется детерминированно, дешевле обычная проверка.

Читать: Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena

28. Спроектируйте критерии допуска изменений промпта и модели, включая ситуацию, когда общий рост скрывает критическую регрессию.¶

System design · Оценка качества и наблюдаемость · Чек-лист

Версионирую всё — промпт, модель с параметрами, датасет и код оценщиков — и сравниваю кандидата с зафиксированным baseline на тех же примерах. Правило — не одно среднее: агрегат не должен просесть, а у каждого критического среза — безопасность, деньги, редкие, но дорогие сценарии — своё правило. Самое трудное — статистика на маленьких срезах. На 50 примерах при доле успеха 90% 95-процентный доверительный интервал — примерно плюс-минус восемь пунктов, так что регрессию в три пункта просто не видно. Поэтому сравниваю попарно, пример за примером, с несколькими сэмплами на пример, и считаю примеры, которые перешли из прошедших в проваленные; для самых тяжёлых отказов держу обязательные примеры, где любой такой переход блокирует выпуск. Пороги и веса тяжести фиксируются до прогона, потому что строгий гейт отклоняет хорошие релизы, а мягкий пропускает регрессии, и этот выбор — продуктовое решение. Дальше canary на малой доле трафика с числовыми порогами отката. Граница: гейт видит только те режимы отказа, которые покрыты датасетом.

Читать: Demystifying evals for AI agents

29. Результаты бенчмарков растут, а пользователи жалуются на ухудшение продукта. Какие гипотезы проверить сначала?¶

Прикладной сценарий · Оценка качества и наблюдаемость · Чек-лист

Гипотезы я бы упорядочил по тому, насколько дёшево каждую отбросить. Первая — причины вне модели: задержка, формат ответа, обрезка или изменённый системный промпт; это видно в логах за день. Вторая — несовпадение состава: разметить выборку живого трафика по типам задач, языку и длине и перевзвесить прирост на бенчмарке по этому составу; если прирост исчезает, модель улучшилась там, где пользователей нет. Третья — регрессия на срезе, которую прячет среднее; её покажут изменения по срезам. Четвёртая — прямая проверка самой жалобы: слепое попарное сравнение старой и новой модели на выборке продовых запросов с оценкой людьми или судьёй, откалиброванным по людям. Если новая модель там выигрывает, жалобы о чём-то другом, часто об изменившихся ожиданиях. Пятая — утечка тестов: пересечение n-грамм с обучающими данными и перефразированные задания бенчмарка, на которых настоящий прирост сохраняется. Воспроизведённые жалобы становятся тест-кейсами, но часть я бы держал отдельно, потому что оптимизация прямо под них снова оторвёт метрику от пользы.

Читать: Rules of Machine Learning

30. Спроектируйте наблюдаемость LLM-процесса в production: какие spans, версии, затраты и обратную связь нужно связать?¶

System design · Оценка качества и наблюдаемость · Чек-лист

Каждая пользовательская задача получает один trace id, к которому привязаны все spans — вызовы модели, retrieval и вызовы инструментов, — и каждый помечен версиями промпта, модели, индекса и кода, так что трасса отвечает не только на вопрос, что сломалось, но и после какого изменения. На каждом span пишу задержку, токены, стоимость, исход и код ошибки, а пользовательская обратная связь несёт тот же идентификатор. Чувствительно именно содержимое, поэтому структуру и метрики храню для всех задач, а полные тексты — по tail-based sampling: каждая неудачная задача, низкая оценка судьи или дизлайк плюс небольшая фиксированная доля успешных как база для сравнения, с маскированием полей и коротким сроком хранения. Тогда сбой читается прямо: span поиска, вернувший пустоту, после которого идёт уверенный ответ, попадает в корзину необоснованных ответов, а не ошибок модели. Измерял бы долю сбоев, отнесённых к конкретному этапу, время диагностики и тексты, проскочившие маскирование, а повторяющиеся корзины превращаю в eval-кейсы. Граница: неверный, но гладкий ответ выглядит как успех, поэтому его полный текст сохранится, только если его отметит обратная связь или судья.

Читать: Site Reliability Engineering · Demystifying evals for AI agents

31. Чем оценка агента с инструментами должна отличаться от проверки одного сгенерированного ответа?¶

System design · Оценка качества и наблюдаемость · Чек-лист

Главное отличие в том, что у агента есть результат в среде, и проверять надо именно его, а не текст, которым агент отчитался об успехе. Слово «готово» ничего не стоит, поэтому оценка читает конечное состояние: создана ли запись, отправлено ли письмо, в каком статусе тикет. Второе измерение — траектория: задача может быть выполнена ценой лишних вызовов, потраченных денег или опасного действия вроде удаления, и это оценивается отдельно от факта выполнения, иначе плохой путь маскируется хорошим исходом. Третье — повторяемость: один удачный прогон ничего не доказывает, нужны несколько испытаний из одинакового чистого состояния среды и измеренная доля успехов, потому что агент недетерминирован. Граница: всё это требует изолированных сред с воспроизводимым состоянием, они дороги и всегда беднее реальности, поэтому часть режимов отказа проявится только в проде.

Читать: Demystifying evals for AI agents

32. Сравните проекционные слои, cross-attention и токенное представление для подключения изображений к языковой модели.¶

Знания · Мультимодальность и голос · Чек-лист

Я бы разделил кодировщик, превращающий пиксели в признаки, и интерфейс, который соединяет их с языковой моделью; три варианта различаются именно интерфейсом. Проекция переводит признак каждого патча в пространство эмбеддингов модели, и результат встаёт в последовательность как текст: обучать дёшево, декодер не меняется, но число токенов растёт с разрешением, и картинка 336 × 336 при патчах по 14 пикселей — это 576 токенов контекста, prefill и KV-кеша. Cross-attention, как во Flamingo, держит признаки вне последовательности, сжимает их в фиксированный набор векторов и вставляет в замороженную модель слои перекрёстного внимания с гейтами, которые стартуют с нуля, так что поначалу поведение на тексте не меняется; последовательность остаётся короткой, но новые слои надо обучать. Дискретные токены квантуют изображение в обученный кодбук, добавленный к словарю, и модель может ещё и генерировать картинки, но квантование теряет мелкие детали. Всем трём нужно обучение выравниванию на парах изображение–текст. Сравнивал бы их на тексте внутри изображения и пространственных задачах, строя зависимость точности от числа визуальных токенов на картинку: на плотных документах фиксированное сжатие выбрасывает ровно то, что важно.

Читать: Flamingo: a Visual Language Model for Few-Shot Learning

33. Как улучшать и проверять распознавание смешанных языков в реплике и разных акцентов?¶

Прикладной сценарий · Мультимодальность и голос · Чек-лист

Начинал бы с оценки, потому что средний WER прячет ровно те группы, ради которых работа затевается. Собрал бы срезы по языкам, акцентам, шуму и переключению языков, в каждом достаточно разных говорящих, и показывал WER по срезу с доверительными интервалами, полученными бутстрепом по говорящим: реплики одного человека коррелируют. Переключение языков требует отдельного внимания: модель вроде Whisper предсказывает один языковой токен на сегмент и декодирует с оглядкой на него, поэтому вставка на другом языке может выйти транслитерацией или даже переводом, а сама оценка неоднозначна: заимствованное слово, записанное другим алфавитом, считается ошибкой, пока это не решат правила нормализации. Помимо WER отслеживал бы ошибки в именах, суммах и других сущностях, от которых зависит действие: одна неверная цифра весит больше множества мелких промахов. Дешёвый рычаг — подсказать декодированию список терминов или промпт, но это помогает только с известными словами; дообучение на речи с акцентами и с переключением языков даёт больше, но может ухудшить другие языки. Любую адаптацию проверял бы на отложенных говорящих и доменах, а срез из нескольких говорящих не считал бы доказательством ни в какую сторону.

Читать: Robust Speech Recognition via Large-Scale Weak Supervision

34. Спроектируйте помощника по десяти миллионам корпоративных документов с индивидуальными правами и постоянно меняющимся корпусом.¶

System design · Дизайн AI-систем · Чек-лист

Сначала уточнил бы объём запросов, требования к свежести и семантику прав, а уже потом считал. При условных двадцати фрагментах на документ это двести миллионов векторов, около 800 ГБ при размерности 1024 во float32, так что индекс шардируется или сжимается product quantisation, а полноту сверяю с точным поиском. Загрузка событийная: изменённые документы заново режутся и пересчитываются в эмбеддинги, удалённые сразу помечаются как удалённые, а индекс версионируется. Решающее: изменения прав должны распространяться быстрее переиндексации. ACL хранится на каждом фрагменте как идентификаторы групп и обновляется без пересчёта эмбеддингов, а группы пользователя определяются в момент запроса, так что изменение членства действует уже со следующего запроса. Фильтр должен стоять внутри ANN-запроса: постфильтрация top-k может почти ничего не оставить пользователю, которому виден малый срез корпуса, а фильтрация во время обхода графа держит полноту, пока разрешённое множество не станет совсем маленьким, — тогда переключаюсь на точный поиск по этому подмножеству. Измерял бы задержку отзыва прав на p99, полноту с фильтром и обоснованность ответов, а отказ шарда показывал бы как неполное покрытие. Устаревший текст можно показать с датой, а при неясных полномочиях доступ закрывается.

Читать: Document-level access control · Contextual Retrieval in AI Systems

35. Спроектируйте LLM gateway с маршрутизацией, failover, кешированием, лимитами запросов и обязательными бюджетами.¶

System design · Дизайн AI-систем · Чек-лист

Gateway существует ради единого контракта поверх разных провайдеров, поэтому сначала я описываю их возможности — потоковую выдачу, вызов инструментов, лимиты контекста, поведение при отказе — и унифицирую только действительно совместимую семантику; остальное выставляю явно, а не эмулирую, иначе клиент незаметно получит другое поведение. Квоты и бюджеты проверяю до отправки запроса, отдельно по каждому клиенту, и обязательно учитываю повторы, иначе failover сам съест бюджет; при исчерпании возвращаю понятную ошибку с указанием, когда пробовать снова. Целые ответы кеширую только там, где допустимо дважды вернуть один и тот же ответ, и ключ включает клиента, модель и параметры, иначе кеш отдаст ответ другого клиента или другой модели. Самое тонкое — границы failover: если часть ответа уже ушла клиенту, переключить провайдера без разрыва потока нельзя, а вызов с побочными эффектами нельзя повторять без идемпотентности. Граница: gateway выравнивает интерфейсы и отказы, но не сгладит разницу в качестве моделей.

Читать: Scaling your API with rate limiters · Designing robust and predictable APIs with idempotency

36. Спроектируйте агента поддержки, который выполняет сервисные действия и при необходимости передаёт обращение человеку.¶

System design · Дизайн AI-систем · Чек-лист

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

Читать: Building Effective AI Agents · Writing effective tools for AI agents—using AI agents

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

System design · Дизайн AI-систем · Чек-лист

Число одновременных потоков ограничено памятью под KV-кеш, а не вычислениями, поэтому мощность считаю от неё. Допустим, 100 миллионов пользователей в день, по десять ответов на каждого и по 20 секунд потоковой выдачи на ответ: в среднем около 230 тысяч одновременных потоков, в пик — скажем, полмиллиона. Модели класса 70B с 80 слоями и восемью KV-головами размерности 128 нужна треть мегабайта кеша в bf16 на токен, так что диалог на 4000 токенов держит 1,3 ГБ, а при условных 80 ГБ свободной памяти под кеш реплика вмещает около 60 потоков — слишком мало, чтобы загрузить вычисления. Это порядка 8000 реплик без учёта запаса. Поэтому допуск считает свободные блоки кеша: запрос стартует, только если помещается его ожидаемая длина, иначе ждёт в ограниченной очереди или сразу получает отказ с подсказкой, когда повторить. Закрытое соединение отменяет генерацию и освобождает её блоки. Диалоги — два миллиарда сообщений в день — пишутся в append-only хранилище с партиционированием по диалогу, поэтому оборванный поток продолжается с последнего сохранённого сообщения. Граница: при коротких диалогах или квантованном кеше ограничением становится пропускная способность декодирования, и допуск считают по токенам на шаг.

Читать: Site Reliability Engineering · Efficient Memory Management for Large Language Model Serving with PagedAttention

38. Реализуйте scaled dot-product attention с causal mask и тестами, выявляющими доступ к будущим токенам.¶

Начал бы с явного контракта по размерностям: батч, головы, длина, размер головы, и проверка формы на входе, потому что большинство ошибок тут именно в перепутанных осях и в молчаливом broadcast. Дальше scores как произведение Q на транспонированный K по последней оси, деление на корень из размера головы, маскирование будущих позиций j > i значением минус бесконечность при разрешённых диагонали и прошлом, устойчивый softmax с вычитанием построчного максимума и умножение на V. Маска обязательно до softmax: зануление весов после нормировки неверно, сумма уже испорчена будущими позициями. Тесты делал бы двух видов: крошечный пример с числами, посчитанными вручную, и главное — тест причинности, где меняем токены после позиции и убеждаемся, что выходы до неё не изменились. Одна только causal mask никогда не закрывает строку целиком, ведь диагональ разрешена, но с маской паддинга строка может оказаться замаскированной полностью, и softmax даст NaN, поэтому этот случай я бы проверил отдельно. Это учебная реализация: в отличие от FlashAttention, она не экономит память и не покрывает кеширование на инференсе.

Читать: Attention Is All You Need

39. Реализуйте token-bucket limiter и объясните изменения для общего лимита, применяемого несколькими воркерами.¶

Ведро хранит две величины: текущее число токенов и момент последнего пополнения. На каждом обращении считаю прошедшее время по монотонным часам, добавляю произведение времени на скорость пополнения, обрезаю сверху ёмкостью и списываю запрошенное, если хватает. Ёмкость задаёт допустимый всплеск, скорость — средний темп, и это основной компромисс настройки. Системные часы брать нельзя: перевод времени или синхронизация дадут отрицательный интервал либо подарят полное ведро. Проверка и списание обязаны быть одной атомарной операцией под замком, иначе два потока увидят один и тот же последний токен. Тестировал бы всплеск на полном ведре, отказ на пустом и восстановление ровно через нужный интервал, подставляя часы вместо ожидания. Для общего лимита нескольких воркеров нужен внешний счётчик со скриптом, выполняющим пополнение и списание атомарно, либо деление квоты по воркерам: дешевле, но менее точно у границ.

Читать: Scaling your API with rate limiters

40. Напишите асинхронный обработчик батча API-запросов с ограничением конкурентности, jitter повторов и изоляцией ошибок элементов.¶

Взял бы фиксированный пул воркеров, забирающих элементы из очереди, а не по задаче на элемент за семафором, чтобы вход на миллион элементов не порождал миллион ожидающих задач. Каждый элемент выполняется в обёртке, которая превращает его собственные сбои в результат — значение, постоянную ошибку или отмену — и пишет его по индексу входа, так что один сбой не топит соседей, в отличие от task group, которая отменяет всё при первой ошибке. У каждой попытки свой тайм-аут внутри общего дедлайна, а отмена батча снимает и выполняющиеся запросы, так что обёртка не должна эту отмену проглатывать. Повторяю только тайм-ауты, сетевые ошибки, ответы о превышении лимита и серверные ошибки, с ограниченным экспоненциальным backoff и full jitter, то есть случайной паузой от нуля до текущей величины backoff, чтобы клиенты не повторяли запросы волнами, а заголовок Retry-After главнее. Небезопасные записи повторяю только с ключом идемпотентности. Тесты — с поддельными часами и API: частичный успех, постоянная ошибка, дедлайн посреди повтора и отмена на середине. Граница: backoff по отдельным элементам не ограничивает суммарный темп, поэтому при общей квоте перед вызовами нужен token bucket.

Читать: Designing robust and predictable APIs with idempotency · Site Reliability Engineering

41. Как разреженная маршрутизация по экспертам увеличивает число параметров и какие затраты сохраняются при активации части экспертов?¶

Знания · Основы LLM · Чек-лист

Маршрутизация покупает ёмкость, а не бесплатный масштаб: модель хранит намного больше параметров, но любой отдельный токен считается лишь небольшой их частью. Маршрутизатор оценивает экспертов для каждого токена и отправляет его к нескольким лучшим, поэтому арифметика растёт с числом активированных экспертов, а не с общим, а качество выигрывает от их специализации. Память при этом не уменьшается: веса всех экспертов остаются размещёнными, а при распределённом обслуживании сами токены едут к устройству со своим экспертом, и обмен all-to-all оказывается на критическом пути. Я бы измерил число токенов на эксперта, чтобы увидеть перекос, долю отброшенных при достижении ёмкости эксперта и долю all-to-all во времени шага, сравнивая качество с плотной моделью того же активного размера. Рассуждение верно лишь пока маршрутизация сбалансирована, а батчи достаточно велики, чтобы этот обмен амортизировался.

Читать: Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity

42. Объясните, как latent attention сжимает представление KV и что приходится восстанавливать при инференсе.¶

Знания · Основы LLM · Чек-лист

Латентное внимание меняет то, что вы храните, а не точность хранения. Key и value проецируются вниз в один низкоранговый латентный вектор на токен, и именно латент лежит в кеше; во время внимания он либо проецируется обратно в key и value по головам, либо матрицы обратной проекции встраиваются в проекции запроса и выхода, и внимание считается прямо по латенту, а позиционная часть кешируется отдельным небольшим ключом. Байты кеша на токен поэтому падают примерно во столько раз, каково сжатие, а платой становятся дополнительная арифметика на каждом шаге декодирования и более сложные ядра. Я бы измерил байты кеша на токен, достижимые в той же памяти длину контекста и размер батча, пропускную способность декодирования и качество против grouped-query при равном бюджете кеша. Различение важно, потому что квантование снижает точность тех же тензоров: одно с другим сочетается, поэтому у каждого должен быть свой baseline, иначе одну экономию посчитают дважды. Выигрыш реален лишь тогда, когда вас ограничивает KV-кеш, а не веса.

Читать: DeepSeek-V2: A Strong, Economical, and Efficient Mixture-of-Experts Language Model

43. Когда префикс промпта можно переиспользовать и какие изменения обесценивают или инвалидируют кеш?¶

Знания · Инференс, serving и стоимость · Чек-лист

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

Читать: Prompt caching

44. Как страничная организация KV-кеша сокращает потери памяти и какие задачи остаются планировщику?¶

Знания · Инференс, serving и стоимость · Чек-лист

Страничная организация борется с фрагментацией, а не с нехваткой памяти. Если каждый запрос резервирует один непрерывный отрезок под самый длинный возможный ответ, большая часть резерва простаивает, а оставшаяся свободная память непригодна, потому что разбросана, — и параллелизм падает задолго до реального заполнения устройства. Страницы хранят кеш блоками фиксированного размера с таблицей на запрос, отображающей логические позиции в физические блоки: рост идёт постепенно, внутренние потери ограничены одним неполным блоком, а одинаковые префиксы или параллельные сэмплы могут ссылаться на общие блоки, копируемые только при записи. Нетронутой остаётся политика: кого принимать, когда блоки закончились, чьи блоки вытеснять или пересчитывать и сколько запрос может ждать. Я бы измерял достигнутый размер батча, долю памяти, реально занятой живыми токенами, частоту вытеснений и p99 задержки: страницы увеличивают вместимость, но плохой планировщик всё равно может оставить часть запросов голодать.

Читать: Efficient Memory Management for Large Language Model Serving with PagedAttention

45. Сервис может потратить больше вычислений на один reasoning-запуск или получить несколько кандидатов и проверить их. Как распределить бюджет при ограничении задержки?¶

Прикладной сценарий · Инференс, serving и стоимость · Чек-лист

Я бы решал это измерением, а не предпочтением. На одних и тех же отложенных задачах я бы прогнал один длинный reasoning-проход и стратегию «несколько кандидатов плюс проверка» на нескольких бюджетах, а затем сравнил успех на единицу расходов и на единицу полного времени, считая токены и задержку проверяющего частью стоимости: проверяющий, удваивающий задержку, может проиграть по сроку там, где выиграл бы по деньгам. Сэмплирование распараллеливается и потому часто укладывается в срок, который один длинный проход не выдерживает, но помогает лишь тогда, когда дешёвая проверка действительно различает кандидатов; иначе лишние кандидаты добавляют расход и не добавляют точности. Так как выигрыш зависит от сложности — он мал там, где уже справляется один проход или не справляется ничто, и максимален между ними, — я бы маршрутизировал по наблюдаемому признаку, доступному до появления ответа, а никогда по правильности. Дальше жёсткий предел по токенам и времени с описанным резервным сценарием и отчёт: расходы на успешную задачу и нарушения срока. Там, где ни одна стратегия не справляется ни при каком бюджете, дополнительные вычисления на инференсе уходят впустую, и рычагом становится более сильная модель.

Читать: Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters · Evaluation best practices

46. Где разместить cross-encoder reranker в поисковом пайплайне и когда выигрыш качества оправдывает задержку?¶

Знания · RAG и поиск · Чек-лист

Cross-encoder стоит после дешёвого поиска и до генерации: он оценивает пары «запрос — документ» для короткого списка, а не для всего корпуса. Он читает запрос и фрагмент вместе — именно это делает его точнее сравнения двух независимых эмбеддингов и одновременно слишком медленным, чтобы прогонять по всему. Потолок пайплайна поэтому задаёт полнота первой ступени: reranker не поднимет документ, которого не было в выдаче, поэтому полноту на глубине кандидатов я измеряю отдельно от итогового качества ответа, иначе промах первой ступени выглядит как ошибка reranker-а. Настройка — это перебор: число кандидатов и размер итогового контекста против качества на отложенных вопросах и полной задержки, с поиском точки, где новые кандидаты перестают менять верх списка. Выигрыш оправдывает задержку, когда узкое место действительно в релевантности; если ответы плохи потому, что факта нет в корпусе, переранжирование не даёт ничего.

Читать: Contextual Retrieval in AI Systems

47. Как связать каждое фактическое утверждение ответа с подтверждающим найденным фрагментом?¶

System design · RAG и поиск · Чек-лист

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

Читать: Patterns for Building LLM-based Systems & Products

48. Что MCP стандартизирует между AI-приложением и внешним сервисом сверх формата function call модели?¶

Знания · Агенты, инструменты и протоколы · Чек-лист

Формат function call описывает одно: форму аргументов, которые выдаёт модель. Он ничего не говорит о том, где живёт инструмент, как приложение узнаёт о его существовании и как возвращается результат. MCP стандартизирует именно этот окружающий слой — рукопожатие клиента и сервера, обнаружение возможностей и типизированные примитивы для инструментов, ресурсов и промптов поверх заданного транспорта, — поэтому один и тот же сервер работает с любым совместимым приложением в пределах возможностей, которые обе стороны объявили при рукопожатии, а инструмент добавляется без изменения модели и переразвёртывания клиента. Исполнение и полномочия остаются вне модели: приложение-хост по-прежнему решает, какие серверы подключены и что каждому разрешено. Пользу я бы оценивал тем, сколько интеграционного кода исчезает на каждый новый инструмент. Плата — возникающая граница доверия: подключённый сервер даёт и описания инструментов, и возвращаемый контент, а это попадает в контекст как недоверенный ввод, поэтому сторонний сервер — поверхность атаки и через цепочку поставок, и через prompt injection.

Читать: Model Context Protocol specification · Security Best Practices

49. Спроектируйте память агента, работающего в нескольких сессиях: что сохранять, извлекать, пересматривать и забывать?¶

System design · Агенты, инструменты и протоколы · Чек-лист

Я бы держал два хранилища с разным жизненным циклом: рабочий контекст сессии, который наполняется и выбрасывается, и долговременную память, куда попадает только подтверждённое — устойчивые предпочтения, решения с обоснованием, итоги задач. Главный выбор — что именно записывать. Я извлекаю факты уже при записи в структурированные записи — субъект, атрибут, значение, источник и время, — а не превращаю в эмбеддинги сырые транскрипты, потому что запись с ключом можно заместить, когда пользователь передумал, а два противоречащих друг другу куска транскрипта так и останутся оба доступными для поиска. Плата — потеря деталей, поэтому сырые эпизоды храню недолго как запасной источник, а не как память. Извлечение возвращает несколько записей, релевантных текущей задаче, а не всю историю: подмешивание всего воспроизвело бы ту самую проблему контекста. Забывание задаю явно: срок жизни для фактов, привязанных ко времени, замещение по ключу и удаление по запросу. Я бы прогнал многосессионные задачи с памятью и без неё и измерил долю успеха, долю извлечённых записей, которые реально использовались, и ошибки из-за устаревших записей. Граница: память, которую модель вывела сама, а не услышала, закрепляет её собственные ошибки, поэтому выводы получают пониженное доверие или не сохраняются вовсе.

Читать: Effective context engineering for AI agents

50. Когда разделение работы между агентами улучшает результат, а когда преобладают затраты на координацию?¶

Знания · Агенты, инструменты и протоколы · Чек-лист

Разделение помогает, когда работа действительно декомпозируется: подзадачи выполняются, не видя промежуточного состояния друг друга, а их результаты способен собрать шаг синтеза. Чистый случай — широкий поиск по множеству источников: широта параллельна, и каждая ветка независима. Помогать перестаёт там, где агенты обязаны согласовываться по ходу. Любая передача — это сжатие с потерями через естественный язык, поэтому общее изменяемое состояние даёт конфликтующие правки, повторную работу и противоречивые выводы, которые кому-то придётся сводить. Я бы задал границы делегирования и критерии готовности для каждого подагента, а синтез сделал отдельным шагом, который показывает расхождения, а не усредняет их. Честное сравнение — против одного агента с тем же общим бюджетом токенов, с подсчётом повторов работы, сбоев координации, стоимости и полного времени. Мультиагентность часто выигрывает по задержке и проигрывает по стоимости, а на последовательной по своей природе задаче накладные расходы координации — чистый убыток.

Читать: How we built our multi-agent research system

51. Как измерять неподтверждённые утверждения в работающем RAG-приложении, не принимая гладкий текст за правильный ответ?¶

System design · Оценка качества и наблюдаемость · Чек-лист

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

Читать: Your AI Product Needs Evals

52. Краткое объяснение reasoning-модели выглядит убедительно, но ответ следует ложной подсказке. Какие выводы должны сделать оценка и мониторинг?¶

Прикладной сценарий · Оценка качества и наблюдаемость · Чек-лист

Вывод в том, что объяснение не является свидетельством о вычислении. Убедительно читающееся резюме при ответе, который следует подброшенной подсказке, говорит о недостоверности самого отчёта, а не о том, что модель рассуждала верно и случайно ошиблась. Поэтому система должна оценивать наблюдаемое — итоговые ответы, вызовы инструментов, совершённые действия — независимо от связности изложения и никогда не повышать доверие к неверному результату из-за складного резюме. Диагностика, которую я бы построил, парная: прогнать одинаковые в остальном задачи с ложной подсказкой и без неё, а затем измерять отдельно две величины — как часто ответ смещается вслед за подсказкой и как часто объяснение признаёт её влияние. Большой разрыв между ними и есть сигнал недостоверности. В мониторинге трассы и резюме полезны как неполные подсказки для разбора. Они не окно в скрытые рассуждения, поэтому чистая трасса не является гарантией безопасности.

Читать: Reasoning Models Don't Always Say What They Think

53. Спроектируйте безопасный API доступа к моделям для разработчиков: аутентификация, квоты, потоковые ответы и обратная совместимость.¶

System design · Дизайн AI-систем · Чек-лист

Этот endpoint — контракт, на котором строят другие, поэтому каждое решение должно пережить клиентов, которых я не могу обновить. Аутентификация — по ключу с областями доступа и ротацией; квоты считают токены и параллельность, а не только число запросов, потому что два запроса могут различаться по стоимости в токенах на порядки, а длинный поток занимает мощность всё время генерации; отказ же возвращает остаток бюджета и подсказку о повторе, а не сухую ошибку. Потоку нужен свой контракт: инкрементальные события с идентификатором запроса, явное завершающее событие и описанное поведение при обрыве посреди ответа, поскольку усечённый ответ нельзя слепо повторять. Совместимость даёт аддитивность: новые необязательные поля, версионированные имена моделей, окна устаревания с телеметрией использования. Трудность в том, что поведение модели не версионируется так, как схема: одинаковые запросы со временем дрейфуют, поэтому обещание должно покрывать интерфейс и описанные лимиты, но никогда не идентичный вывод.

Читать: Scaling your API with rate limiters

54. Составьте сквозной бюджет задержки голосового агента от определения конца реплики до воспроизведения ответа.¶

System design · Мультимодальность и голос · Чек-лист

Бюджет я считаю до первого слышимого звука, потому что именно это воспринимается как отзывчивость, и перечисляю все этапы до него: определение конца реплики, финальную расшифровку, время модели до первого токена, накопление текста на первый синтезируемый фрагмент, сам синтез, сетевой транспорт и буферизацию у клиента. Наименее очевидное и часто одно из самых крупных слагаемых — определение конца реплики: ожидание тишины, чтобы убедиться, что человек закончил. Здесь прямой размен с перебиваниями: сократишь — агент говорит поверх людей, удлинишь — кажется медленным. Выносимой сумму делает потоковость: расшифровка, генерация и синтез перекрываются, а не выстраиваются в очередь, поэтому вклад каждого этапа я отслеживаю отдельно и задаю цель по медиане и по p95, ведь запоминается именно хвост. Бюджет должен выдерживать и нагрузку, поэтому я описываю и деградацию: короткий ответ, короткое подтверждение-заполнитель или более дешёвый голос, когда этап выбивается.

Читать: The Tail at Scale

55. Реализуйте минимальный агентный runner с проверяемой диспетчеризацией инструментов, обработкой ошибок и жёстким лимитом шагов.¶

Состояние цикла я бы сделал явным объектом: история сообщений, счётчик шагов, дедлайн, бюджет и причина остановки, — потому что именно состояние, спрятанное в управляющем потоке, делает runner трудным для остановки, тестирования и отладки. Каждая итерация спрашивает у модели одно действие, а вызов идёт через реестр: найти инструмент по имени, отвергнуть незарегистрированный, проверить аргументы по схеме и только затем вызвать. Неизвестный инструмент или неверный аргумент — не падение, а наблюдение, возвращённое модели, чтобы она исправилась; настоящие инфраструктурные сбои повторяются по ограниченной политике. Остановка должна достигаться с нескольких сторон — финальный ответ, предел шагов, дедлайн, бюджет, неустранимая ошибка, — и runner записывает, какая именно сработала. Я бы протестировал путь через предел и всегда падающий инструмент: агент, который не умеет останавливаться, и есть дорогая поломка. Одобрение значимых действий и сохранение состояния между перезапусками здесь сознательно не покрыты.

Читать: Building Effective AI Agents

56. Разграничьте time to first token, time per output token, inter-token latency и throughput при сравнении систем инференса.¶

Знания · Инференс, serving и стоимость · Чек-лист

Три из этих метрик описывают то, что чувствует один пользователь, а throughput — ёмкость системы, поэтому под нагрузкой они тянут в разные стороны. Time to first token — от поступления запроса до первого токена: ожидание в очереди плюс prefill, так что он растёт с длиной промпта и глубиной очереди. Time per output token — средний темп декодирования после этого: сквозное время минус TTFT, делённое на оставшиеся токены. Inter-token latency — тот же темп как распределение отдельных интервалов, и оно показывает остановки, которые прячет среднее, например когда планировщик берёт длинный prefill и все идущие декодирования замирают. Throughput — суммарные токены или запросы в секунду. Батч побольше поднимает throughput и замедляет декодирование для каждого пользователя, поэтому цифра пропускной способности ничего не значит без задержки, которой она куплена. Я бы сравнивал системы при одинаковой интенсивности запросов и одинаковых распределениях длин, показывал p50 и p99 по каждой метрике задержки, а throughput указывал как максимальную нагрузку, при которой цели по задержке ещё выполняются. Число токенов несопоставимо между токенизаторами, а офлайн-обработке батчами важны только throughput и стоимость.

Читать: vLLM documentation

57. Почему точный attention может работать быстрее без изменения квадратичного характера вычислений?¶

Знания · Основы LLM · Чек-лист

Потому что на GPU обычный attention упирается в обмен с памятью, а не в арифметику. Стандартное ядро пишет матрицу оценок N на N в HBM, читает её обратно ради softmax, записывает вероятности и снова читает их, чтобы умножить на V. FlashAttention режет Q, K и V на блоки, которые помещаются в SRAM на кристалле, и держит для каждой строки текущий максимум и сумму, то есть онлайн-softmax, пересчитывая частичный результат по мере прихода каждого блока ключей, так что полная матрица в HBM не попадает вовсе. FLOPs остаются квадратичными, обратный проход их даже добавляет, пересчитывая оценки по сохранённой статистике softmax вместо хранения матрицы, и всё равно выигрывает, потому что байтов передаётся намного меньше. Метод точный: от стандартного attention он отличается лишь порядком суммирования в плавающей точке, в отличие от разреженных или низкоранговых методов, меняющих само вычисление. Я бы измерял на реальных длинах, размерах голов, масках и типах данных на целевом GPU, проверяя совпадение в пределах допуска. На коротких последовательностях attention не узкое место, а при декодировании по одному токену стоимость attention — это чтение KV-кеша, и это уже другая задача.

Читать: FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness

58. Спроектируйте запросы на естественном языке к хранилищу с тысячами таблиц: от выбора схемы до безопасного исполнения.¶

System design · Дизайн AI-систем · Чек-лист

При тысячах таблиц трудность в выборе схемы, а не в написании SQL, а настоящий риск — запрос, который выполняется и возвращает неверное число. Поэтому я бы доставал из каталога небольшой набор кандидатов по описаниям таблиц и колонок, утверждённым определениям метрик, известным путям соединений и проверенным примерам запросов и генерировал по нему, предпочитая семантический слой, где метрики вроде выручки уже определены: сырые соединения провоцируют двойной счёт из-за размножения строк. Права — не забота модели: запрос выполняется только на чтение под собственной учётной записью пользователя в хранилище, так что действует защита на уровне строк и колонок, а перед этим парсер подтверждает, что это один SELECT по объектам из каталога, и задаются оценка стоимости, таймаут и лимит строк. На неоднозначность система отвечает уточняющим вопросом, а в ответе показывает SQL и свои допущения. Оценивал бы на реальных вопросах с проверенными запросами, сравнивая результирующие наборы, а не текст SQL, и отдельно мерил бы полноту выбора схемы: пропущенная таблица ограничивает всё дальнейшее. Где определения спорны или не задокументированы, генерация этого не исправит, и сначала нужны выверенные метрики.

Читать: OWASP Top 10 for LLM Applications · Spider 2.0: Evaluating Language Models on Real-World Enterprise Text-to-SQL Workflows

59. Клиент жалуется на худшие ответы после обновления модели. Как проверить регрессию и решить, что восстановить или изменить?¶

Прикладной сценарий · Оценка качества и наблюдаемость · Чек-лист

Жалоба — это зацепка, а не подтверждённая регрессия, поэтому начинал бы я с конкретных неудачных запросов клиента, а не с наших агрегированных eval, которые проблему не отметили. Сначала выяснил бы, что на самом деле изменилось: версия модели, но и параметры по умолчанию, системный промпт, схемы инструментов, выходные лимиты и retrieval — любое из этого может приехать вместе с обновлением. Затем прогнал бы те же входы на старой и новой конфигурации, зафиксировав всё остальное, по нескольку сэмплов на каждый, потому что ответы варьируются, и сравнил бы их попарно вслепую по критериям, которые клиент признаёт описанием сбоя. Если разрыв сохраняется, поискал бы похожие запросы в трафике, чтобы оценить масштаб. Исправление следует из причины: ошибку конфигурации чиним; промпт, подогнанный под особенности старой модели, адаптируем, часто вместе с клиентом; реальная потеря способностей на его срезе оправдывает закрепление прежней версии на ограниченный срок, пока готовится исправление. В любом случае эти кейсы попадают в критерии допуска релизов. Закрепление временное, потому что старые версии выводят из эксплуатации, а если парный прогон не показывает ничего сверх шума сэмплирования, регрессия не подтверждена.

Читать: Your AI Product Needs Evals

60. Как сделать действия агента в production обратимыми там, где это возможно, и проверяемыми там, где откат невозможен?¶

System design · Агенты, инструменты и протоколы · Чек-лист

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

Читать: Designing robust and predictable APIs with idempotency · Compensating Transaction pattern

61. Рассчитайте память полного bf16-дообучения модели 7B с Adam, затем для LoRA; явно задайте предположения об оптимизаторе.¶

Прикладной сценарий · Дообучение и post-training · Чек-лист

Сначала я бы назвал предположение о точности, потому что от него зависит итог. При весах и градиентах в bf16, мастер-копии в fp32 и двух моментах Adam в fp32 получается 2 плюс 2 плюс 12, то есть 16 байт на параметр: около 112 ГБ на 7 млрд параметров ещё без учёта активаций — именно так считает статья о ZeRO. Моменты или мастер-веса в меньшей точности меняют цифру, поэтому свой выбор надо назвать. LoRA убирает большую часть: замороженной базе нужны только её 2 байта на параметр, около 14 ГБ, без градиентов и состояния оптимизатора, а адаптеры на десятки миллионов параметров при умеренном ранге несут полные 16 байт и укладываются меньше чем в гигабайт. Чего LoRA не убирает, так это активаций: обратное распространение всё равно проходит через все замороженные слои, чтобы добраться до адаптеров, а память активаций растёт с батчем, длиной последовательности и глубиной, так что на длинном контексте может превысить веса. Активации я бы считал отдельно, при необходимости включил бы checkpointing, оставил запас аллокатору и подтвердил пиковую память на характерном батче с максимальной длиной.

Читать: ZeRO: Memory Optimizations Toward Training Trillion Parameter Models · LoRA: Low-Rank Adaptation of Large Language Models

62. Спроектируйте обучение модели, не помещающейся на одном ускорителе: как разделить состояние и ограничить стоимость коммуникаций?¶

System design · Дообучение и post-training · Чек-лист

Я бы начал с того, что именно не помещается, потому что у каждого вида состояния своё лечение. При Adam в смешанной точности параметры, градиенты и состояние оптимизатора стоят около 16 байт на параметр, а активации растут отдельно — с микробатчем, длиной последовательности и глубиной. ZeRO шардирует состояние модели между data-parallel рангами: первая стадия делит состояние оптимизатора, вторая добавляет градиенты, и обе обходятся примерно тем же обменом, что обычный data parallelism, потому что all-reduce превращается в reduce-scatter плюс all-gather; третья стадия шардирует и параметры, собирая каждый слой непосредственно перед использованием, и трафик вырастает примерно в полтора раза. Это деление состояния, а не вычислений. Если рабочий набор одного слоя всё равно не влезает, нужен tensor parallelism, который режет матричные умножения и обменивается данными внутри каждого слоя, поэтому его место на быстрых связях внутри узла; между узлами pipeline parallelism делит слои на стадии, которые обмениваются только активациями, и платит простоями. Для активаций — checkpointing. До масштабирования я бы измерил пиковую память на устройство, долю времени шага на обмен и пропускную способность на устройство от одного узла до целевого размера: на медленной сети сборки слоёв третьей стадии могут занять большую часть шага.

Читать: ZeRO: Memory Optimizations Toward Training Trillion Parameter Models

63. Объясните GRPO и компромиссы оценки advantage без обученной value model.¶

GRPO заменяет обучаемого критика из PPO самой группой ответов в роли baseline. На каждый промпт текущая политика генерирует группу ответов, их оценивают, и advantage каждого — это разность его награды и среднего по группе, делённая на стандартное отклонение группы; при награде за результат это значение получает каждый токен ответа. Обновление — clipped-цель PPO, а KL к опорной модели добавляется прямо в функцию потерь, а не вшивается в награду. Отказ от value model, обычно сопоставимой по размеру с политикой, экономит её память и обучение, но главная статья расходов остаётся: несколько генераций на промпт, вычисление наград, проходы опорной модели. Baseline шумный при маленьких группах, а если все ответы получили одинаковую награду, все advantage равны нулю и промпт не даёт градиента, кроме слагаемого KL; деление на крошечный разброс к тому же раздувает почти единогласные группы. Я бы логировал долю групп с нулевой дисперсией, фильтровал промпты по сложности и сравнивал успех на отложенных задачах, KL, длину ответов и устойчивость награды. Обучаемый критик окупается, когда вклад отдельных шагов нужно оценивать на длинных многошаговых траекториях.

Читать: DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models

64. Награда политики растёт, а людям ответы нравятся всё меньше. Как выявить и ограничить reward hacking?¶

Прикладной сценарий · Дообучение и post-training · Чек-лист

Растущая награда при падающем предпочтении людей — характерный признак переоптимизации: политика ушла туда, где ошибки reward model перевешивают её сигнал. Я бы подтвердил это слепыми сравнениями людьми на отложенных данных по нескольким checkpoint, сопоставив их с прокси-наградой и с KL от опорной политики, чтобы найти, где предпочтение людей было на пике. Затем посмотрел бы, за что награда стала платить: длина, уверенный тон, оформление, согласие с пользователем, — и проверил бы эти признаки напрямую на reward model. Быстрая мера — откатиться к пиковому checkpoint и перезапустить с более сильным KL-коэффициентом или меньшим числом шагов. Надёжная — покрытие: свежие предпочтения на ответах текущей политики, на которых reward model никогда не обучалась, и её повторное обучение. Gao, Schulman и Hilton наблюдали, как эталонная награда сначала растёт, а потом падает с удалением от исходной политики, но эталоном у них была синтетическая reward model, а не люди, поэтому форма кривой — гипотеза для проверки. Контроль KL и ранняя остановка ограничивают дрейф, но не делают прокси правильным.

Читать: Scaling Laws for Reward Model Overoptimization

65. Объясните использование принципов, самокоррекции и AI-предпочтений в Constitutional AI и сохранённую зависимость от человеческих решений.¶

Constitutional AI заменяет человеческую разметку вредности суждениями модели по записанным принципам, в два этапа. На этапе обучения с учителем полезная модель отвечает на вредные промпты, критикует свой ответ по принципу, взятому из конституции, и исправляет его, а затем модель дообучают на исправленных ответах. На этапе RL модель выдаёт пары ответов, модель обратной связи выбирает лучший по случайно взятому принципу, и на этих AI-предпочтениях учится модель предпочтений, которая служит наградой: это конвейер RLHF, где метки вредности ставит машина. Поэтому принципы определяют каждую критику, каждое сравнение и то, чему учится модель предпочтений. Человеческого остаётся много: люди написали и отобрали принципы, предпочтения по полезности в исходной работе по-прежнему размечали люди, стартовая модель обучена на человеческой обратной связи, а оценка — это сравнения людьми. Я бы измерял согласие AI-меток с человеческими на отложенных парах и следил за лишними отказами на безобидных запросах. Метод сокращает разметку, но не устраняет ценностный выбор, а переносит его в документ.

Читать: Constitutional AI: Harmlessness from AI Feedback

66. Объясните поиск через гипотетический документ и способ проверить пользу на вашем распределении запросов.¶

Знания · RAG и поиск · Чек-лист

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

Читать: Precise Zero-Shot Dense Retrieval without Relevance Labels

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

Прикладной сценарий · Практический кодинг · Чек-лист

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

Читать: Designing AI resistant technical evaluations · AI Interview Success: An Interviewer's Inside Guide

68. Команда связывает улучшение результатов с reasoning-моделью, но одновременно изменила промпты, инструменты и вычислительный бюджет. Как выяснить, что именно помогло?¶

Прикладной сценарий · Оценка качества и наблюдаемость · Чек-лист

Три изменения вышли одновременно, поэтому сравнение до и после по умолчанию приписывает модели их все. Я бы заморозил то, что не проверяется: набор задач, оценщика и среду инструментов, а ответы инструментов записал бы, чтобы живой API не дрейфовал между прогонами. Дальше менял бы по одному фактору плюс важные сочетания: старая модель с новыми промптом и инструментами, новая модель со старым промптом, обе модели при одинаковом бюджете вычислений. Полный перебор старых и новых версий модели, промпта, инструментов и бюджета — всего шестнадцать конфигураций. Reasoning-модели сильно реагируют на бюджет, так что сравнение без его выравнивания часто меряет лишние вычисления при инференсе, а не модель. В каждой ячейке нужны повторные прогоны, потому что пара пунктов у стохастической системы бывает шумом, и показывать стоит интервалы, сложные срезы и примеры ошибок, а не одно среднее. Отдельно я бы измерил рабочую систему в её реальных пределах цены и задержки: победитель при равном бюджете может оказаться не по карману. Если факторы сильно взаимодействуют, честный ответ — само сочетание.

Читать: Evaluation best practices · Scaling LLM Test-Time Compute Optimally can be More Effective than Scaling Model Parameters

69. Различите награду за результат, process supervision и проверку при инференсе. Какие данные обоснуют выбор каждого подхода для новой reasoning-задачи?¶

Знания · Оценка качества и наблюдаемость · Чек-лист

Первые два — обучающие сигналы, третий — нет. Награда за результат оценивает только итог, точный ответ или прошедшие тесты, как награды на основе правил в DeepSeek-R1, и обучение с подкреплением по ней меняет веса: это дёшево, когда есть проверка, но сигнал редкий, а правильный ответ, добытый неверными шагами, всё равно получает награду. Process supervision размечает отдельные шаги и обучает на них модель награды; Lightman и соавторы показали, что на математике она отбирает решения лучше, чем надзор по результату, ценой пошаговой разметки людьми. Проверка при инференсе веса не трогает: сэмплируем несколько кандидатов, выбирает проверяющий или голосование, а платим задержкой и токенами на каждом запросе. Одна и та же пошаговая модель награды может играть любую из этих ролей, так что различие в том, где применяется сигнал. Мне нужно знать, есть ли надёжная проверка итога, доступна ли и согласована ли пошаговая разметка и какова доля ложных принятий у проверяющего, потому что любое правило начнут эксплуатировать. Все три подхода я бы оценивал независимой проверкой итога на отложенных задачах и не переносил выводы с математики на процессы, где проверки нет.

Читать: DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning (v1) · Let's Verify Step by Step

70. Запрос к reasoning API расходует токены, но не возвращает пригодный ответ. Как найти причину и организовать восстановление с ограниченным бюджетом?¶

Прикладной сценарий · Инференс, serving и стоимость · Чек-лист

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

Читать: Reasoning models

71. Спланируйте продукт вместе с интервьюером, затем примерно за два часа соберите его с любыми AI-инструментами для программирования и защитите решения, код и путь в продакшен.¶

Прикладной сценарий · Практический кодинг · Чек-лист

Сначала я бы согласовал, что должен суметь пользователь, и показал минимальный полный сценарий, а не превращал лимит времени в цель по объёму кода. Разделил бы этот сценарий по ясным интерфейсам, дал помощнику только нужный контекст и проверки приёмки, а каждую правку изучил до интеграции. Основное внимание уделил бы модели данных, обработке ошибок и допущениям, которые могут сломать подход. В коротком журнале решений сохранил бы, что отверг и почему. На демонстрации показал бы обычный и отказной сценарии, затем объяснил, что измерено, что предполагается и что не закончено. Если зависимость или модель задерживает работу, сократил бы scope с сохранением главного сценария. Рабочий прототип подтверждает ограниченный результат; для production ещё нужны подходящие контроли доступа, эксплуатационные проверки и валидация. Эти пробелы следует назвать явно, даже если показ прошёл успешно.

Читать: The AI-native interview · AI Interview Success: An Interviewer's Inside Guide

72. Проверьте и доработайте черновой pull request коллеги со сквозной функцией в незнакомой кодовой базе, работая вместе с coding-агентами.¶

Прикладной сценарий · Практический кодинг · Чек-лист

Сначала я бы восстановил ожидаемое поведение и проследил точки входа, затронутые изменением. Резюме агента помогает ориентироваться, но перед доверием рекомендациям я сверил бы его с вызывающим кодом и инвариантами. Главный риск сквозной функции — непоследовательное применение: один endpoint проверяет права, а другой, кеш или фоновая задача обходят проверку. Я отделил бы наблюдаемые дефекты от гипотез и для каждого существенного опасения искал маленький контрпример. Решение ревью опиралось бы на поведение, показанное тестом или трассой, а не на уверенность помощника. Также проверил бы ошибки, повторы и общее состояние, отверг исправления, ослабляющие тесты или необоснованно расширяющие scope. Аккуратного diff недостаточно для одобрения, если критические пути не изучены: остаточную неопределённость нужно объяснить, а действительные ограничения AI на интервью соблюдать. Непроверенный совет не становится найденным багом только потому, что его сформулировала модель.

Читать: The AI-native interview · AI Interview Success: An Interviewer's Inside Guide · Demystifying evals for AI agents

73. В клоне репозитория продукта реализуйте структуру данных, которую продукт действительно использует; к AI обращайтесь только с точечными вопросами по синтаксису.¶

Я начал бы с вызывающего кода: какие операции нужны, как часто выполняются и какое поведение обещают существующие тесты. Представление определяется этим контрактом. Быстрого поиска недостаточно, если основную нагрузку дают обновления, порядок или сроки действия. Я задал бы инварианты, затраты времени и памяти, затем разобрал маленькие контрпримеры до окончательного выбора. Например, после обновления записи старое событие истечения не должно удалить её новую версию. Пустой вход, повторные ключи и граничное время полезны тем, что выявляют скрытые обычными примерами допущения. Я следовал бы соглашениям репозитория и ограничил помощь AI точечными вопросами синтаксиса, как требует описанная задача. Финальное объяснение связывает структуру с поведением продукта и называет изменение нагрузки, при котором её стоит заменить. Среднее константное время поиска само по себе не делает структуру универсально лучшей; нужно проверить стоимость остальных операций и поддержания согласованности.

Читать: Working Inside Existing Systems · collections: OrderedDict objects · Algorithms, fourth edition: Directed Graphs

74. На сессии с AI-кодингом объясните, какими моделями пользуетесь и почему, как следите за расходом токенов и как задаёте агенту контекст и задачу.¶

Прикладной сценарий · Практический кодинг · Чек-лист

Я выбирал бы среди разрешённых на сессии моделей по сложности задачи, наблюдаемой надёжности, задержке и оставшемуся бюджету. Универсального правила, какая именованная модель должна выполнять каждый шаг планирования или редактирования, нет. До делегирования я изучил бы нужный код и дал агенту ограниченную цель, интерфейсы, инварианты, исключения и конкретный критерий готовности. Текст репозитория и результаты инструментов — проверяемые сведения, а не полномочие менять ограничения. Я учитывал бы размер контекста, вывод и повторы: неудачные попытки способны занять основную часть времени и расходов. При отклонении вернулся бы к последнему проверенному состоянию и передал краткое резюме решений и открытых вопросов. Сброс контекста полезен лишь при сохранении существенного. Ответственность за принятие результата остаётся моей, и я остановил бы делегирование, если уже не могу надёжно проверить предлагаемую правку. Экономия токенов не оправдывает потерю необходимого контекста.

Читать: Effective context engineering for AI agents · AI Interview Success: An Interviewer's Inside Guide

75. Чем ответ по схеме отличается от function calling и какой компонент действительно исполняет действие?¶

Знания · Агенты, инструменты и протоколы · Чек-лист

Ответ с ограничением по схеме управляет формой данных, а вызов инструмента запрашивает операцию с аргументами. Ни один механизм сам не исполняет действие и не доказывает его разрешённость. До диспетчеризации приложение проверяет статус завершения, содержимое и предметные правила. Возможны отказ или усечение, а структурно правильный объект может содержать неверный счёт, выдуманный идентификатор основания или невозможную сумму. Я отделил бы исправимую ошибку формата от запрещённого действия, ограничил повторы и вернул явную ошибку после исчерпания восстановления. Для значимых операций права и нужное подтверждение остаются связанными с конкретными аргументами в коде приложения. Проверил бы не только неверный формат, но и внешне корректный запрос через границу арендаторов. Структурированная генерация сокращает ошибки разбора, но не устанавливает истинность, выполнение бизнес-правил или полномочия. Эти проверки не следует отдавать той же модели, которая предложила действие.

Читать: Tool use with Claude · Structured outputs

76. После долгой работы агент уверенно решает не ту задачу. Как найти момент расхождения состояния с целью и восстановить работу?¶

Прикладной сценарий · Агенты, инструменты и протоколы · Чек-лист

Я сравнил бы текущий план с последней проверенной целью, ограничениями и критериями завершения, затем нашёл первое решение, подменившее цель. Причиной может быть неоднозначная передача, устаревшая память, вводящий в заблуждение результат инструмента или инструкция в найденном содержимом. Просьбы к той же отклонившейся сессии постараться лучше недостаточно. Я сохранил бы полезную проверенную работу, отбросил неподтверждённые допущения и начал заново с краткого состояния, где разделены факты, решения и открытые вопросы. До повторения шагов нужно сверить уже произошедшие внешние эффекты. Для профилактики я проверял бы цель при существенных переходах, ограничивал бюджет и фиксировал причины остановки. Критерий — продвижение следующих действий к согласованному результату без нарушения ограничений. Сжатие помогает при нехватке контекста, но резюме, потерявшее важный запрет, само может стать причиной отклонения. Поэтому проверять нужно и содержание передачи, а не только её длину.

Читать: Effective context engineering for AI agents

77. Как для coding agent отделить вклад модели от вклада harness в надёжное завершение задачи?¶

System design · Агенты, инструменты и протоколы · Чек-лист

Я определил бы успех через поведение, проверяемое вне coding-агента, затем фиксировал задачи и бюджет, меняя модель и обвязку по отдельности. Обвязка включает сборку контекста, права инструментов, изоляцию исполнения, тесты, повторы и остановку; улучшение любого компонента может выглядеть как более умная модель. Я версионировал бы компоненты, повторял неопределённые кейсы и разбирал неудачные трассы вместо одного среднего pass rate. Если правка проходит из-за ослабления тестов агентом, это отказ обвязки: критерии приёмки нужно защитить от самой правки. И наоборот, сломанная зависимость или таймаут могут провалить хороший результат по причинам окружения. Эти категории и полную стоимость принятой задачи я показал бы отдельно. Сравнение выявляет вклад в проверенной конфигурации, но не устанавливает универсальный рейтинг для любых репозиториев и бюджетов. Заявление агента о готовности не заменяет независимую проверку результата.

Читать: Demystifying evals for AI agents

78. Как собрать полезный eval-набор без эталонных ответов и при дефиците экспертного времени?¶

Прикладной сценарий · Оценка качества и наблюдаемость · Чек-лист

Я начал бы с небольшого набора характерных запросов и классификации ошибок, затем тратил экспертное время там, где неверная оценка меняет продуктовый выбор. Не каждому кейсу нужен единственный эталонный ответ: часть проверяется по обязательным основаниям, запрещённым утверждениям, допустимым переходам состояния или правилу отказа. До автоматизации эксперты должны определить критерии и разобрать неоднозначные примеры. Я отделил бы случаи для разработки от отложенной проверки и сохранил происхождение и историю изменений. Синтетические кейсы полезны для границ, но не показывают частоту реальных пользовательских ошибок. Модель-судья помогает приоритизировать просмотр только после сравнения с человеческими метками; разногласие остаётся задачей для разбора. Вместо доказательства качества маленьким удобным набором я показал бы непокрытые области и неопределённость. Дополнительная разметка ценна, когда меняет решение, а не только увеличивает число; критические редкие ошибки следует рассматривать отдельно от среднего.

Читать: Your AI Product Needs Evals · Demystifying evals for AI agents

79. Как изменить оценку LLM-процесса при переходе от предложений к исполнению действий в production?¶

System design · Оценка качества и наблюдаемость · Чек-лист

Когда workflow исполняет действия, оценки убедительного совета недостаточно: нужно проверять итоговое состояние и разрешённость операции. Я проверял бы выбор инструмента, аргументы, полномочия, нужное подтверждение и последствия частичного отказа. Особенно важен таймаут после записи: повтор способен продублировать уже успешную операцию. Оценка должна сверять результат по идентичности операции и отличать безопасное восстановление от повторного эффекта. Для разрушительных кейсов я использовал бы изолированные синтетические сервисы и проверял границы арендаторов, отозванный доступ, исчерпанный бюджет и остановку. Высокая средняя успешность не компенсирует запрещённое действие, поэтому критические ошибки блокируют релиз отдельно. Логи связывают версии и внешние эффекты без ненужного чувствительного содержимого. Проверки дают свидетельства по покрытым сценариям, но не делают безопасным любое будущее действие модели. Новые полномочия или инструменты требуют пересмотра набора и границ, а не доверия прежнему общему баллу.

Читать: Demystifying evals for AI agents · OWASP Top 10 for LLM Applications

80. Как версионировать промпты и зависимые настройки для воспроизводимого отката обнаруженной регрессии?¶

System design · Оценка качества и наблюдаемость · Чек-лист

Я версионировал бы пакет релиза, а не только строку промпта: идентификатор модели, параметры генерации, схемы инструментов, поиск, нужная версия индекса и код приложения влияют на поведение. Каждая трасса указывает пакет, чтобы воспроизвести регрессию настолько точно, насколько позволяет провайдер. Я сравнил бы новый и прежний пакеты на отложенных кейсах, отдельно разобрал критические ошибки и определил триггер отката до rollout. Возврат трафика полезен лишь тогда, когда зависимости прежнего пакета ещё существуют и разрешены. Для изменения индекса может понадобиться сохранённая совместимая версия, а внешнее действие не отменяется восстановлением промпта. Поэтому откат конфигурации нужно отделить от сверки побочных эффектов. Эксплуатационная проверка — отрепетированное переключение и восстановление; идеальная воспроизводимость невозможна, если провайдер меняет незакреплённую модель или сервис. Эти ограничения я записал бы заранее и предусмотрел понятный отказ, если безопасного возврата уже нет.

Читать: Site Reliability Engineering

81. Спроектируйте извлечение структурированных полей из десяти миллионов сканов с возможностью проверки сомнительных результатов.¶

System design · Дизайн AI-систем · Чек-лист

Я разделил бы приём документов, извлечение, валидацию и ревью, чтобы неопределённые поля незаметно не становились доверенными записями. Нужны стабильные ID, версии и устойчивое состояние обработки; тогда workers повторяют ограниченные этапы без дублирования результатов. Каждое извлечённое поле сохраняет страницу или область источника и версию извлечения. Схема ловит неверный формат, а предметные проверки и выборочное экспертное ревью — правдоподобные ошибки. Порог confidence я калибровал бы на представительных документах, не предполагая одинаковый смысл оценки провайдера для любой формы. Неуверенные или значимые поля попадают в очередь с исходным свидетельством и историей исправлений. Планирование ёмкости учитывает эту очередь, а не только throughput модели. Я измерял бы ошибки полей, нагрузку ревью, задержку и стоимость по классам документов. Десять миллионов обработанных документов не означают успех, если редкие критические ошибки становятся невидимыми.

Читать: Interpret and improve model accuracy and confidence scores · Structured outputs

82. Спроектируйте непрерывное обновление индекса с изменениями, удалениями и запросами во время перестроения.¶

System design · RAG и поиск · Чек-лист

Я рассматривал бы индекс как версионированную проекцию источника со стабильными ID документов, порядком изменений и явными записями удаления. Инкрементальным workers нужны идемпотентные обновления и checkpoint, чтобы повтор не пропустил изменение и не воскресил удалённое содержимое. При пересборке я создал бы отдельный индекс, загрузил согласованный снимок, догнал последующие изменения и проверил количества, характерные запросы и права до переключения read alias. Атомарная смена alias помогает переключению, но сама не решает запоздавшие записи и отзыв доступа. Для них нужна отдельная политика распространения и проверки, включая кеши. Я наблюдал бы задержку от источника до поиска и проверял обновление, удаление и запрос во время перехода. Старый индекс пригоден для отката только тогда, когда удалённые или вновь ограниченные документы не становятся видимыми снова; свежесть относится и к полномочиям, и к содержимому.

Читать: Aliases · Document-level access control

83. За время долгой задачи контекст агента заполняется. Как вы решите, что остаётся в окне, что сворачивается в резюме, а что выносится наружу?¶

System design · Агенты, инструменты и протоколы · Чек-лист

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

Читать: Effective context engineering for AI agents · Lost in the Middle: How Language Models Use Long Contexts · RULER: What's the Real Context Size of Your Long-Context Language Models?

84. Несколько продуктовых команд работают через один внутренний AI-шлюз. Как сделать так, чтобы трафик, данные и кеши одной команды не влияли на другую?¶

System design · AI-платформа и операционная модель · Чек-лист

Я решаю вопрос изоляции по каждому общему ресурсу, а не один раз для шлюза целиком. Общие ресурсы — квота провайдера, мощность самого шлюза, кеши промптов и эмбеддингов, логи запросов и данные оценки. Каждый арендатор получает свои ключи, квоту и ограничение частоты, поэтому шторм повторов у одной команды ухудшает работу только этой команды; без персональных лимитов один инцидент съедает общую квоту. Кеши по умолчанию разделяются по арендаторам. Общий кеш префиксов не передаёт чужой текст, но попадание в кеш быстрее промаха, поэтому по времени ответа видно, встречался ли префикс раньше; там, где сами промпты чувствительны, этот канал стоит закрыть. В логах лежат промпты и ответы, поэтому доступ к трассировкам я ограничиваю арендатором и задаю срок хранения, а агрегированная телеметрия стоимости и задержек остаётся общей. Изоляцию проверяю нагрузкой на одного арендатора, наблюдая за остальными. Строгая изоляция стоит попаданий в кеш и денег; если все арендаторы — одно юридическое лицо с одной политикой данных, я скажу это прямо и ослаблю её осознанно.

Читать: Architect multitenant solutions on Azure · Prompt caching · Scaling your API with rate limiters

85. Провайдер объявил, что версия модели, от которой зависят ваши продукты, будет отключена через три месяца. Как вы проведёте переход во всех командах, которые её используют?¶

Прикладной сценарий · AI-платформа и операционная модель · Чек-лист

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

Читать: Managing technical lock-in in the cloud · Rules of Machine Learning

86. Задержка и доступность вашей AI-платформы зависят от внешнего провайдера моделей. Что вы пообещаете внутренним командам и как будете это обещание выполнять?¶

System design · AI-платформа и операционная модель · Чек-лист

Я обещаю сквозной показатель, который платформа действительно удержит, и формулирую его в том, что чувствует вызывающая сторона: задержка на высоком перцентиле и доля запросов, завершившихся с пользой, измеренные на нашей границе, а не взятые со страницы доступности провайдера. Доступность, которой я не управляю, обещанием быть не может, поэтому цель опирается на собственные механизмы: таймаут под срок вызывающей стороны, ограниченный бюджет повторов, меньшая резервная модель, упрощённый, но честный ответ и очередь для работы, которая может подождать. С повторами нужно быть осторожным: наивные повторы во время перегрузки провайдера добавляют нагрузку системе, которая уже отказывает. Резервный путь меняет качество ответа, поэтому у него должна быть своя оценка, а вызывающая сторона должна видеть, каким путём её обслужили. Я публикую бюджет ошибок, описываю, что происходит после его исчерпания, и прямо называю отказы, которые остаются вне моего контроля. Если команде нужна более сильная гарантия, ответ — второй провайдер или зарезервированная мощность, и то и другое стоит денег.

Читать: Site Reliability Engineering · Scaling your API with rate limiters

87. Перед запуском ассистента с доступом к инструментам: как вы организуете состязательное тестирование и что позволит утверждать чистый результат?¶

System design · Безопасность, защита и governance · Чек-лист

Я иду от ущерба, а не от приёмов, и от двух разных атакующих: пользователя, который пытается заставить продукт сделать недопустимое, и недоверенного текста, который читает модель, — страницы, документа, результата инструмента, — содержащего инструкции. Второй важнее, когда у ассистента есть инструменты: там ущерб — это действие, а не фраза. Покрытие даёт сочетание автоматической генерации множества вариантов с людьми, которые систему не строили, и запись всех попыток, а не только удачных: тогда набор можно прогнать на следующей версии и обсуждать покрытие предметно. Находки уходят названным владельцам вместе с исправлениями, и я отличаю заблокированный класс атак от одной формулировки, которая перестала срабатывать. Честное итоговое утверждение узкое: атаки, которые мы пробовали, на этой версии в основном не прошли. Это не доказательство безопасности — полного решения против внедрения инструкций сегодня нет, — поэтому оно должно опираться на минимальные права и подтверждение значимых действий.

Читать: OWASP Top 10 for LLM Applications · AI Risk Management Framework · Prompt injection (series)