Десять скрытых ошибок поиска в производственных системах RAG и способы устранения каждой из них.
От размера блоков и перекрытия к гибридному поиску, RRF, переранкингу, выбору эмбеддингов и оценке CI: десять ошибок поиска, приводящих к неверным ответам RAG, и способы их устранения.
Источники: RAG: Mistakes that Quietly Kill Retrieval Quality
Один из чат-ботов поддержки когда-то прекрасным стилем объяснил неверную политику возврата средств. Инструмент поиска нашёл абзац, в котором слово «возврат средств» встречалось четыре раза. Он был тематически релевантен, так как описывал прекращённую линейку продуктов. Генеративная модель сделала то, что ей было велено — уверенно ответить на основе предоставленного контекста. Никто не сказал ей, что контекст неверен.
Такова суть большинства сбоев в технологии RAG, которые в итоге приводят к сеансам отладки. Команда тратит две недели на замену модели, переписывание системных инструкций и добавление указания «отвечать только на основе контекста» крупным шрифтом, но уровень галлюцинаций почти не меняется. Проблема никогда не заключалась в процессе генерации. Модель правильно рассуждала на основе уже ошибочных данных, поступивших к ней изначально.
Десять конкретных ошибок снижают качество поиска в производственных системах RAG. Они обычно проявляются в определенной последовательности: сначала ошибки разбиения на чанки, поскольку они возникают на раннем этапе, затем проблемы с дизайном механизма поиска, после этого — вопросы с ранжированием результатов и выбором методов включения данных, и наконец — проблема измерения, которая позволяет всем этим ошибкам оставаться незамеченными. В каждом из разделов ниже объясняется, почему возникает ошибка, каковы ее последствия и что необходимо изменить, а также там, где исследования противоречат друг другу, противоречия указываются открыто.
Почему именно механизм поиска является причиной сбоев в RAG
Отчеты специалистов о работе систем RAG в 2026 году постоянно указывают на одну и ту же причину проблем: большинство некорректных ответов связано с процессом поиска информации. Возвращаются неверные документы, или упускаются правильные, или они занимают слишком низкую позицию в рейтинге, чтобы их можно было использовать. Распространенная оценка составляет около 70% или даже выше. Это число меняется в зависимости от отчета и области применения, поэтому является лишь приблизительным показателем, однако независимые источники согласны в отношении общей тенденции. Когда система RAG дает неверный результат, наиболее вероятное объяснение заключается в том, что модели LLM так и не были показаны правильные доказательства, поэтому первым шагом является анализ того, что вернул механизм поиска, прежде чем вносить изменения в запрос.
Десять основных ошибок делятся на четыре группы в соответствии с этапами работы системы. Ошибки с номерами от 1 до 4 влияют на данные, загружаемые в векторный хранилище. Ошибки с номерами от 5 до 7 касаются архитектуры процесса поиска. Ошибки с номерами 8 и 9 связаны с этапами ранжирования и генерации векторных представлений. Десятая ошибка заключается в том, что ничего из этого не измеряется.
Термины, используемые ниже
- Чанкинг означает разделение исходных документов на фрагменты перед индексацией. Модели встраивания и окна контекста работают лучше с короткими, сфокусированными единицами, чем с целыми файлами.
- Плотный поиск (векторный поиск) помещает запросы и фрагменты в одно пространство встраивания и возвращает ближайших соседей. Он эффективен для обработки парафразов, но слаб в работе с буквальными строками.
- Редкий поиск, такой как BM25, ранжирует фрагменты по общим словам запроса, уделяя больший вес редким словам. Коды, имена и жаргон хорошо совпадают, а синонимы — нет.
- Гибридный поиск выполняет оба способа поиска одновременно и объединяет два ранжированных списка, чаще всего с использованием Reciprocal Rank Fusion (RRF). RRF использует позиции в ранжировании вместо сырых оценок, что решает проблему некомпарируемости значений BM25 и косинусных сходств.
- Переранжирование вновь оценивает короткий список кандидатов, обычно состоящий из 20–100 элементов, с использованием кросс-кодера, который одновременно обрабатывает запрос и текст, вместо того чтобы обрабатывать их отдельно. В результате формируется гораздо более точный порядок элементов перед тем, как верхние k элементов будут переданы в LLM.
Четыре ошибки при разбиении на чанки
1. Использование разбиения фиксированного размера в качестве стандарта и полное игнорирование других вариантов
В учебных материалах сначала рекомендуется разбивать каждый документ на окна по 500 токенов независимо от содержимого. Это занимает пять минут, хорошо подходит для демонстрации, и команды используют этот метод без дальнейших проверок.
В этом вопросе существуют противоречивые исследования, и говорить об этом полезнее, чем притворяться, что существует консенсус. Несколько сравнений 2026 года отдают предпочтение фиксированному или рекурсивному разделению токенов перед семантическим разбиением на фрагменты. В одном крупном тестировании множества стратегий победило рекурсивное разделение на 512 токенов, отчасти потому, что семантическое разбиение в среднем давало фрагменты длиной всего 43 токена, что слишком мало для сохранения контекста. Другие исследования в других областях показывают противоположный результат: в оценке систем поддержки клинических решений, прошедшей рецензирование, была зафиксирована точность 87% для адаптивного разбиения, соответствующего тематике, против 50% для фиксированной базовой стратегии (p = 0.001). В третьем сравнении было установлено, что хорошо настроенный фиксированный размер может сравниться с семантическим разделением или превзойти его на реальных наборах данных, что соответствует использованным в первоначальной статье RAG фиксированным фрагментам длиной 100 слов.
Ни одна стратегия не работает во всех случаях. Все источники согласны в том, что ошибка заключается не в выборе разделения фиксированного размера, а в выборе какой-либо одной стратегии без сравнения альтернатив на реальном корпусе данных.
Практическим решением является измерение вместо теоретизирования. Соберите от 20 до 50 репрезентативных пар вопросов и ответов, индексируйте тот же корпус данных с использованием двух-трех кандидатских стратегий и сравните показатели recall@5 и контекстной точности. Тексты с встроенной структурой, такие как документация API, юридические документы и финансовые отчеты, обычно показывают лучшие результаты, когда сначала происходит разделение в соответствии с этой структурой, поскольку эти единицы и так уже являются целостными:
from langchain_text_splitters import RecursiveCharacterTextSplitter
# Recursive splitting respects structure first, falls back to
# character boundaries only when a section is still too large.
splitter = RecursiveCharacterTextSplitter(
chunk_size=512, # tokens, not characters, if you swap in a token-aware splitter
chunk_overlap=75, # ~15% overlap, a reasonable starting point
separators=["\n## ", "\n### ", "\n\n", "\n", ". ", " "],
)
chunks = splitter.split_text(document_text)
2. Один размер фрагмента для каждого типа документа
Размер выбирается заранее на основе приблизительных правил, после чего применяется к смешанной коллекции документов. Ссылки на API, длинные документы с правилами и протоколы чатов получают одинаковые параметры обработки.
Чрезмерно большие фрагменты снижают точность оценки релевантности. Фрагмент из 2 000 токенов, охватывающий пять тем, даёт вектор, который представляет собой размытое среднее всех пяти тем и плохо соответствует ни одной из них. Слишком маленькие фрагменты лишают читателя необходимого контекста — например, это похоже на сигнатуру функции без указания параметров или на пункт правила без указания раздела, который он изменяет.
Размер должен соответствовать плотности содержимого. Техническая документация обычно вмещает примерно от 256 до 512 токенов, что позволяет сосредоточиться на одной концепции. Нарративный или политический текст обычно требует от 1 024 до 2 048 токенов для сохранения контекста. Это лишь отправные точки для проверки, поскольку оптимальное значение зависит от модели встраивания и от того, как пользователи формулируют вопросы.
3. Проблема перекрытия
Перекрытие настраивается один раз и затем игнорируется или пропускается из-за предполагаемой траты памяти. Без него предложение, пересекающее границу блока, разрезается на две части: один блок заканчивается вводной частью, а следующий начинается с вывода, и ни одна из них не может быть воспринята как целостная мысль. Это распространённая и полностью избежимая причина жалоб на то, что ответ где-то там, но модель не может его найти.
Разумным стандартным значением является перекрытие размером 10–20% от размера блока: 50–100 токенов для блока из 500 токенов, что недорого по сравнению с проблемами, которых это предотвращает. Большее значение не всегда лучше. Чрезмерно высокое перекрытие в основном увеличивает объем хранилища и добавляет «шум», причем по крайней мере один систематический анализ 2026 года с использованием метода поиска SPLADE не выявил значимой пользы от перекрытия в такой конфигурации. Решение должно определяться «золотым набором» параметров, а не стандартными настройками.
4. Игнорирование собственной структуры документа
Более просто рассматривать каждый файл как единый объект, независимо от того, является ли это справочником Markdown API, договором с пронумерованными пунктами или финансовым отчетом, содержащим много таблиц, однако разделение без учета структуры часто приводит к тому, что заголовок оказывается вне своего раздела или таблица — вне абзаца, который ее описывает. Чаще всего пострадает описание функции, отделенное от списка ее параметров, в результате чего ответ на вопрос об этой функции будет неполным.
Решение заключается сначала в разделении по структуре — с учётом заголовков, разделов, списков и таблиц, — а разделение по размеру следует применять только в тех разделах, которые остаются слишком большими. По этой причине к середине 2026 года большинство инструментов для разбиения данных на части представляют собой гибридные решения: сначала учитывается структура, затем происходит семантическое разделение в длинных неструктурированных участках, фиксированный размер используется в качестве крайней меры, и ни один метод не навязывается всему смешанному корпусу данных.
Три ошибки в архитектуре поиска
5. Использование только поиска векторов
Шаблоны для начинающих по умолчанию предусматривают использование поиска векторов. Это один запрос к API, и он выглядит отлично в демонстрациях, где тестовые запросы представляют собой разговорные парафразы — именно то, в чём лучше всего справляются плотные эмбеддинги.
Настоящий трафик отличается от демонстрационного. Пользователи вводят коды продуктов, строки с ошибками, названия флагов, номера тикетов и собственные имена — краткие литеральные токены. Модели с высокой плотностью, обученные кластеризовать смысл, склонны путать их с похожими, но неверными элементами. Результаты тестов неоднократно показывают эту разницу: отрегулированная гибридная схема превосходила любой из методов в отдельности в тестах на ранжирование в электронной коммерции, а тесты, проведенные специалистами, показали, что метод, основанный исключительно на векторах, уступает полноценно объединенной гибридной схеме, в основном из-за пропуска точных идентификаторов. Цифры различаются в зависимости от корпусов данных, но общая тенденция сохраняется во всех тестированных случаях. Когда запросы сочетают в себе элементы разговорного стиля и точного совпадения, что бывает практически всегда, гибридный подход оказывается более эффективным.
Изменение заключается в добавлении индекса BM25 или SPLADE рядом с векторным индексом. Weaviate, Elasticsearch, OpenSearch, Qdrant и Milvus теперь все поддерживают нативные гибридные запросы, а LangChain и LlamaIndex поставляются с механизмами поиска на основе слияния, которые их реализуют:
from langchain.retrievers import EnsembleRetriever
from langchain_community.retrievers import BM25Retriever
bm25_retriever = BM25Retriever.from_texts(chunk_texts)
bm25_retriever.k = 20
vector_retriever = vectorstore.as_retriever(search_kwargs={"k": 20})
# weights are a starting point for RRF-style blending; tune against your eval set
hybrid_retriever = EnsembleRetriever(
retrievers=[bm25_retriever, vector_retriever],
weights=[0.4, 0.6],
)
results = hybrid_retriever.invoke(user_query)
6. Слияние с использованием взвешенного среднего, а не RRF
После добавления алгоритма BM25 логичным шагом кажется нормализация обоих списков оценок в диапазон от 0 до 1 и их смешивание с учетом весов. Это выглядит разумным в электронной таблице. Однако оценки BM25 и значения косинусного сходства происходят из неограниченных распределений разной формы, поэтому метод минимум-максимум является хрупким. Один документ-аномалия, содержащий термин запроса десятки раз, может после нормализации сделать все остальные оценки BM25 близкими к нулю, искажая итоговый рейтинг таким образом, что это трудно заметить без специального анализа.
Метод слияния взаимных рангов избегает этой проблемы путем использования ранговой позиции каждого документа в каждом списке и полного игнорирования оценок. Именно поэтому RRF, а не взвешенное среднее, является стандартом практически во всех промышленных гибридных реализациях, упоминаемых в технических отчетах 2026 года. Стандартная формула предусматривает присвоение каждому документу суммы 1 / (k + rank) для всех списков, в которых он присутствует, причем обычным значением k=60 служит коэффициент, снижающий влияние чрезмерно высоких или низких рангов.
7. Один k для каждого этапа
Значение Top-k обычно представляет собой глобальную константу, которая используется при первоначальном поиске, при объединении результатов и для финального запроса. Когда на первом этапе загружается лишь небольшое количество фрагментов, которые может вместить запрос, показатель воспроизводимости уже снижен до минимума до того, как ранжировщик сможет что-либо исправить: фрагмент, занявший 14-е место в результатах векторного поиска, так и не попадает в запрос. Противоположной ошибкой является передача сотен кандидатов в ранжировщик без последующей фильтрации, что приводит к потере времени и денег, а также к заполнению запроса слабыми данными. В таких условиях способность ЯИ к уделять внимание снижается (эффект «потери посередине»), и это незаметно сводит на нет преимущества, полученные в результате переранжирования.
Лучше рассматривать k как воронку. На первом этапе берут большой набор — примерно от 20 до 100 кандидатов, — чтобы у алгоритма реранкинга была возможность исправить ошибки первоначального сортирования, а затем оставляют небольшой финальный набор из примерно 3–8 элементов для последующей обработки. Каждое значение k на отдельных этапах необходимо настраивать отдельно с учетом набора для оценки, поскольку одно значение не может соответствовать обоим целям.
Два типа ошибок в ранжировании и эмбеддингах
8. Игнорирование реранкинга
Реранкинг требует дополнительного вызова сети или этапа обработки, что увеличивает задержку и, в случае облачных сервисов, ведет к дополнительным расходам. Под давлением сроков именно это первым удаляют, и порядок на первом этапе считается окончательным.
Векторный поиск первой стадии основан на бай-энкодерах, которые сжимают текстовый фрагмент в один фиксированный вектор ещё до поступления запроса. Именно это обеспечивает высокую скорость работы в масштабах, но ограничивает точность, поскольку теряется тонкая взаимосвязь между конкретным запросом и конкретным фрагментом текста. Кросс-энкодеры восстанавливают эту взаимосвязь путём одновременного анализа обоих элементов. В независимых отчётах за 2026 год указывается, что использование кросс-энкодеров для переранжирования является лучшим дополнением к системе с хорошей работой поиска первой стадии: типичным является улучшение точности или показателя NDCG на несколько пунктов, причём на сложных с лексической точки зрения наборах данных результаты достигают двадцати пунктов при дополнительной задержке менее 200 мс при разумных размерах пула данных. Один из клиентов-консалтинговых проектов отметил улучшение точности на 23 пункта благодаря переранжированию, что превышает эффект от изменения способов эмбеддинга или размера фрагментов текста. Как только гибридный поиск начнёт работать, следующим шагом будет применение кросс-энкодеров.
Изменение заключается в добавлении этапа переранжирования между процессом слияния данных и окончательным запросом. Для самостоятельной развертки без платы за каждый вызов популярным открытым кросс-кодером с хорошим мультиязычным покрытием является bge-reranker-v2-m3. API Cohere для переранжирования представляет собой стандартную альтернативу в управляемом формате, когда не требуется инфраструктура GPU. Оба решения интегрируются с LangChain и LlamaIndex:
from FlagEmbedding import FlagReranker
reranker = FlagReranker("BAAI/bge-reranker-v2-m3", use_fp16=True)
def rerank(query: str, candidates: list[str], top_k: int = 5) -> list[str]:
pairs = [[query, c] for c in candidates]
scores = reranker.compute_score(pairs, normalize=True)
ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True)
return [text for text, _ in ranked[:top_k]]
final_context = rerank(user_query, fused_candidates, top_k=5)
9. Общая модель вжимания на специализированном корпусе
Модель вжимания, поставляемая с фреймворком, часто сразу применяется к юридическому, медицинскому или финансовому корпусу текстов, что оправдывается несколькими ручными проверками. Модели универсального назначения обучаются на широком массиве веб- и энциклопедических текстов, поэтому они менее четко различают специализированную терминологию, чем модели, обученные на материалах конкретной области. Этот недостаток наиболее ощутим там, где ставки высоки. В регулируемых сферах небольшая ошибка, такая как использование описания стандартной процедуры вместо конкретного исключения, о котором спрашивали, приводит к ответу, который кажется правдоподобным, но на самом деле ошибочным, что хуже, чем явная неудача.
Перед сохранением результатов обязательно протестируйте по меньшей мере один адаптированный под конкретную область или отрегулированный инструмент встраивания на общем стандартном варианте из золотого набора. Если отрегулировать инструмент встраивания невозможно, кросс-кодер-переранжер, обученный на небольшом наборе маркированных запросов из конкретной области, часто позволяет быстрее и дешевле устранить большинство проблем, поскольку он исправляет ошибки первой стадии без необходимости повторного встраивания всего корпуса данных.
Ошибка, скрывающая остальные
10. Оплата за показы
Инфраструктура оценки кажется избыточной по сравнению с работой над функциями, и кажется, что достаточно просто взглянуть на несколько результатов, если демо выглядит хорошо. Однако именно она приносит наибольшие косвенные затраты, поскольку скрывает все остальные проблемы. Галлюцинации, обусловленные полученным контекстом, документы в неверном порядке и фрагменты, обрезанные именно в неправильном месте, невозможно надежно обнаружить путем просмотра результатов, и к тому времени, когда пользователи сообщают об этом, проблемы уже существуют в продакшене.
Решением является «золотой набор» из 50–200 типичных пар вопросов и ответов, охватывающих крайние случаи, такие как двусмысленная формулировка, вопросы, требующие двух документов для решения, и адверсарские перефразирования. Оценка проводится с использованием стандартной системы из двух частей. Работу модели по поиску оценивают по точности и воспроизводству контекста, а работу модели-генератора — по верности и степени релевантности ответа. В этой области доминируют две платформы, и команды часто объединяют их. Ragas — это стандартный инструмент для анализа метрик, а его синтетический генератор позволяет создать «золотой набор» на основе корпуса данных для дальнейшей доработки человеком. DeepEval, построенный на pytest, — это распространенный способ превращения оценки в реальный этап CI-процесса. Часто используется следующее разделение: Ragas для исследований и генерации данных, DeepEval — для проверки каждого pull-реквеста:
from deepeval import assert_test
from deepeval.metrics import FaithfulnessMetric, ContextualPrecisionMetric
from deepeval.test_case import LLMTestCase
def test_refund_policy_query():
test_case = LLMTestCase(
input="What is the refund window for the Pro plan?",
actual_output=rag_pipeline.run("What is the refund window for the Pro plan?"),
retrieval_context=rag_pipeline.last_retrieved_chunks,
expected_output="Pro plan purchases can be refunded within 14 days of purchase.",
)
faithfulness = FaithfulnessMetric(threshold=0.8)
precision = ContextualPrecisionMetric(threshold=0.7)
assert_test(test_case, [faithfulness, precision])
Внедрите подобный набор инструментов в CI, чтобы любые изменения, связанные с разбиением данных на части, заменой способов встраивания информации или обновлением базы знаний, которые ухудшают качество поиска, прерывали процесс сборки ещё до того, как это повлияет на рабочий день клиента.
Как ошибки различаются в зависимости от настроек
- Внутренний корпоративный поиск и системы вопросов и ответов к документам, самая распространённая конфигурация, в значительной степени зависят от гибридного метода поиска. Сотрудники вставляют номера заявок, коды правил и SKU вместе с вопросами на простом языке, но поиск, ориентированный только на поиск текста, упускает литеральные элементы вопросов.
- Боты поддержки клиентов в наибольшей степени выигрывают от переранжирования результатов поиска. Неправильный, но грамотно сформулированный ответ может привести к появлению заявки или потере аккаунта клиента, вместо того чтобы вызвать лишь равнодушие со стороны коллеги.
Выбор следующего шага
На этапе до запуска, когда ещё проверяется целесообразность использования технологии RAG, наилучшим стартом будет поиск только на основе векторов: его проще всего реализовать, и ответ на вопрос о подходящей архитектуре можно получить в течение дня. Как только появятся реальные запросы пользователей, необходимо проанализировать логи в поиске точных совпадений, таких как коды продуктов, идентификаторы тикетов и значения конфигурации. Если такие совпадения обнаружатся, прежде всего следует внедрить алгоритм BM25 с фьюжн-методом RRF, поскольку источники единогласно указывают на него как на самое значительное улучшение в процессе поиска, причем с большим отрывом. Далее идёт переранжирование запросов, когда гибридный поиск уже работает, и целью становится точность вместо простого количества найденных результатов. Этот подход дешёв по сравнению с получаемыми результатами и не требует пересоздания индекса. Использование моделей SPLADE или адаптированных под конкретную область эмбеддингов следует отложить для команд, у которых уже сформирована развитая система оценки и которые убедились, что сочетание гибридного поиска с переранжированием всё равно оставляет пробелы в качестве результатов, поскольку такие решения требуют больше усилий и технического обслуживания, и их сложно оправдать без базовых показателей эффективности.
Количество сотрудников и бюджет влияют на решение. При наличии двух инженеров использование готового API для переранжирования (обычно выбирается Cohere) выгоднее, чем разработка собственного кросс-кодера: при небольшом объеме трафика расходы незначительны по сравнению с временем работы GPU-серверов. Если уже есть персонал для MLOps и GPU, или объем трафика настолько велик, что начисление платы за каждый запрос становится значимой статьей расходов, более разумным решением будет использование открытой модели вроде bge-reranker-v2-m3.
Сколько все еще стоит хорошая система обработки
RAG — это не идеальное решение. Его главное преимущество заключается в опоре на внешние источники: ответы могут цитировать извлеченные данные вместо того, чтобы полагаться только на то, что запомнил модель, а база знаний может обновляться без переобучения. Однако дополнительные механизмы действительно увеличивают нагрузку на систему. Необходимо синхронизировать два индекса, использовать инструмент для переранжирования для выявления отклонений, иметь процедуру оценки для обеспечения качества результатов, а также схему разбиения текста на фрагменты, которую нужно перепроверять при изменении состава документов.
RAG также не устраняет галлюцинации. Он снижает количество вымышленной информации, возникающей из-за отсутствия знаний, но не влияет на ситуации, когда большая языковая модель неправильно интерпретирует или применяет предоставленный ей контекст. Метрики точности существуют потому, что понятия «опора на извлеченный контекст» и «правильность» являются разными характеристиками, и современные процедуры оценки учитывают обе из них.
Готовность к использованию
- Оценка в CI. Проводите тестирование с использованием Ragas и DeepEval для каждого запроса, изменения механизма поиска или базы знаний, а не только один раз при запуске.
- Синхронизация индексов. Обновляйте индексы BM25 и векторные индексы одновременно или по одному расписанию. Когда устаревший спарсинговый индекс используется вместе с новыми векторными представлениями, процесс поиска начинает отклоняться, что трудно заметить.
- Наблюдаемость. Фиксируйте все фрагменты данных, полученные при обработке каждого запроса, а не только окончательный ответ. Это позволяет без предположений определить, проблема связана с процессом поиска или с генерацией ответа.
- Учетные данные. Храните ключи API для переранжирования результатов и генерации векторных представлений вне репозитория и ротируйте их через стандартный менеджер секретов.
Краткий вывод
Посмотрите, что вернул поисковик, прежде чем менять запрос или модель. Девять из десяти ошибок (плохое разделение данных на части, отсутствие гибридного поиска, наивное объединение результатов, неправильный размер наборов кандидатов, пропуск переориентации рейтингов, использование непроверенной модели вкладки) — это проблемы поиска, которые можно решить с помощью соответствующих методов. Десятая ошибка — отсутствие оценки — и является причиной того, что первые девять так часто остаются незамеченными.
Ни одно из решений не требует наличия исследовательской команды. Добавление алгоритма BM25 рядом с существующим хранилищем векторов, замена метода смешивания оценок на RRF или отказ от повторной классификации между этапами объединения данных и генерации результата — всё это скорее задачи инженерной реализации, чем полной переработки системы. Каждый из этих подходов находит поддержку в независимых источниках, даже если цифры там расходятся. Практический старт: соберите две недели реальных запросов пользователей, подсчитайте, сколько из них содержат точные идентификаторы, которые могут быть размыты при использовании векторного поиска, и создайте набор из 50 запросов на основе уже имеющихся примеров неудач. Это требует меньше усилий, чем кажется, и позволяет определить, какие из десяти ошибок стоит дороже всего.
Связанные материалы
- Отладка тихих сбоев RAG: получение данных, разбиение на фрагменты, фильтры и оценка — Ответы, генерируемые с помощью RAG, могут казаться правильными, но при этом быть неверными. Руководство для разработчиков на Python по отслеживанию процессов получения данных, их разбиения на фрагменты, применения фильтров метаданных, оценки результатов, гибридного поиска и связывания информации с реальными данными.
- Гибридный подход RAG для юридических текстов: разбиение на фрагменты, алгоритм BM25, метод BGE и переоценка рангов — Пайплайн RAG для юридических исследований на основе Конституции Индии: разбиение текста на фрагменты вида «родитель-дочерний», поиск с использованием алгоритмов BM25 и BGE, объединение рангов, переоценка результатов с применением кросс-кодеров и расширение запросов; всё это протестировано на специальных тестовых данных.