Habr AI показал, как собрать собственный RAG-ретривер в LangChain для имён и терминов

Habr AI опубликовал практический разбор для RAG-инженеров, которым стандартный векторный поиск не дает нужной точности на именах, названиях и редких терминах. В материале показывают, как собрать собственный ретривер на TF-IDF, встроить его в LangChain и проверить на бенчмарке против типовых решений.

Где ломаются эмбеддинги

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

Ошибка возникает не на этапе генерации, а раньше — когда система достает не тот фрагмент документа. Слабое место стандартного поиска проявляется там, где важны буквальные различия. Имена людей, названия продуктов, компаний, внутренних систем, технические сокращения и редкие термины могут быть слишком близки по смысловому окружению, но критично отличаться в прикладной задаче.

Если такие сущности плохо разделяются в пространстве эмбеддингов, качество выдачи падает даже при хорошем LLM-слое. Поэтому идея собственного ретривера здесь выглядит не как украшение стека, а как способ закрыть конкретный класс ошибок.

«А для этого у меня есть собственный ретривер».

Схема кастомного ретривера

Практическая часть начинается с самого понятного слоя — подготовки данных. Документы нужно разбить на фрагменты, или чанки, чтобы поиск возвращал не весь текст целиком, а конкретный релевантный кусок. После этого для набора чанков строится TF-IDF-представление.

Оно помогает ранжировать фрагменты по важности слов и быстрее находить совпадения там, где буквальная точность важнее семантической близости. Затем поверх индекса добавляется собственная поисковая логика и все это упаковывается в интерфейс LangChain. В статье этот конвейер выглядит максимально приземленно: корпус очищают и приводят к рабочему виду документы режут на чанки для точного возврата контекста по чанкам строят TF-IDF-модель результаты поиска оборачивают в кастомный ретривер для LangChain * отдельно готовят вопросы для сравнения со стандартными вариантами Сильная сторона такого подхода — предсказуемость.

Инженер лучше понимает, почему система выбрала тот или иной фрагмент, и может дебажить выдачу без сложной инфраструктуры вокруг векторной базы. Плюс такой ретривер дешевле в эксплуатации и быстрее поднимается для локальных экспериментов. Это не универсальная замена современным решениям, но хороший инструмент для доменов, где значение имеет не «похожий смысл», а точное совпадение сущностей и формулировок.

Как проверяют результат Отдельный акцент сделан на сравнении, а не только на сборке.

После создания собственного ретривера автор предлагает прогнать его против двух или трех стандартных решений и посмотреть на качество выдачи и скорость. Такой шаг важен, потому что кастомная реализация легко может казаться лучше на нескольких ручных примерах, но проигрывать на более широком наборе запросов. Бенчмарк здесь выступает как фильтр от самообмана и помогает понять, где именно специализированный поиск дает реальную прибавку.

Для подготовки вопросов в статье используют Ollama. Это удобный способ быстро собрать тестовый набор под свой корпус, не завязываясь на внешний API и не тратя время на полностью ручную разметку. В итоге материал показывает зрелый инженерный подход: сначала выделить типичную ошибку, затем подобрать под нее более подходящий механизм поиска и только после этого сравнивать результаты на контролируемом наборе запросов.

Для команд, которые строят внутренние RAG-сервисы, такая дисциплина обычно важнее громких обещаний про «магический» стек.

Что это значит

Разбор Habr AI показывает сдвиг в зрелости RAG-практики: рынок уходит от веры в один универсальный ретривер к более узкой настройке поиска под данные и тип ошибок. Для команд с базами знаний, каталогами, юридическими текстами или внутренними справочниками это хороший сигнал: иногда заметный прирост качества дает не новая модель, а правильно собранный слой поиска.