Retrieval-Augmented Generation (RAG) всё чаще упоминается в контексте LLM и всё чаще фигурирует в требованиях к разработчикам, но за этим термином обычно скрывается довольно размытое представление о том, как такие системы реально устроены. В этой статье я разбираю RAG как архитектурный подход: зачем он вообще появился, какие задачи решает, как выглядит базовый пайплайн от данных до ответа модели и где на практике чаще всего возникают проблемы.

В этом посте мы поговорим подробно про RAG на каждом его этапе, его модификации и его перспективные направления развития на момент написания статьи.

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

В конце концов я пришёл к выводу, что лучше бы их вообще не брать. Но если уж ввязался — то только на следующих условиях (которые в последние несколько проектов спасли мне миллиарды нервных клеток).

ИИ‑агенты — очень горячая тема. Кажется, все их делают, но также кажется, что реальную пользу приносит только небольшая часть. Один из основных удачных примеров — DeepResearch, глубокий поиск, отвечающий на сложные вопросы. Многие им пользуются в ChatGPT или Perplexity, но у внешних решений нет доступа к нашим корпоративным данным, поэтому мы сделали свой DeepResearch и сэкономили время сотрудников компании.

Меня зовут Сергей Скородумов, я руководитель отдела поисковых сервисов. В статье расскажу про ИИ‑агентов в целом, как мы делали своего, за счёт чего растили его качество и какие главные выводы сделали.