Целью работы не было подмена понятия. Мы реализовали наиболее удобный сплиттер для наших данных и для проведения исследований. Overlap чанков в 15% действительно является рекомендацией, а склейка маленьких чанков кастомная.
При соединении подряд идущих маленьких чанков может теряться смысл. И чанки могут содержать информацию о двух разных темах. Особенность нашей структуры данных помогла ограничить такую склейку.
Это не "мы открыли заголовки в LangChain", а инженерная сборка цепочки, которая в нашем домене дала измеримый прирост.
Да, отдельные эвристики выглядят простыми - и это нормально: хорошие продакшен-решения часто состоят из простых вещей, которые правильно сшиты и замерены.
Пример составления бенчмарка предоставлен, любой желающий может создать бенчмарк под свои документы и провести тестирование.
Что подразумевает под собой "оценка RAG" - это релевантность найденных чанков. Что такое чанки? Это вырезки из текста, а не перефразированная информация. Следовательно не имеет никакого смысла при оценке сверять семантическую схожесть, когда у вас чанк является буквально частью текста из бенчмарка. Поэтому здесь просто сверяется перекрытие триграмм. Если перекрытие больше 80%, то чанк является релевантным. Порог в 80% связан с небольшим переформатированием структуры текста и добавлением breadcrumbles в начало чанка
Добавление реранкера в пайплайн не «неизбежно» повышает точность. Реранкер улучшает ранжирование, но итог зависит от качества кандидатов, домена, длины чанков, наличия шумов и т.д. У нас до реранкера уже был сделан пласт работы (метаданные, гибрид/RRF), и только потом реранкер дал финальный прирост.
Мы прямо написали, что на CPU было ~16 секунд и что критично запускать на GPU, а также указали оптимизацию до 4–5 секунд на CPU и <0.02 сек на RTX. Это не «умолчали», а наоборот — проговорили ограничение.
Про “пафосный заголовок / корпоративный отчёт”.
Тут уже не техническая критика, а стиль. Хабр — не журнал ВАК, статья описывает прикладной путь «как довести до результата». Если вам интересен и не понятен в реализации какой-либо из механизмов, вы скажите прямо, я подскажу как было реализовано изнутри
Тут зависит от того, как вы будете обрабатывать ваши данные и разбивать на чанки. Сложную структуру всегда можно представить в виде нескольких простых маленьких компонентов и научиться работать с ними.
Универсального метода нет, каждая структура требует своих доработок. В нашем случае, с нашими данным работает хорошо
Целью работы не было подмена понятия. Мы реализовали наиболее удобный сплиттер для наших данных и для проведения исследований. Overlap чанков в 15% действительно является рекомендацией, а склейка маленьких чанков кастомная.
При соединении подряд идущих маленьких чанков может теряться смысл. И чанки могут содержать информацию о двух разных темах. Особенность нашей структуры данных помогла ограничить такую склейку.
Это не "мы открыли заголовки в LangChain", а инженерная сборка цепочки, которая в нашем домене дала измеримый прирост.
Да, отдельные эвристики выглядят простыми - и это нормально: хорошие продакшен-решения часто состоят из простых вещей, которые правильно сшиты и замерены.
Пример составления бенчмарка предоставлен, любой желающий может создать бенчмарк под свои документы и провести тестирование.
Что подразумевает под собой "оценка RAG" - это релевантность найденных чанков. Что такое чанки? Это вырезки из текста, а не перефразированная информация. Следовательно не имеет никакого смысла при оценке сверять семантическую схожесть, когда у вас чанк является буквально частью текста из бенчмарка. Поэтому здесь просто сверяется перекрытие триграмм. Если перекрытие больше 80%, то чанк является релевантным. Порог в 80% связан с небольшим переформатированием структуры текста и добавлением breadcrumbles в начало чанка
Добавление реранкера в пайплайн не «неизбежно» повышает точность. Реранкер улучшает ранжирование, но итог зависит от качества кандидатов, домена, длины чанков, наличия шумов и т.д. У нас до реранкера уже был сделан пласт работы (метаданные, гибрид/RRF), и только потом реранкер дал финальный прирост.
Мы прямо написали, что на CPU было ~16 секунд и что критично запускать на GPU, а также указали оптимизацию до 4–5 секунд на CPU и <0.02 сек на RTX. Это не «умолчали», а наоборот — проговорили ограничение.
Про “пафосный заголовок / корпоративный отчёт”.
Тут уже не техническая критика, а стиль. Хабр — не журнал ВАК, статья описывает прикладной путь «как довести до результата». Если вам интересен и не понятен в реализации какой-либо из механизмов, вы скажите прямо, я подскажу как было реализовано изнутри
Это вопрос не про RAG, а про умение LLM понимать таблицы. Конкретно с текстовыми данными и с небольшими таблицами все работает хорошо.
Если вы хотите решать задачи с большими таблицами при помощи LLM, рекомендую вам ознакомиться с данной статьей: https://openreview.net/forum?id=IZnrCGF9WI
Тут зависит от того, как вы будете обрабатывать ваши данные и разбивать на чанки. Сложную структуру всегда можно представить в виде нескольких простых маленьких компонентов и научиться работать с ними.
Универсального метода нет, каждая структура требует своих доработок. В нашем случае, с нашими данным работает хорошо