Десять помилок у пошуку в продакшн-системах RAG та способи виправлення кожної з них.
Від розміру частин та перекриття до гібридних пошуків, RRF, переранкінгу, вибору ембеддингів та оцінки CI: десять помилок у пошуку, що призводять до неправильних відповідей RAG, та способи їх виправлення.
Один з чат-ботів підтримки колись чудовою прозою пояснив неправильну політику повернення грошей. Алгоритм знайшов абзац, у якому слово „повернення грошей“ зустрічалося чотири рази. Він був тематично пов’язаний та описував припинену лінійку продуктів. Штучний інтелект зробив те, що йому було сказано — впевнено відповісти на основі наданого контексту. Ніхто не повідомив йому, що контекст був неправильним.
Саме так виглядає більшість помилок типу 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). У третьому порівнянні було виявлено, що добре налаштований фіксований розмір може дорівнювати чи перевершувати семантичне розділення на реальних наборах даних, що узгоджується з фіксованими уривками по 100 слів, використаними у початковій статті про RAG.
Жодна стратегія не є ефективною скрізь. Усі джерела погоджуються, що проблема полягає не у виборі розділення фіксованого розміру, а у виборі будь-якої окремої стратегії без перевірки альтернатив на реальному корпусі даних.
Практичним рішенням є вимірювання замість теоретизування. Зіберіть від 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. Ігнорування власної структури документа
Розглядати кожен файл як єдиний блок простіше, чи то це посібник API у форматі Markdown, договір із пронумерованими пунктами чи фінансовий звіт із великою кількістю таблиць, але розділення без урахування структури часто призводить до того, що заголовок відокремлюється від відповідного розділу чи таблиця — від абзацу, який її пояснює. Типовою наслідком є розділення опису функції від її списку параметрів, тож запит щодо цієї функції повертає лише частину відповіді.
Рішення полягає спочатку у розділенні за структурою — за заголовками, розділами, списками та таблицями, а розділення за розміром використовувати лише всередині тих розділів, які залишаються занадто великими. До середини 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 та косинусові подібності походять з необмежених, різної форми розподілів, тож нормалізація типу min-max є крихкою. Один документ-відхилення, який повторює термін запиту десятки разів, може після нормалізації притиснути всі інші оцінки 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 Rerank від 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 request:
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, щоб будь-яка зміна, пов’язана з розділенням інформації на частини, заміною елементів вбудовування чи оновленням бази знань, яка погіршує процес пошуку, зупиняла процес будування, перш ніж це зіпсує день клієнта.
Як помилки відрізняються залежно від налаштувань
- Внутрішній пошук у корпораціях та системи Q&A для документів, найпоширеніша конфігурація, сильно залежать від гібридного методу пошуку. Співробітники вставляють номери заявок, коди правил та SKU разом із запитаннями простою мовою, але пошук, заснований лише на тексті, не бере до уваги буквальну частину запитання.
- Боти підтримки клієнтів найбільше виграють від переранжування результатів. Неправильна, але ввічлива відповідь тут може призвести до створення заявки чи втрати облікового запису, замість того, щоб співробітник просто проігнорував запитання.
Вибір наступного кроку
На етапі перед запуском, або поки ще перевіряється, чи є RAG взагалі придатним, пошук лише за векторами є правильним початком: його найлегше створити, і він дає відповідь на питання щодо архітектури вже протягом дня. Як тільки з’являються запити справжніх користувачів, необхідно проаналізувати журнали за записами точних збігів, такими як коди продуктів, ідентифікатори тикетів та значення конфігурації. Якщо такі записи знаходяться, спочатку слід додати алгоритм BM25 у поєднанні з RRF, оскільки джерела постійно вказують на нього як на найбільше покращення ефективності пошуку, і to з великим відривом. Після цього настає етап переранжування, коли гібридний пошук починає працювати, а метою є точність, а не просто кількість знайдених результатів. Цей підхід є недорогим за свої результати та не вимагає перебудови індексу. Використання 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 для пошуку, об’єднання рейтингів результатів, переоцінка через крос-енкодери та розширення запитів; всі етапи протестовані на спеціалізованих тестах.