Нет глупых вопросов: что такое узкое место ИИ и как контекстная инженерия его исправляет?

Введение

Каждый, кто работал с современными языковыми моделями (LLM), сталкивался с парадоксом: модель может написать эссе, объяснить квантовую физику и даже сгенерировать код, но «забывает» то, что вы сказали пятью сообщениями ранее. Это не баг — это фундаментальное ограничение, которое называют AI bottleneck (узкое место ИИ).

По мере того как компании внедряют LLM в реальные бизнес-процессы — анализ контрактов, обработка тысяч страниц техдокументации, диалоговые ассистенты — проблема ограниченного контекста становится критической. И здесь на помощь приходит контекстная инженерия (Context Engineering) — набор методов, позволяющих «скормить» модели ровно те данные, которые нужны, и в нужном объёме.

В этой статье разберём, почему контекст — главный ресурс в работе с ИИ, как и почему он становится узким местом, и какие практические техники контекстной инженерии помогают это исправить.

Часть 1. Что такое AI bottleneck?

Термин AI bottleneck (буквально «бутылочное горлышко ИИ») обозначает любое ограничение, которое препятствует масштабированию или качеству работы модели. В контексте LLM главный бутыль — контекстное окно.

Как работает контекстное окно?

Современные модели (GPT-4, Claude 3.5, Gemini) обрабатывают текст блоками — токенами. Их количество в одном сеансе строго ограничено. Например, GPT-4 Turbo — 128K токенов, Claude 3 Opus — 200K. Кажется, что это много, но для промышленных задач этого часто не хватает:

• Анализ годового отчёта компании (300 страниц) — около 150K токенов.
• Многошаговое рассуждение с 100+ вложениями (RAG) — каждый фрагмент занимает место.
• Диалог из 50 реплик с длинными инструкциями — модель начинает «забывать» первые указания.

Почему контекст — узкое место?

1. Квадратичная сложность внимания — механизм self-attention растёт как O(n²) по длине входа. Чем длиннее контекст, тем дороже вычисления. Даже при 128K токенов latency и стоимость становятся неприемлемыми для реального времени.
2. Забывание середины — исследования (например, работа "Lost in the Middle" от Google AI) показывают, что модели лучше всего помнят начало и конец промпта, а информация в середине часто игнорируется.
3. Стоимость — API многих моделей берут плату за каждый токен ввода. При контексте 100K токенов один запрос может стоить $1-2. Для тиражирования это недёшево.

Пример из практики: Ассистент техподдержки обрабатывает историю чата (50 сообщений) и базу знаний (30K токенов). Модель начинает отвечать шаблонно или игнорировать данные, потому что полезная информация «выпала» из контекста.

Часть 2. Как контекстная инженерия исправляет bottleneck?

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

Основные техники

Как это работает на практике?

Рассмотрим типовой сценарий: юридический анализ договоров. У нас 50 документов по 20 страниц каждый. Вместо того чтобы передать модели все 1000 страниц, применяем:

1. Chunking: каждый документ разбиваем на фрагменты по 1000 символов с перекрытием 100 символов.
2. Векторизация: каждый чанк превращаем в эмбеддинг (например, text-embedding-3-small) и сохраняем в векторной базе (Chroma, Pinecone, Qdrant).
3. RAG-запрос: пользователь задаёт вопрос «Какие штрафные санкции за просрочку?» — модель преобразует его в эмбеддинг и ищет 5 ближайших чанков.
4. Формирование контекста: в промпт вставляются только эти 5 чанков + инструкция. Размер контекста — ~2K токенов, а не 500K.
5. Генерация ответа: модель отвечает, опираясь на узкий, но релевантный контекст.

Часть 3. Пример кода: реализация RAG с контекстной инженерией

Ниже — упрощённая реализация на Python с использованием LangChain и Chroma. Этот код можно адаптировать для любого проекта на asibiont.com.

from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import OpenAIEmbeddings
from langchain.vectorstores import Chroma
from langchain.chains import RetrievalQA
from langchain.llms import OpenAI

# 1. Загрузка документа (например, контракт в TXT)
with open("contract.txt", "r") as f:
    text = f.read()

# 2. Chunking: разбиваем на части по 1000 символов
splitter = RecursiveCharacterTextSplitter(
    chunk_size=1000,
    chunk_overlap=200,
    separators=["\n\n", "\n", " ", ""]
)
chunks = splitter.split_text(text)

# 3. Создаём эмбеддинги и сохраняем в Chroma
embeddings = OpenAIEmbeddings()
vectorstore = Chroma.from_texts(chunks, embeddings, persist_directory="./chroma_db")
retriever = vectorstore.as_retriever(search_kwargs={"k": 5})

# 4. RAG-цепочка
qa_chain = RetrievalQA.from_chain_type(
    llm=OpenAI(temperature=0),
    chain_type="stuff",
    retriever=retriever
)

# 5. Задаём вопрос
question = "Какие штрафы предусмотрены за задержку поставки?"
answer = qa_chain.run(question)
print(answer)

Что здесь происходит?
- chunk_size=1000 — каждый фрагмент не превышает 1000 символов, что быстрее и дешевле.
- chunk_overlap=200 — сохраняем контекст на границах.
- k=5 — в контекст попадает только 5 самых релевантных чанков.

Совет: настраивайте размер чанка под задачу. Для точного поиска фактов — 300-500 символов, для суммаризации — 1500-2000.

Часть 4. Продвинутые приёмы контекстной инженерии

4.1 Динамическое контекстное окно для чат-ассистентов

В долгих диалогах используйте суммаризацию старой части истории и заменяйте её кратким содержанием.

# Псевдокод: суммаризация после каждых 10 оборотов
if len(history) > 10:
    summary_prompt = f"Суммаризируй этот диалог в 3 предложения: {history[:-5]}"
    summary = llm(summary_prompt)
    history = [summary] + history[-5:]  # заменить старую часть

4.2 Prompt Compression с LLMLingua

Библиотека LLMLingua (Microsoft Research) сжимает промпт на 40-60% без существенной потери точности. Интеграция проста:

pip install llmlingua

from llmlingua import PromptCompressor
compressor = PromptCompressor()
compressed_prompt = compressor.compress(prompt, rate=0.5)

4.3 Иерархическая суммаризация для больших корпусов

Если нужно «скормить» модели книгу (500K токенов), разбейте её на главы, каждую суммаризируйте отдельно, затем объедините в итоговую сводку. При запросе к модели передавайте только эту сводку.

Часть 5. Когда контекстная инженерия не нужна?

Несмотря на эффективность, контекстная инженерия не панацея. Избегайте её, если:
- Задача требует целостного понимания всего документа (например, поиск противоречий в разных частях).
- Вы имеете дело с короткими промптами (менее 2K токенов) — оверхед настройки RAG не оправдан.
- У вас высокие требования к latency — добавление шага ретрива увеличивает время запроса на 0.5-2 секунды.

В таких случаях используйте модели с длинным контекстом (Gemini 2.0 — 1M токенов, Claude 3.5 — 200K) без дополнительной обвязки, но помните о стоимости.

Заключение

AI bottleneck — это не столько ограничение длины контекста, сколько неумение правильно им распорядиться. Контекстная инженерия превращает «сырую» информацию в структурированные, компактные и релевантные данные, которые модель способна эффективно обработать.

Главные выводы:
- Контекстное окно — дефицитный ресурс, и каждый токен на счету.
- Chunking + RAG — минимальный набор для решения проблем с объёмом.
- Динамическое окно и сжатие промпта помогают в долгих диалогах.
- Инструменты вроде LangChain, LLMLingua и векторных баз данных делают контекстную инженерию доступной для любого разработчика.

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