Этап 1 — Как LLM работает и зачем нужен prompt engineering
Prompt engineering — это не набор «волшебных фраз». Это способ ясно передать модели задачу, контекст, ограничения и ожидаемый формат ответа. Если пользователь пишет только «объясни Docker», модель вынуждена угадывать уровень читателя, цель, глубину, формат и критерии качества. Иногда она угадает, иногда нет. Хороший prompt уменьшает количество угадывания.
LLM, или large language model, — это модель, которая генерирует текст по видимому контексту. Она не «думает» как человек и не проверяет каждый факт в интернете по умолчанию. Модель получает входной текст, разбивает его на токены и по вероятностям выбирает следующий токен. Затем следующий, затем следующий. Из этой последовательности и получается ответ.
Что такое токены и контекст
Токен — это небольшой фрагмент текста. Иногда токен похож на слово, иногда на часть слова, знак препинания или пробел. Модель работает не с «человеческими словами» напрямую, а с последовательностью токенов. Поэтому важен не только смысл, но и то, сколько текста помещается в context window.
Context window — это видимая рабочая область модели: system instructions, пользовательский запрос, история диалога, вставленные документы и предыдущие ответы. Модель отвечает только на основе того, что находится в этом окне, плюс своих обученных паттернов. Если нужного факта нет в контексте, модель может попытаться достроить вероятный ответ. Именно здесь появляются галлюцинации.
Длинный prompt не всегда лучше короткого. Если в контексте много случайных деталей, противоречий и старых решений, модель может потерять фокус. Хороший контекст не максимальный по размеру, а отобранный: только то, что нужно для текущей задачи.
Почему модель может ошибаться уверенно
Галлюцинация — это ответ, который звучит правдоподобно, но не опирается на надёжный факт в контексте или источниках. Модель не обязательно «знает», что не знает. Если prompt требует уверенный ответ и не говорит, что делать при недостатке данных, модель часто продолжает генерировать наиболее вероятный текст.
Чтобы снизить риск, нужно явно задавать поведение при неопределённости: «если данных недостаточно, скажи, чего не хватает», «не выдумывай источники», «отделяй факт от предположения». Для задач с высокой точностью полезно давать документы, ссылки, таблицы или проверяемые входные данные.
Из чего состоит хороший prompt
Практический prompt похож на небольшой контракт. Он говорит модели, что сделать, для кого, на каком материале, с какими ограничениями и в каком виде вернуть результат. Чем яснее контракт, тем меньше модель выбирает случайно.
| Часть prompt-а | Что объясняет | Пример |
|---|---|---|
| Задача | Что нужно сделать | «Объясни тему новичку» |
| Аудитория | Для кого ответ | «Человек знает Java, но не знает Spring» |
| Контекст | На каких фактах работать | «Используй этот фрагмент документации» |
| Ограничения | Чего нельзя или что важно | «Не используй списки как основное объяснение» |
| Формат | Как вернуть результат | «Markdown, 3 раздела, таблица и пример» |
Например, плохой prompt: «расскажи про JWT». Лучше: «Объясни JWT начинающему backend-разработчику. Сначала объясни token, header, payload, signature. Потом покажи, где token отправляется в HTTP request. Не сравнивай с OAuth глубоко. Верни ответ с таблицей и коротким примером Authorization header». Второй prompt не делает модель умнее, но делает задачу понятнее.
Temperature и top-p
Параметры генерации управляют свободой ответа. temperature влияет на случайность выбора токенов. Низкое значение делает ответы стабильнее и консервативнее. Высокое значение может дать больше вариантов и креативности, но также повышает риск нестабильности. top-p ограничивает выбор набором наиболее вероятных токенов.
Для production-задач, где важны точность и повторяемость, обычно нужны строгий prompt, низкая или умеренная temperature и фиксированный формат. Для brainstorming можно дать модели больше свободы, но итог всё равно нужно проверять.
Роли system, user и assistant
В chat-модели сообщения имеют роли. system задаёт высокоуровневые правила поведения: стиль, безопасность, ограничения продукта. user содержит конкретную задачу. assistant — это ответы модели. Если в истории есть конфликт, более приоритетные инструкции должны управлять поведением.
Например, system может говорить: «отвечай кратко и не выдумывай факты». User может попросить: «придумай ссылку на исследование». Модель должна следовать system-ограничению и не создавать фальшивую ссылку.
Практический пример
Допустим, нужно получить объяснение Redis для junior-разработчика. Слабый запрос «что такое Redis» может дать слишком широкий ответ. Управляемый prompt будет таким:
Объясни Redis junior backend-разработчику.
Сначала объясни, что такое key-value storage и in-memory хранение.
Затем покажи 3 типичных сценария: cache, session storage, rate limiting.
Не уходи в кластеризацию.
Формат: короткое введение, таблица, один пример на псевдокоде.
Если термин требует пояснения, объясни его перед использованием.
Такой prompt заранее задаёт уровень, границы, структуру и запрет на лишнюю глубину. Ответ станет более полезным не потому, что модель «поняла мир», а потому что задача стала инженерно определённой.
Итог этапа
LLM генерирует следующий токен по контексту и вероятностям. Prompt engineering нужен, чтобы управлять этим процессом: задавать цель, аудиторию, контекст, ограничения и формат. Хороший prompt не гарантирует абсолютную правду, но снижает неопределённость, уменьшает галлюцинации и делает результат пригодным для работы.
Чек-лист понимания
- Могу объяснить, что LLM генерирует текст токен за токеном.
- Понимаю, что context window ограничивает видимые данные.
- Понимаю, почему модель может звучать уверенно и ошибаться.
- Могу собрать prompt из задачи, аудитории, контекста, ограничений и формата.
- Понимаю, когда уменьшать свободу модели через настройки и строгий формат.