Почему RAG — это не просто «добавить поиск»: latency, качество и выбор стратегии retrieval

Когда говорят про RAG, его часто описывают как простой способ улучшить LLM‑систему: добавить поиск по внешним данным, найти релевантный контекст, передать его модели и получить более точный ответ. На уровне идеи это действительно выглядит логично. Но в реальной системе RAG — это не только способ обогатить ответ. Это отдельный операционный слой, который влияет на задержку, размер prompt, количество input tokens, стоимость запроса, качество ответа, SLA и требования к наблюдаемости системы. Я хотел посмотреть на это не в формате общих рассуждений, а на небольшом локальном стенде: где именно появляется дополнительная нагрузка, какие параметры сильнее всего влияют на latency, почему больше контекста не всегда означает лучшее качество и почему стратегия retrieval должна зависеть от типа вопроса и структуры данных. Это не промышленный benchmark и не попытка получить универсальные цифры. Скорее серия контролируемых экспериментов: посмотреть на механику RAG pipeline и компромиссы, которые часто остаются за кадром, когда RAG описывают просто как «поиск + LLM».

https://habr.com/ru/articles/1040938/

#RAG #LLM #retrieval #latency #Chroma #Ollama #vector_search #embeddings #topk #chunk_size

Почему ломается ваш AI-агент — и почему смена модели обычно его не чинит

Представьте внутреннего AI-агента, который помогает компании искать общие документы и управлять ими. Он работает. До тех пор, пока 12–15% запросов не начинают падать. Агент возвращает не тот документ, редактирует не тот файл, молча падает или уверенно ссылается на файл, которого не существует. Поиск по фото отказывает с той же частотой. Ошибки размазаны равномерно по пользователям, фичам и запросам. Первое инстинктивное действие — поменять модель. Opus 4.5, GPT 5.5 или что там сейчас в топе лидерборда. Меняете. Счет за инференс растет в 4–5 раз, а общая доля ошибок снижается с 12% до 9%. Пользователи пишут о тех же проблемах. Бюджет следующего квартала сгорает за пару недель ради улучшения в 3 процентных пункта — и вы по-прежнему не понимаете, что именно было не так в системе и как улучшать ее дальше. Эта статья — о том, почему смена модели обычно разочаровывает и куда стоит смотреть в первую очередь. Большинство сбоев AI-систем живет в слое обвязки — orchestration, retrieval, tool definitions, retries, context management, — а не в самой модели. Дальше — метод, как отличить проблемы обвязки от проблем модели, кейс, в котором одно исправление в обвязке подняло completion rate с 26% до 88% без смены модели, и чек-лист, который помогает находить такие сбои в вашей собственной системе. Если вы никогда не делали подобной диагностики — ожидайте найти хотя бы один пункт, который стоит починить.

https://habr.com/ru/articles/1039292/

#aiагенты #llm #rag #orchestration #retrieval #tool_calling #context_engineering #evals #production #ai_infrastructure

Защита от дублирования кода агентами: семантические концепции

Я строю Telegram-first SaaS в одиночку, а весь код за меня пишут ИИ-агенты Claude Code, и довольно быстро я уперся в неприятное: каждый новый агент приходит на работу с чистой памятью, не находит уже написанное, грепает по выдуманным именам и пишет свою реализацию заново - так за неделю в репозитории набегает +65К -1.5К строк, а устоявшиеся паттерны тихо расходятся. Это третья статья серии про разработку руками агентов, и в ней - честный разбор того, как я строил для своей команды из амнезиков слой памяти о коде. Почему клоны от ИИ это в основном Type-4, которые токенные детекторы попросту не видят; почему векторная база здесь неправильный основной фикс; как граф концептов на локальной модели лег почти один-в-один на когнитивную науку о человеческой памяти (Тульвинг, Вегнер, Спэрроу); и как на одном страшном отрицательном результате я чуть не усложнил себе архитектуру ради проблемы, которая решалась переписыванием одного абзаца. С тупиками, цифрами и слепым A/B-тестом, без срезанных углов. Вспомнить всё

https://habr.com/ru/articles/1039124/

#ИИагенты #Claude_Code #дедупликация_кода #граф_концептов #эмбеддинги #семантический_поиск #Type4_клоны #retrieval #DRY #память
__агентов

Практический ИИ-агент Python: LangGraph + Qdrant

При разработке ИИ-агента для базы знаний, мне казалось, что задача почти типовая: складываем информацию в Qdrant, находим информацию через векторный поиск и поиск в интернете и формируем красивый ответ через LLM. На деле ИИ-агент начал уверенно галлюцинировать, приносить не только нерелевантные ответы, но и тупить с короткими пользовательскими запросами. И самое неприятное, при всем при этом метрика «похожести» similarity выглядела достаточно высокой, что сильно вводило в заблуждение. После серии экспериментов и улучшений пришло понимание, что промышленный ИИ-агент — это не столько про LLM, сколько про качество извлечения информации и гибкую оркестрацию компонентов ИИ-агента. Что в итоге полностью поменяло архитектуру моей системы. В статье расскажу, как я пришла от «просто добавь LLM» к промышленному графовому ИИ-агенту на LangGraph + Qdrant.

https://habr.com/ru/articles/1038190/

#aiагенты #retrieval #llmагент #qdrant #rag #langgraph

RAG для тех, кто разочаровался: почему retrieval ломается и как это починить

Вы собрали RAG-пайплайн: загрузили документы, нарезали на чанки, сгенерировали эмбеддинги, подключили векторную базу. Задаёте вопрос — модель отвечает уверенно и подробно. Показываете заказчику, тот в восторге. Потом начинается тестирование на реальных вопросах, и оказывается, что на половину из них система отвечает мимо: то находит не тот документ, то находит правильный, но не тот кусок, то вообще ничего релевантного не достаёт и модель уверенно галлюцинирует. Каждый раз проблема не в модели (GPT-4 и Claude отвечают хорошо, если им дать правильный контекст), а в retrieval — в том, как мы ищем релевантные куски документов. Модель отвечает ровно настолько хорошо, насколько хорош контекст, который ей подсунули. Рассмотрим три основные причины. Разобрать RAG

https://habr.com/ru/companies/otus/articles/1034386/

#ml #python #retrieval #rag #LLM #векторный_поиск

A weighty thematic issue of Information Research has just dropped: 'Artificial Intelligence (AI) in Information Science'. The issue includes 44 papers exploring information seeking in the age of #AI, #information evaluation and use, information #retrieval, trust and security, future research needs, and a lot more. It'll take a while to read them all, but read I must!

https://publicera.kb.se/ir/issue/view/5559 #InformationResearch #InformationScience #InformationRetrieval #LLMs #ArtificialIntelligence

This is a handy list for comparing the features of vector databases (holy mole there are a lot of them), including year of launch, opensource-ness, licences, and implementation language: https://superlinked.com/vector-db-comparison

#vectors #embeddings #search #retrieval #rag #genai #agents

RAG: Как собрать свой ретривер для особых случаев

С опытом у RAG-инженера накапливается солидный багаж эвристик и инструментов, которые в определенных задачах превосходят по качеству или скорости стандартные. Фраза «а для этого у меня есть собственный ретривер» звучит с некоторым снобизмом, но добавляет к профессионализму несколько пойнтов. Хотите в свою коллекцию ретривер, который умеет работать с терминами, плохо различимыми в векторном пространстве эмбеддинга, в частности с именами и названиями? Тогда давайте перейдём от снобизма к практике. Начнём с обработки текста и сегментируем его на фрагменты - «чанки». Далее сделаем TFIDF модель, добавим поиск и обернём всё это в ретривер LangChain. Наконец сравним наш ретривер с двумя-тремя стандартными решениями. А Ollama поможет с вопросами для бенчмарка.

https://habr.com/ru/articles/1022244/

#rag #rag_pipeline #text_mining #text_generation #retrieval #ollama #gensim #langchain