RAGFlow: когда RAG встречает Agentic Workflow

Последние полгода в AI-тулзах чётко прослеживается тренд: голые RAG-системы уже не катят. Ожидание — что движок не просто найдёт релевантные чанки, но и как-то их обработает перед подачей в LLM. Именно здесь RAGFlow пытается занять нишу, добавляя агентную логику поверх классического retrieval pipeline.

Из чего собран RAGFlow

По факту это Python-библиотека, которая под капотом использует:

1. Retrieval — классический векторный поиск через FAISS или аналоги
2. Pre-processing agents — цепочка мелких агентов для очистки и трансформации данных
3. Routing layer — определяет, нужно ли вообще лезть в базу знаний или хватит дефолтного ответа LLM

Главный козырь — гибкость в настройке пайплайна. Вот пример минимального сетапа:

from ragflow import RAGPipeline

pipeline = RAGPipeline(
    retriever="faiss",
    cleaning_agents=["remove_duplicates", "extract_key_phrases"],
    routing_threshold=0.7
)

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

Где реально полезно

Из своего опыта внедрения выделил три сценария, где RAGFlow даёт ощутимый прирост:

1. Динамические FAQ-системы
   Когда база ответов постоянно обновляется (например, документация API), встроенные агенты для дедупликации и нормализации запросов снижают количество мусорных срабатываний на 20-30%.

2. Мультимодальные цепочки
   Хотя движок заточен под текст, его API позволяет впихнуть кастомных агентов для обработки изображений/таблиц перед тем, как данные уйдут в LLM.

3. Снижение costs на больших контекстах
   За счёт умного роутинга система может избегать дорогих запросов к LLM, если уверена, что ответ и так лежит в первых N релевантных чанках.

Подводные грабли

После недели тестов на продакшн-подобных нагрузках вылезли типичные боли любого RAG-решения:

• Перформанс на больших объёмах
  Даже с FAISS поиск по 500k+ документов начинает требовать GPU для адекватной latency. Заявленная поддержка кластеризации пока сыровата.

• Оверрайтинг агентов
  Встроенные cleaning-агенты иногда слишком агрессивны — вырезают ключевые термины из технической документации. Приходится кастомизировать.

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

Для кого это

RAGFlow не будет вашим серебряным патроном, но отлично подойдёт, если:

• Уже используете RAG и хотите добавить agentic workflow без полного рефакторинга
• Часто экспериментируете с разными preprocessing-стратегиями
• Готовы мириться с необходимостью тонкой настройки под свои данные

Сейчас движок явно переживает хайповую фазу (662 звезды за неделю — серьёзно). Но под капотом достаточно здравых идей, чтобы его протестировать в следующем POC. Главное — не верить маркетингу слепо и сразу закладывать время на кастомизацию агентов под свою специфику.

Источник: https://github.com/infiniflow/ragflow