RAG — чтобы находить. Полный контекст — чтобы решать..

Совет 2026 года устоялся: разбей документы на чанки, сделай эмбеддинги, доставай top-k, отдавай их модели. Не трать контекст. Не трать токены.

Я построил систему, которая намеренно не делает ничего из этого. Каждый запрос получает всё резюме эксперта целиком — 69 проектов, публикации, образование, языки. Примерно 34 000 символов, полностью, каждый раз.

Вот логика, потому что это была не лень.

Задача определяет архитектуру

Система ищет тендеры ООН для одного конкретного эксперта. Каждый день она обходит 28 источников, нормализует и дедуплицирует тысячи закупочных объявлений, а затем отвечает на один вопрос по каждому тендеру: подходит ли этот человек?

Похоже на retrieval. Но это не он. Это исключение.

• Retrieval спрашивает: что в этом корпусе наиболее похоже на запрос?
• Исключение спрашивает: есть ли здесь что-то, что дисквалифицирует?

Это противоположные операции. Первая хочет самые сильные совпадения. Второй нужно самое слабое звено — а оно по определению наименее похоже на всё остальное.

Почему похожесть подвела бы

Реальный паттерн из данных.

Тендер называется Public Financial Management. У эксперта дюжина проектов по публичным финансам. Косинусная близость между тендером и профилем: очень высокая.

# what a RAG pipeline does here
chunks = retrieve(query=tender.description, corpus=cv_chunks, k=3)
# returns: finance_project_2019, finance_project_2021, education_economics
# verdict: strong match

Тендер — на эколога. Об этом сказано один раз, на пятой странице, в разделе обязанностей.

Или: роль подходит идеально, но требует национального консультанта с обязательным местным языком. Одно предложение, зарытое в требованиях.

Дисквалифицирующая деталь никогда не бывает семантически самым близким фрагментом. Именно это и делает её дисквалифицирующей — это часть, которая не вписывается в паттерн. Retrieval-система оптимизирована на то, чтобы её не показать.

Что уничтожает чанкинг

Разбей резюме на чанки — и ты сохранишь факты, но потеряешь форму.

Достань три чанка про публичные финансы — и модель видит эксперта по публичным финансам. Отправь все 69 проектов — и модель видит, в каких странах он реально работал, какими языками реально владеет, на каком уровне seniority работает и — что важнее всего — чего он никогда не делал.

Отсутствие — это информация. А отсутствие невозможно достать через retrieval. Нет чанка, который говорит «у этого человека нет опыта в экологии». Ты узнаёшь это, только прочитав всё и заметив, что ничего такого нет.

RAG может сказать тебе, что есть в документе. Он не может сказать, чего в нём нет.

Экономика, которой меня учили бояться

34 000 символов — это примерно 9 000 токенов контекста на одно суждение. Помножь на сотни тендеров в день, и это якобы дорогая ошибка.

Не дорогая. ИИ и прокси вместе обходятся в несколько долларов в месяц.

Две причины:

1. Предфильтр делает дешёвую работу первым. Стоп-слова, тема, территория, язык, дедлайн, просрочено — всё в коде, без вызовов модели. ИИ видит только кандидатов, переживших правила.

# rules run first, model runs last
candidates = [t for t in tenders if passes_rules(t)]   # cheap
verdicts   = [judge_with_full_cv(t) for t in candidates] # expensive, but few

2. Резюме побайтово одинаково на каждом вызове. Один и тот же префикс снова и снова — идеальная форма для prompt caching.

Панель отслеживает стоимость прогона и стоимость одного найденного тендера, так что это не догадка. Я слежу за цифрой.

Обобщаемый урок: стоимость токенов — реальное ограничение, но его люди применяют по памяти, а не по замеру. Цены сдвинулись. Большинство RAG-пайплайнов, что я вижу, спроектированы под экономику, которой больше нет.

Что возвращает модель

Не прозу. Структурированный вердикт, логируемый целиком:

{
  "fits": false,
  "short_reason": "requires national consultant, local language mandatory",
  "long_reason": "The role matches the expert's PFM background, but eligibility restricts applicants to nationals with working Portuguese...",
  "country": "Mozambique",
  "tor_attached": true
}

Она судит суть роли, а не её название. В этом весь смысл.

Когда я использую RAG — и использую

Это не аргумент против RAG. Это аргумент против того, чтобы включать его по умолчанию.

RAG уместен, когда:

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

На других проектах я использую RAG именно по этим причинам. Другая задача, другая форма, другой ответ.

Честная оговорка с моей стороны: длинный контекст тоже не без проблем. Модели менее надёжно удерживают середину длинного промпта, чем его начало и конец. 34 тыс. символов комфортно помещаются в то, с чем нынешние модели справляются хорошо. На 300 тыс. разговор был бы другим, и я, скорее всего, строил бы гибрид.

Правило, к которому я пришёл

Спроси, что модель должна сделать с документом.

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

Большинство бизнес-задач, в которые люди вшивают RAG, — это задачи суждения, переодетые в костюм retrieval. Подходит ли этот кандидат. Рискован ли этот контракт. Стоит ли участвовать в этом тендере. В каждой из них ответ решает деталь, которую никто бы не достал.

Что почитать ещё

• Полная система тендеров: 28 источников, 17 коннекторов, самочинящиеся парсеры
• ИИ и автоматизация