Как ты борешься с галлюцинациями rag систем?

Когда системе задаётся вопрос по базе знаний, но в ней нет искомой информации.

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

Согласен, цепочка избыточна. Но иначе никак, т.к. у нас нет доступа к базам данных компаний))

Несколько LLM в параллель и сравнивать - пробовал.

В правилах соревнования не было прямого запрета на использование внешних источников, но это противоречит духу RAG Challenge, как по мне.

Валидировать конечный результат - не успел имплементировать, держу эту идею в голове к след конкурсу.

О, спасибо за инфу! То есть побороть это можно только при помощи таблицы соответствий кодов? Её где-то нагуглить надо, или она вшита в метаинфу pdf?

Да, это оказалось неприятной особенностью IBM WatsonX API. Для инференса своих локалок я юзаю vLLM с Outlines бэкендом

OpenAI. У них отличный эмбеддер и хорошие мультиязычные модели. Есть всякие YandexGPT и тому подобное, но я не зарывался в них

Спасибо)

почему использовали Llama и Gpt от OpenAI, а не DeepSeek?

Llama - потому что одна из номинаций была на открытые модели от IBM. Лама была одним из safe вариантов.

OpenAI - из-за их безумных лимитов. В некоторых пайплайнах у меня параллельно обрабатывалось по 800 запросов, из-за llm реранкинга

А, тут не подскажу. У локальных эмбеддинг моделей вообще всё печально. В чате LLM под капотом эту тему часто обсуждают, советую почитать

Да, экспериментировал с другими, рассматривал RRF и прочие. Оценивал условно на глаз после вычитки результатов LLM скоринга (reasoning поле сопровождающее скор помогает в этом).
Сначала вообще думал использовать чисто результаты llm скоринга.

Развесовка исходя из доверия каждой системе. Т.е. similarity score векторного поиска может скорректировать LLM скор, но не сильно, т.к. последний гораздо качественнее

Оценивался отдельно Retrieval и Generation. Больше инфы в канале у Рината и тут https://abdullin.com/erc/#r2

Чуть позже он выложит код скоринг системы.

123 балла из 133 максимальных

ну как вы описали с тысячами.

Замечу, этот момент вообще не очевиден для людей "не в теме", как и то, что цифра в скобках - это отрицательное значение.

В некоторых отчётах упоминание о том, что метрики приведены в тысячах, находится в начале секции на 40 страниц. И всё, больше нигде. И вот поди догадайся, надо ли домножать цифры на 1000. Есть, конечно эвристики, типа общих знаний о масштабе компании, что помогает интуитивно догадаться о порядке её доходов, но и это работает не всегда.

При создании валидационного сета натолкнулся на реальный случай, когда годовая выручка компании составила 214 долларов. Не тысяч, не миллионов. Лично перепроверил несколько раз, в т.ч. в других источниках, помимо отчёта.

Так что увы, для того, чтобы добрать несколько процентов точности из хвоста распределения, приходится учитывать подобные правила. Они применимы как к LLM, так и к "кожанным мешкам"

Согласен, промпты - это трудоёмкая часть. Но зачастую мучения с ними - это лишь прокси проблемы, не связанной с самим RAGом как таковым.

Неважно, как работает вопросно-ответная система - дилеммы и edge кейсы остаются те же. На том же примере, "Является ли отсутствие доказательства - доказательством отсутствия?"
Не всегда допустимо пустить решение таких вопросов на самотёк.

На разработку системы я потратил 150-200 часов. Но только потому, что я отнёсся к процессу как к обучению. Одно только тестирование десятков парсеров чего стоит.

Так-то разработать что-то подобное, когда уже есть опыт - не так уж долго и сложно.

Из всех pdf парсеров только Marker справляется с такими документами. И то, я не уверен, фиксит он как-то по умному, или просто детекит и OCR'ит всю страницу

А что в вашем понимании - экономичные? Локальные модели с небольшим количеством параметров? Или просто API модели с низким прайсом?

Да, это интересная идея. Я думаю, такой подход особенно раскроется с слабыми эмбеддинг моделями и небольшими LLMками.

Согласен, qdrant, chromadb, milvus были бы гораздо удобнее. FAISS - вообще не база данных, а библиотека для поиска)
Просто был готовый код под руками

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