Что такое контекст-инжиниринг — и почему он важнее промпта

Пару лет все учились «писать промпты». Как сформулировать фразу поэлегантнее, чтобы модель поняла.

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

Промпт — это одна фраза. Контекст — вся картина

Представь, ты задаёшь коллеге вопрос.

Промпт — это сам вопрос. Как ты его сформулировал.

Контекст — это всё, что коллега знает в этот момент. Кто ты, над чем вы работаете, что было вчера, какие файлы у него на столе. С одним и тем же вопросом, но разным фоном, ответ будет совсем разный.

Так вот. Контекст-инжиниринг — это забота о том фоне, а не о самой фразе. Ты решаешь, что положить модели «на стол» перед ответом.

Что попадает в контекст

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

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

Контекст-инжиниринг — это искусство собрать этот набор так, чтобы нужное было внутри, а лишнего не было. Потому что окно не резиновое: всё это занимает токены, и за них ты платишь.

Почему модель «тупит»: дело часто не в промпте

Классика. Ты пишешь идеальную фразу, а ответ — мимо. И начинаешь переписывать промпт в десятый раз.

А проблема сплошь и рядом в другом:

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

Ни одну из этих бед не лечит красивая формулировка. Лечит их работа с контекстом: что показать, что убрать, что подтянуть в нужный момент.

Что с этим делать новичку

Тебе не нужно строить сложные системы. Достаточно поменять привычку.

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

• Нужен твой код? Вставь именно тот кусок, а не «где-то в проекте».
• Разговор длинный и она путается? Начни заново и дай только суть.
• Нужны свежие факты? Дай их прямо в сообщении — из головы модель их не возьмёт.

Это и есть контекст-инжиниринг на бытовом уровне. Не магия — просто следишь, что лежит у модели «на столе». Хорошая формулировка (как написать промпт) всё ещё важна. Но она — один кубик внутри контекста, а не весь ответ на вопрос «почему не работает».

Промпт-инжиниринг больше не нужен?

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

Контекст-инжиниринг — это то же самое, что RAG?

Нет, RAG — это один из приёмов внутри. RAG подтягивает нужные куски из твоих документов и кладёт их в контекст. А контекст-инжиниринг шире: это и память, и примеры, и инструкция, и бюджет токенов — вся сборка целиком, а не только «достать документ».