Comments 6
Спасибо за статью , все чётко и с конкретными примерами по каждому пункту
А зачем нужен реранк в прведённом случае? Ведь, поиск, с одной стороны, вернёт score, которые считаются как мера близости к вектору вопроса. А с другой - если мы выбираем 3-5 чанков, то отвечающая ЛЛМ сама разберётся, что ей релевантно, а что нет - можно вместе с мусором прогрузить.
Реранкер, наверное, более интересен, если, например, грепнули сайтик, или длинный документ и чтобы из него ради разового запроса не строить вектора и потом в них не искать, а сразу получить сортировку.
Спасибо за статью, добавлю: есть неплохой фреймворк LlamaIndex для работы с RAG-системами + интересная статья про KAG (Knowledge Augmented Generation), а также обзор продвинутых "агентских" техник RAG'а
Благодарю за хорошо структурированную статью.
Некоторые документы переполнены лишней информацией.
Особенно это относится к сильно зарегулированным областям, например, банкинг.
То есть:
- начало документа - длинная борода с разными дисклеймерами,
- затем страница собственно сути документа
- и снова длинная борода повторяющейся фигни, которую обязаны повторять.
Вопрос: есть ли смысл для повышения эффективности векторизации извлекать из документов только суть?
С таким подходом, с одной стороны, усложняется ссылка на документ, а с другой стороны, повышается эффективность поиска, а размер векторной базы значительно сокращается.
Действительно, при однотипной структуре документов целесообразно применение предобработки данных до векторизации с целью сократить объем БД и повысить релевантность выдачи, например при помощи парсинга, суммаризации и т.п методов, основной критерий это сохранение качества извлекаемых из документов данных, что в некоторых доменах, например медицина может стать критичным
В статье упоминаются ключевые методы, которые влияют на точность RAG, но не приводится явных метрик, cможете сказать какие метрики вы использовали?
Методы построения RAG систем