Comments 17
Когда происходит разбивка на фрагменты, естественным образом должен возникнуть вопрос: а откуда, собственно, этот фрагмент взят? То есть, надо иметь ссылку не просто на 750-страничный документ, а ссылку либо на раздел/главу/параграф в этом документе, или, на худой конец, на номер страницы в PDF/DOC/ODT файле.
Есть ли какой-либо способ получать именно такую ссылку, чтобы показывать пользователю в ответе используемые материалы не просто:
.
Найдены документы:
1 . Питон_для_чайников.pdf
2 . Этот_сумасшедший_змей.pdf
а
Найдены документы:
1 . Питон_для_чайников.pdf,
Часть II. Системное программирование,
Глава 3. Контекст выполнения сценариев,
Перенаправление потоков ввода-вывода
2 . Этот_сумасшедший_змей.pdf
стр. 255, 897
.
Возможно, должен быть какой-то стандарт записи такого адреса. И еще надо иметь возможность открыть документ именно на этом месте с помощью, конечно, OpenSource решения.
Согласен, у каждого документа нужно собирать реквизиты документа, и оглавление, и помечать каждый кусок текста в базе ссылкой на этот документ, в идеале на главу/раздел.
Но, насколько я понимаю, чтобы такое делать, проще пульнуть документ в LLM с большим окном токенов, и получить оттуда данные в типовом формате. См. мою статью с таким разбором: https://habr.com/ru/articles/879876/
Далее, когда мы имеем оглавление, берем раздел за разделом, и какой объем раздела сохранять в один кусок информации? Разумеется, минимальный осмысленный объем. Иногда это абзац, но иногда, и два, и три, иначе потеряется смысл... Вот здесь без LLM и хорошего промпта уже не обойтись. Возможно, при этом еще и немного переписывать, отжимая из текста воду.
А еще стоит вопрос сохранения рисунков, таблиц и формул...
Еще нужно создать граф связей между пересекающимися данными в чанках. И так, как описано в статье, создание dataset для rag в формате вопрос - ответ , Claude.ai делать не рекомендует.
Интересное утверждение...
проведи фактчекинг: создание dataset для rag в формате вопрос - ответ , Claude.ai делать не рекомендует
Ответ Qwen3max
На основе проведённого поиска нет подтверждения утверждению, что Claude.ai официально не рекомендует создавать датасеты для RAG в формате вопрос–ответ.
Напротив, в документации и практике, связанной с использованием Claude (включая интеграцию с RAG), формат вопрос–ответ активно применяется:
Для оценки качества RAG-систем, включая те, что используют Claude, часто используются синтетические вопросно-ответные пары .
В общей методологии построения и оценки RAG-систем стандартным является датасет, содержащий триплеты: (контекст, запрос, ответ) .
Примеры использования собственных датасетов для RAG с загрузкой из CSV (включая Q&A-формат) также существуют в сообществе .
Сама платформа Claude (в частности, в Enterprise-версиях) поддерживает RAG и использует загруженные документы как источник знаний для генерации ответов на вопросы пользователей .
Таким образом, утверждение о том, что «Claude.ai не рекомендует создавать dataset для RAG в формате вопрос–ответ», не подтверждается официальными источниками или документацией. Наоборот — такой формат считается стандартным для оценки и обучения RAG-систем, включая те, что используют Claude.
Ответ DeepSeek
🔍 Проверка утверждения
Утверждение о том, что Claude.ai не рекомендует создавать dataset для RAG в формате "вопрос-ответ", не находит подтверждения в результатах поиска.
· На официальной странице Claude.ai представлены примеры запросов, с которыми пользователи могут обращаться к ассистенту, включая задачи по анализу кода, улучшению стиля письма и объяснению сложных тем. Прямых указаний или рекомендаций против создания датасетов для RAG на странице нет.
· В одном из результатов поиска, где перечислены продукты для работы с данными, даже упоминается, что инструмент "CamelAI" предназначен для "интеллектуального анализа данных без SQL-запросов", что косвенно говорит о возможности использования ИИ-ассистентов для работы с данными.
💡 Что говорят эксперты о датасетах для RAG
Хотя напрямую ваш запрос не подтвердился, в найденных источниках подробно обсуждается важность качества данных для RAG-систем и приводятся рекомендации.
· Важность качества данных: Качество набора данных — это основа точности RAG-системы. Плохо структурированные данные могут приводить к неверным или бессвязным ответам.
· Структурирование данных: Для эффективной работы RAG данные должны быть правильно сегментированы на фрагменты (чанки), снабжены метаданными и преобразованы в векторные представления (эмбеддинги).
· Подходы к созданию датасетов: Создание датасета для RAG — это не просто сбор пар "вопрос-ответ". Процесс требует контекстного структурирования, анализа значимости и постоянного улучшения для обеспечения точности поиска и генерации.
💎 Заключение
Таким образом, утверждение о нерекомендовании Claude.ai создания QA-датасетов для RAG не соответствует информации из предоставленных источников. Напротив, общая идея статей подчеркивает, что качественные датасеты, независимо от способа их создания, являются краеугольным камнем успешной RAG-системы.
Задайте claude.ai вопрос "Почему не стоит делать rag по принципу вопрос ответ". Ответ Вас удивит:"
Почему RAG в формате "вопрос-ответ" — плохая идея
Отличный вопрос! Многие начинающие делают датасет в формате FAQ и потом удивляются, почему система работает плохо. Вот почему это антипаттерн:.... "
Задайте claude.ai вопрос "Почему стоит делать rag по принципу вопрос ответ?" и Вас ответ тоже удивит. Вообще GPT дадут ответ на любой вопрос, вопрос только к степени бредовости. Скорее надо просить какие-нибудь CONS/PROS и сравнение подходов. Когда Вы просите подтвердить какую-нибудь идею, он подтвердит.
Если у нас есть 10 версий скажем API и соответственно 10 версий похожих PDF - что будет в ответе? Случайная компиляция из нескольких документов разных версий?
В ответе (вернее в обогащенном запросе к LLM) будет пять одинаковых фрагментов из разных версий (наиболее близких по вектору) - вместо пяти разных фрагментов (пять - потому что запрашивается пять "лучших" результатов).
А самое интересное - между фрагментами теряется контекст, так что даже зная, что эта информация есть в документе, ее можно не найти - просто потому что заголовок и описание могут быть отделены от фрагмента с нужной информацией.
Например, описание "что нельзя делать со стиралкой" - слово "стиралка" не в каждом абзаце есть или даже главе. А если и встречаются - то используются синонимы вроде "устройство". Человек понимает по контексту, что устройство - это устройство из заголовка (т.е. стиралка). А RAG такие нюансы не учитывает.
Так что предостережение "Не использовать на животных" просто не попадет в контекст вопроса "можно ли стирать кошку в стиралке?". Но вполне может попасть описание режима стирки "Шерсть".
На каком объеме данных трестировался RAG?
Либо можно установить dify и все сделать почти вообще без кода
Очередная RAG система Hello, World которая не имеет применения в реальной жизни. Тут уже писали про "стиралку" и версионность выше, я дополню.
Так же вопросы:
1. Что с мультиязычностью (EN, RU, ES, IT, FR) и как это обрабатывается, опять же в контексте в том числе? Если я задал вопрос по русски, а текст содержащий ответ на английском?
2. Как обрабатываются документы со сложной структурой страницы. Да же банально книги и инфойсы бывают 2-3 колоночные, иметь сноски, эпиграфы и тд.
3. Если документ обновляется, как обрабатывать новые версии и удалять старые? Если в документе на 1000 страниц поменялся 1 абзац?
Кстати интересно, если ли RAG, который еще картинки показывает? Ну ты запросил "схема синхофазатрона" и он находит картинку в документе, допустим она была подписана правильно.
могу ошибаться, но вектора неязыкозависимы.
Конечно языкозависимы - все зависит от модели, которой производятся вектора. Более того, они зависимы от предметной области, на которой модель специализируется. Если это модель общего назначения, то она будет плохо работать, например, на специфичных математических текстах. На mteb это все хорошо видно по фильтрам и наборам тестов.
Раг, конечно, игрушечный - помимо вопросов к выбору моделей эмбеддингов есть еще куча вопросов, например к сплиттеру - корректно ли recursivecharactertextsplitter обработает markdown? Он ведь предназначен для обычного текста.
Также с конвертером - markitdown не способен обработать нетекстовые pdf, также как и нетекстовые djvu, tiff, и прочие image-подобные форматы.
Вместоfromlangchain.prompts import PromptTemplate
надоиспользоватьfrom langchain_core.prompts import PromptTemplate
А где тесты качества RAG как поисковой системы? Как же можно считать его построенным , если тестирование на качество не сделано. В итоге какая точность и полнота ?
Как я построил RAG-систему за вечер с помощью 5 open source-инструментов