Нужна единственная метрика -процент правильных ответов с точки зрения эксперта предметной области. Все остальные - вспомогательные и стоит им уделять внимание только если вы ТОЧНО уверены, что они повышают эту главную. Если у вас в базе знаний (вокруг которой rag) нет правильного ответа на конкретный вопрос, то никаким повышением context precision вы это не решите. 2. Главной проблемой после отсутствия информации в базе является выдача релевантных чанков (тех самых, в которых содержится ответ на вопрос пользователя и если которых в принципе нет, то разговаривать вообще не о чем). Простые методы типа топ-к не работают. И тут только два пути - либо повышать это к, тем самым увеличивая денежные затраты на каждый промпт - в принципе рабочий вариант. Либо усложняя алгориьмы. В подавляющем большинстве кейсов (за исключением пожалуй случаев, когда rag нужен на сильно структурированных данных типа sql баз) оптимальным является parential retrievement. Он практически гарантирует, что если в бз есть правильный ответ на вопрос - модель его выдаст пользователю. Его суть: делаем две таблицы чанков: small и large. Large - абзац, таблица целиком и тп - семантически законченный кусок знаний. Small - разбитый на части large чанк, по длинне максимально близкий средней длине вопроса пользователя. Как правило, одно предложение.
Отличная работа! Но хотелось бы меньше кастомизаций и большей универсальности (в реальную систему не только подобные таблицы будут подаваться скорее всего). Для нас сейчас оптимальный по соотношению затраты/качество является следующий вариант: Ключевой момент: parential retrievement. Маленькие чанки в идеале должны быть близки к размеру среднего запроса пользователя. На практике - абзац или ячейка таблицы. Ячейка таблицы как правило меньше среднего абзаца, потому ячейки больше попадают в топ, но это не баг, а фича, так как таблицы более сложный элемент. Большие чанки - абзац или таблица целиком или страница презентации. Да, таблицы парсятся в json, показало себя лучше, чем markdown. Все, такой подход даёт отличную итоговую точность, но, конечно, когда таблица большая, как в ваших примерах, он вылетает по лимиту токенов. Поэтому приходится усложнять. Во-первых, если таблица более двух страниц, то большой чанк тогда - пара страниц таблицы. В принципе достаточно только заголовки перенеси в каждую страницу. Далее, очень большие таблицы, как правило, с простой структурой. Объединения рандомных ячеек, когда, например, где то посередине три ячейки объединили в одну - такое в больших таблицах крайне редко. Поэтому совсем большие плоские таблицы просто конвертируем в pandas dataframe, а llm просим сделать запрос на фильтрацию датафрейма...
Нужна единственная метрика -процент правильных ответов с точки зрения эксперта предметной области. Все остальные - вспомогательные и стоит им уделять внимание только если вы ТОЧНО уверены, что они повышают эту главную. Если у вас в базе знаний (вокруг которой rag) нет правильного ответа на конкретный вопрос, то никаким повышением context precision вы это не решите. 2. Главной проблемой после отсутствия информации в базе является выдача релевантных чанков (тех самых, в которых содержится ответ на вопрос пользователя и если которых в принципе нет, то разговаривать вообще не о чем). Простые методы типа топ-к не работают. И тут только два пути - либо повышать это к, тем самым увеличивая денежные затраты на каждый промпт - в принципе рабочий вариант. Либо усложняя алгориьмы. В подавляющем большинстве кейсов (за исключением пожалуй случаев, когда rag нужен на сильно структурированных данных типа sql баз) оптимальным является parential retrievement. Он практически гарантирует, что если в бз есть правильный ответ на вопрос - модель его выдаст пользователю. Его суть: делаем две таблицы чанков: small и large. Large - абзац, таблица целиком и тп - семантически законченный кусок знаний. Small - разбитый на части large чанк, по длинне максимально близкий средней длине вопроса пользователя. Как правило, одно предложение.
Отличная работа! Но хотелось бы меньше кастомизаций и большей универсальности (в реальную систему не только подобные таблицы будут подаваться скорее всего). Для нас сейчас оптимальный по соотношению затраты/качество является следующий вариант: Ключевой момент: parential retrievement. Маленькие чанки в идеале должны быть близки к размеру среднего запроса пользователя. На практике - абзац или ячейка таблицы. Ячейка таблицы как правило меньше среднего абзаца, потому ячейки больше попадают в топ, но это не баг, а фича, так как таблицы более сложный элемент. Большие чанки - абзац или таблица целиком или страница презентации. Да, таблицы парсятся в json, показало себя лучше, чем markdown. Все, такой подход даёт отличную итоговую точность, но, конечно, когда таблица большая, как в ваших примерах, он вылетает по лимиту токенов. Поэтому приходится усложнять. Во-первых, если таблица более двух страниц, то большой чанк тогда - пара страниц таблицы. В принципе достаточно только заголовки перенеси в каждую страницу. Далее, очень большие таблицы, как правило, с простой структурой. Объединения рандомных ячеек, когда, например, где то посередине три ячейки объединили в одну - такое в больших таблицах крайне редко. Поэтому совсем большие плоские таблицы просто конвертируем в pandas dataframe, а llm просим сделать запрос на фильтрацию датафрейма...