Чат-бот, отвечающий на вопросы по вашим PDF-файлам, создаётся за один вечер. Система, которая делает это надёжно, с предсказуемой стоимостью, для пользователей, задающих вопросы так, как вы не предполагали, — требует месяцев. Разрыв между этими двумя результатами — не секретная библиотека и не хитрый промпт. Это набор инженерных решений по поиску, оценке и обработке ошибок, которые большинство туториалов полностью пропускают.
Этот разрыв — тема курса LLM Engineering with LangChain: RAG and Agents. Не сам фреймворк — LangChain это средство, а не цель — а дисциплина превращения вероятностной модели в компонент, который можно анализировать. Генерация с дополненной выборкой (RAG), эмбеддинги, векторные базы данных, агенты, вызов инструментов, оценка (evals), стоимость и задержка: это несущие части. Ошибётесь в них — демо впечатлит на неделю, а затем тихо подорвёт доверие.
Эта статья о том, как на самом деле работает эта машинерия, где она ломается и как выглядит путь обучения — чтобы вы могли решить, стоит ли это поле вашего времени и является ли курс правильным входом.
Почему эта область вознаграждает понимание механизма
LLM сам по себе — это функция: текст на входе, текст на выходе, без памяти о ваших данных и без возможности проверять факты. RAG — инженерный ответ на это ограничение: вместо того чтобы надеяться, что модель запомнила ваши документы, вы извлекаете релевантные фрагменты во время запроса и вставляете их в промпт. Задача модели сокращается с «знать всё» до «прочитать эти пять абзацев и ответить». Это гораздо более простая задача, и именно поэтому RAG стал архитектурой по умолчанию для корпоративных LLM-приложений.
Но фраза «извлечь релевантные фрагменты» скрывает три отдельные поверхности отказа:
- Чанкинг решает, что такое «фрагмент». Разрежьте пункт договора посередине предложения — и поисковик может никогда его не найти.
- Эмбеддинги решают, что значит «релевантный». Они отражают семантическое сходство, а не логику — фрагмент о возвратах и фрагмент об отсутствии возвратов могут находиться очень близко в векторном пространстве.
- Векторная база данных решает, насколько быстро и точно вы можете искать. Индексы приближённого поиска ближайших соседей обменивают полноту на скорость, и этот компромисс невидим, пока его не поймает оценка.
Каждое из этих решений — реальное инженерное решение с цифрами. Понимание механизма позволяет предсказать, какое из них вызывает плохой ответ, вместо случайной подстройки промптов.
Одна задача, разобранная как следует
Возьмём конкретную работу: построить внутреннего помощника по 40 000 тикетов поддержки и документации по продукту, чтобы агенты поддержки могли спросить «как мы обрабатываем возвраты по годовым планам после 30 дней?» и получить ответ со ссылкой на источник.
Вот как практик на самом деле выстраивает последовательность — и что ломается, если её переставить.
Шаг 1: Создайте набор для оценки до пайплайна
Это шаг, который новички пропускают, и именно он определяет, будут ли следующие три недели продуктивными или слепыми. Напишите 30–50 реальных вопросов с известными правильными исходными фрагментами. Не синтетические вопросы, которые генерирует модель, — реальные от агентов поддержки, включая запутанные.
Почему сначала? Потому что каждое решение после этого (размер чанка, модель эмбеддингов, включение или выключение реранкера) — это сравнение, а сравнение требует системы оценки. Без неё вы выбираете по ощущениям, а ощущения не выдерживают контакта с продакшн-трафиком.
Шаг 2: Чанкинг по структуре, а не фиксированными окнами
Наивный сплиттер режет каждые 1000 символов. На документе о политике возвратов это надёжно отрывает пункт об исключении («…кроме годовых планов, где…») от его правила. Лучший подход: разбивать по структуре документа — заголовки, пункты списков, строки таблиц — и сохранять небольшое перекрытие между чанками, чтобы предложение, пересекающее границу, выжило хотя бы в одном чанке.
Для корпуса из 40 000 документов размер чанка — это ещё и рычаг стоимости. Удвоение количества чанков удваивает векторное хранилище и примерно удваивает число кандидатов, которые поисковик оценивает на каждый запрос.
Шаг 3: Выбирайте эмбеддинги и векторное хранилище осознанно
Модели эмбеддингов различаются размерностью и тем, в чём они хороши. Модель с 1536 измерениями и модель с 384 измерениями дают очень разные объёмы хранения: для 200 000 чанков это примерно 1,2 ГБ против 300 МБ сырых векторов float32 до накладных расходов индекса. Больше измерений не всегда лучше — это компромисс с задержкой и стоимостью.
Выбор векторной базы данных аналогичен. pgvector — прагматичный выбор по умолчанию, если вы уже используете Postgres: одна система для эксплуатации, транзакции и фильтрация по метаданным бесплатно, и масштабируется дальше, чем ожидает большинство команд. Qdrant и Pinecone дают специализированное индексирование и управляемую эксплуатацию ценой ещё одной зависимости. Ошибка — выбрать специализированную векторную БД в первый же день для нагрузки, которая спокойно помещается в Postgres.
Шаг 4: Добавьте гибридный поиск и реранкер
Чистый векторный поиск упускает точные идентификаторы — артикулы, коды ошибок, названия планов. Гибридный поиск сочетает сходство эмбеддингов с поиском по ключевым словам, что ловит такие случаи. Затем кросс-энкодерный реранкер пересчитывает оценку топ-50 кандидатов и оставляет лучшие 5–8 для промпта.
Компромисс конкретен: реранкер может добавить 100–300 мс на запрос в зависимости от модели и оборудования, и он требует вычислений. Вы платите задержкой за точность. Во внутреннем инструменте поддержки это обычно оправдано; в клиентском чате, где ощущаются каждые 200 мс, сначала измерьте, потом решайте.
Шаг 5: Оценивайте, затем итерируйте
Запустите набор для оценки. Предположим, 34 из 50 вопросов извлекают правильный фрагмент в топ-5 — это 68% попаданий. Теперь у вас есть число, относительно которого можно улучшать. Попробуйте другой размер чанка, реранкер, гибридный поиск — и снова измерьте. Когда поиск выходит на плато около 90%, оставшиеся ошибки обычно связаны с пробелами в корпусе (ответа нет в документах), а не с ошибками пайплайна.
Где сама схема ломается
RAG и агенты применимы не везде. Есть условия, при которых вся архитектура перестаёт окупаться, и раннее их распознавание экономит месяцы.
Отказ 1: Корпус слишком мал или слишком нестабилен
Если ваша база знаний — 20 страниц, которые меняются еженедельно, RAG избыточен. Хорошо структурированный промпт с полным текстом может поместиться в контекстное окно и быть надёжнее. RAG окупается, когда корпус превышает то, что помещается в контекст, и меняется независимо от вашего кода. Ниже этого порога вы добавляете индекс, пайплайн эмбеддингов и задачу переиндексации для решения проблемы, которой у вас нет.
Ранний сигнал: ваш набор для оценки почти полностью проходит с наивным промптом на полном контексте. Если так — прекратите строить поиск.
Отказ 2: Вопросы требуют рассуждений по многим документам
Векторный поиск возвращает топ-k похожих чанков. Он не агрегирует. «Каков был наш общий объём возвратов за прошлый квартал в разрезе планов?» — это вопрос SQL, а не поиска. Агенты могут помочь — агент с вызовом инструментов, который пишет и выполняет запрос — но это другая архитектура со своими режимами отказа (агент пишет неверный запрос и уверенно сообщает число).
Ранний сигнал: пользователи продолжают задавать вопросы, ответы на которые требуют подсчёта или соединения. Это сигнал добавить инструмент для структурированных данных, а не увеличивать k.
Отказ 3: Модель эмбеддингов устаревает
Модели эмбеддингов выводятся из эксплуатации. Когда провайдер прекращает поддержку модели, с которой вы индексировали, ваши векторы больше не сопоставимы с новыми эмбеддингами запросов — и вам придётся переиндексировать весь корпус. Для 200 000 чанков это пакетная задача на часы и реальный счёт за API, плюс план переключения, чтобы запросы не попадали на полумигрированный индекс.
Ранний сигнал: следите за уведомлениями провайдера об устаревании. Если уже поздно, безопасный ход — построить новый индекс рядом со старым и переключиться атомарно, а не переиндексировать на месте.
Отказ 4: Агент зацикливается
Агенты с вызовом инструментов отказывают характерным образом: модель вызывает инструмент, получает бесполезный результат, повторяет тот же вызов с немного другой формулировкой и сжигает токены, пока её не остановит лимит. Без явного ограничения цикла и запасного пути один вопрос пользователя может стоить во много раз больше ожидаемого.
Ранний сигнал: рост среднего числа токенов на запрос при неизменном объёме пользователей. Исправление: жёсткое ограничение итераций, путь «сдаться и сообщить об этом» и трассировка, чтобы видеть точный цикл.
| Отказ | Что идёт не так | Ранний сигнал | Если уже поздно |
|---|---|---|---|
| Корпус слишком мал | Излишняя сложность | Промпт на полном контексте проходит оценки | Оставить индекс, упростить путь промпта |
| Нужна агрегация | Поиск возвращает похожее, а не правильное | Пользователи задают вопросы с подсчётом | Добавить инструмент для структурированных данных |
| Эмбеддинги устарели | Векторы несопоставимы | Уведомление провайдера об устаревании | Построить новый индекс, переключиться атомарно |
| Циклы агента | Всплеск стоимости и задержки | Рост токенов на запрос | Добавить ограничение итераций и запасной путь |
Агенты и инструменты: часть, которая звучит легко, но таковой не является
Агент — это цикл: модель решает вызвать инструмент, читает результат, решает снова. Вот и всё. Сложность — во всём, что вокруг цикла: дизайн инструментов, обработка ошибок и наблюдаемость.
Описание инструмента — это промпт. Если описание search_tickets расплывчато, модель будет вызывать его для вопросов, которые должны направляться в другое место. Хороший дизайн инструментов означает узкие, хорошо названные инструменты с чёткими схемами входных данных и явными сообщениями об ошибках. Инструмент, возвращающий пустую строку при ошибке, ничему не учит модель; инструмент, возвращающий «нет результатов по запросу X; попробуйте более широкие термины», позволяет модели исправиться.
Структурированный вывод здесь тоже важен. Когда вам нужно, чтобы модель вернула JSON, вызов функций ограничивает вывод схемой — но схема должна быть достаточно простой, чтобы модель могла надёжно её заполнить. Глубоко вложенные схемы со множеством необязательных полей — это место, где структурированный вывод тихо деградирует в некорректные ответы.
И наблюдаемость не опциональна. Трассировка каждого шага агента — какой инструмент, какой вход, какой выход, сколько токенов — это разница между отладкой за час и отладкой за неделю. Вот почему существуют инструменты трассировки вроде LangSmith и почему команды, которые их пропускают, платят за это позже.
Стоимость и задержка: рычаги, которые действительно работают
У LLM-приложений два взаимодействующих бюджета: деньги и время. Основные рычаги:
- Кэширование — идентичные или почти идентичные запросы получают кэшированные ответы. В инструменте поддержки с повторяющимися вопросами это может быть самой большой экономией.
- Потоковая передача — пользователь видит токены по мере их поступления. Общая задержка не меняется, но воспринимаемая задержка резко падает.
- Пакетная обработка — задачи эмбеддингов и офлайн-задачи естественно группируются; интерактивные запросы — нет.
- Выбор модели — маршрутизация простых запросов к меньшей модели, а сложных — к большей часто является изменением с наибольшим рычагом.
Грубый расчёт: если каждый запрос стоит около 200 ₽ в токенах и вы обслуживаете 50 000 запросов в месяц, это 10 млн ₽ в месяц — немало. Но добавьте реранкер и многошагового агента, и один запрос может стоить в 5–10 раз больше. В этот момент разница между 3-шаговым и 8-шаговым агентом — реальные деньги, и задержка накапливается так же.
Пути обучения и их честные компромиссы
Есть три реалистичных способа войти в эту область, и они различаются по времени, деньгам и тому, что вы на самом деле сможете делать.
| Путь | Время | Стоимость | Что вы получаете | Что вы упускаете |
|---|---|---|---|---|
| Самостоятельное изучение по документации и туториалам | 3–6 месяцев, неравномерно | Низкая | Работающие демо | Обратную связь по решениям; дисциплину оценок |
| Построение реального внутреннего проекта | 2–4 месяца | Ваше время | Глубокую интуицию | Широту; кого-то, кто проверит ваши слепые зоны |
| Структурированный курс | Недели — несколько месяцев | Умеренная | Последовательность, закрывающую пробелы | Всё равно нужен собственный проект для закрепления |
Самостоятельное изучение дешевле всего и работает, если вы достаточно дисциплинированы, чтобы построить набор для оценки до пайплайна — большинство людей нет, потому что туториалы никогда не показывают этот шаг. Построение реального проекта учит большему, чем любой курс, но вы узнаёте только то, на что случайно наткнулся ваш проект. Структурированный путь стоит того, когда вы хотите, чтобы пробелы закрывались в продуманном порядке — оценка поиска, ограничения циклов агента, контроль затрат — а не обнаруживались по одному инциденту в продакшене за раз.
Именно этот разрыв призван закрыть курс LLM Engineering with LangChain: RAG and Agents: он проходит полный путь от чанкинга и эмбеддингов через оценки, агентов и контроль затрат, с расчётами вроде тех, что намечены в этой статье, выполненными на примерах. Если у вас уже есть проект и нужен только один недостающий кусок, документация быстрее. Если вы начинаете и хотите последовательность, курс — более эффективный маршрут.
Кому это подходит — и кому нет
Этот путь подходит вам, если:
- Вы умеете писать на Python и уже вызывали API. Курс предполагает код, а не только концепции.
- Вы построили демо, которое кого-то впечатлило, а затем сломалось, и хотите знать почему.
- Вы отвечаете за систему, которая должна быть надёжной и предсказуемой по стоимости, а не просто впечатляющей.
Он не подходит вам, если:
- Вы хотите избежать кода. Это инженерия, а не написание промптов.
- Вам нужны результаты за неделю. Качество поиска и дисциплина оценок требуют итераций.
- Вы ищете обзор фреймворка. LangChain рассматривается потому, что это средство передвижения, а не пункт назначения.
Начните с набора для оценки
Если вы возьмёте из этой статьи одну вещь, пусть это будет: разница между демо и продуктом — это измерение. Сначала постройте набор для оценки, трассируйте каждый шаг и относитесь к поиску, агентам и стоимости как к инженерным задачам с цифрами. Остальное — итерации.
Курс проходит именно эти расчёты на примерах — размер чанка, доля попаданий при поиске, задержка реранкера, стоимость агента — и даёт обратную связь по вашим решениям через ИИ-чат курса, где вы можете попросить проверить ваш подход. Если вы хотите структурированный путь, а не сборку из разрозненных туториалов, детали и запись на странице LLM Engineering with LangChain: RAG and Agents.
Начать можно здесь: LLM-инженерия: LangChain, RAG и агенты.