LLM за 20 минут: что тестировщику нужно понимать

Коротко

• Тестировщику не нужно знать, как обучают модель. Нужно понимать семь понятий: токены, контекст, эмбеддинги, выбор следующего слова, галлюцинации, RAG и агенты. Из них следуют почти все дефекты LLM-систем.
• Модель видит текст как токены и знает только то, что лежит в её контексте прямо сейчас. Всё, что не влезло в контекст, для неё не существует.
• Ответ выбирается с долей случайности, поэтому один прогон ничего не доказывает. Галлюцинации появляются потому, что модель пишет правдоподобный текст и не сверяет его с фактами.
• После каждого понятия есть абзац «что это значит для тестов». Если времени мало, читайте только их.

Токены: в чём модель измеряет текст

Модель работает с токенами, фрагментами текста. Токен бывает целым словом, частью слова или знаком препинания. Слово «возврат» может оказаться одним токеном или тремя, это зависит от токенизатора конкретной модели. Русский текст обычно дробится на токены сильнее английского, поэтому одна и та же фраза по-русски часто стоит дороже.

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

Ещё одно следствие: модель не видит отдельных букв. Отсюда известные ошибки в задачах вроде «сколько букв „р“ в слове». Это особенность устройства, и по ней не стоит судить о качестве модели в целом.

Что это значит для тестов:

• проверяйте длину ответа: «вода» стоит денег и времени;
• считайте токены по полю usage в ответе API или токенизатором модели, а не на глаз;
• не делайте выводов о качестве по задачам на буквы и символы, если продукт не про них.

Контекст: всё, что модель знает в момент ответа

Контекст — это весь текст, который модель получает в одном запросе: системный промпт (инструкции от разработчиков), история диалога, найденные документы, результаты инструментов и вопрос пользователя. Модель не помнит прошлых разговоров. Вся «память» ассистента состоит из того, что приложение положило в контекст в этот раз.

У контекста есть лимит в токенах. Если текст не влез, приложение или сервер обрезают его, обычно без всякой ошибки. Пример из локального запуска: Ollama по умолчанию даёт модели окно в 4 тысячи токенов, если видеопамяти меньше 24 ГБ (документация Ollama). Длинный документ в таком окне просто потеряет часть текста.

Даже то, что влезло, модель использует неравномерно. Информацию в начале и в конце длинного контекста она использует лучше, чем в середине. Этот эффект называют lost in the middle.

Что это значит для тестов:

• держите в датасете вопросы, ответ на которые лежит в конце длинного документа или в середине длинной истории диалога;
• проверяйте длинные диалоги: помнит ли ассистент на десятом сообщении то, что пользователь сказал в первом;
• проверяйте конфликт инструкций: системный промпт говорит одно, документ в контексте другое. На этом конфликте строится prompt injection, о нём разбор про непрямую инъекцию через документы RAG.

Эмбеддинги: смысл текста в виде чисел

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

На эмбеддингах работает поиск по смыслу. Пользователь спрашивает «можно ли сдать кроссовки», а в правилах написано «возврат обуви»: общих слов нет, но векторы близки, и нужный фрагмент находится.

У этого есть обратная сторона. Эмбеддинги хорошо ловят тему и хуже различают детали: числа, отрицания, названия продуктов. Фразы «возврат в течение 30 дней» и «возврат в течение 14 дней» могут оказаться очень близкими, хотя для покупателя это разные ответы.

Что это значит для тестов:

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

Как модель выбирает слова: temperature и случайность

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

Параметр	Что делает	Практический вывод
temperature	при 0 выбирается самый вероятный токен, чем выше, тем распределение «площе» и ответы разнообразнее	для тестов на факты начинайте с 0
top-p	оставляет только самые вероятные токены с суммарной вероятностью p	меняйте один параметр за раз
top-k	оставляет k самых вероятных токенов	поддерживается не везде
max tokens	потолок длины ответа	слишком малый обрежет ответ посреди фразы
seed	фиксирует случайность, если провайдер это поддерживает	полной воспроизводимости обычно нет

Даже при temperature 0 ответы у многих провайдеров немного различаются от запуска к запуску: влияют вычисления на видеокартах, обработка запросов пачками и обновления модели. А ещё значения по умолчанию отличаются у разных API. Например, OpenAI-совместимый слой Ollama ставит temperature 1.0, если вы её не передали (исходный код).

Что это значит для тестов:

• один прогон не доказывает ничего. Задавайте важный вопрос несколько раз и считайте долю верных ответов;
• записывайте в баг-репорт модель, её версию и все параметры генерации, иначе баг не воспроизвести;
• всегда передавайте temperature явно, не полагайтесь на значения по умолчанию;
• разницу в формулировках дефектом не считайте. Дефект — это разница в фактах.

Посмотреть на эту случайность своими глазами можно в третьей части: там pytest задаёт модели один вопрос 10 раз.

Почему модель выдумывает

Модель обучена продолжать текст правдоподобно. Знания, которые попали в неё при обучении, она хранит неточно, а проверять сказанное ей не на чем. Когда вопрос касается факта, которого она не знает или которого нет в контексте, она всё равно пишет связный уверенный ответ. Такой ответ и называют галлюцинацией.

Типичные виды:

• выдуманные факты, цифры, ссылки, названия статей закона и пунктов договора;
• правильный ответ с «додуманной» деталью, которой нет в источнике;
• уверенный ответ там, где правильно сказать «не знаю» или задать уточняющий вопрос.

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

Что это значит для тестов:

• в датасете обязательно должны быть вопросы, ответа на которые нет в базе. Ожидаемое поведение: отказ или уточнение;
• проверяйте ответ по источнику: каждое утверждение ответа должно подтверждаться документом. На этом построена метрика Faithfulness, о ней в разборе 4 метрики RAG;
• уверенный тон ответа ничего не говорит о его правильности.

RAG одной картинкой

RAG (retrieval-augmented generation) — схема, в которой модель отвечает по найденным документам, а не по памяти:

вопрос пользователя
      │
      ▼
 [retriever] ── ищет по базе документов (эмбеддинги, ключевые слова)
      │
      ▼
 найденные фрагменты (top-k)
      │
      ▼
 [сборка промпта] = инструкции + фрагменты + вопрос
      │
      ▼
 [LLM] ── пишет ответ по фрагментам
      │
      ▼
 ответ (иногда со ссылками на источники)

Retriever — компонент, который ищет фрагменты документов (чанки). Top-k — сколько лучших фрагментов он отдаёт модели.

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

Агент одной картинкой

Агент — это LLM, которая может вызывать инструменты (API, поиск, базу данных) и сама решает, что делать дальше:

задача пользователя
      │
      ▼
 ┌─► [LLM думает] ── нужен инструмент?
 │        │ да                     │ нет
 │        ▼                        ▼
 │   [вызов инструмента]      финальный ответ
 │   check_order(id=123)
 │        │
 └── результат инструмента

Цикл «подумал, вызвал инструмент, получил результат» повторяется, пока модель не решит, что задача выполнена. MCP (Model Context Protocol) — стандартный способ подключать инструменты к агентам.

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

Что дальше

• Следующая часть: первый автотест для LLM за вечер на pytest и Ollama. Поставите модель и проверите на практике всё, о чём здесь шла речь.
• Если вы пропустили начало серии: кто такой AI QA-инженер и чем он отличается от обычного тестировщика.
• Возьмите любой ассистент, с которым работаете, и нарисуйте его схему, как выше. Отметьте на ней, где может сломаться каждый из семи пунктов этой статьи.