Хочу поделиться своим опытом через данный пост.

Вижу много проектов, где RAG используют просто как поиск по базе данных. Давайте разберёмся, когда это оправдано, а когда - перебор.

Начнём с главного вопроса: зачем вам RAG?

RAG имеет смысл, когда нужно общаться с LLM о ваших данных - задавать сложные вопросы, получать аналитику, генерировать инсайты. Если же задача просто найти информацию в базе - это совсем другая история.

Если же, к примеру, у вас данные лежат в PostgreSQL То есть данные лежат в таблицах, колонках и строках. Вам нужен поиск. И тут вы думаете: "А давайте добавим pgvector и построим RAG, чтобы был крутой поиск!"

Здесь нужно очень хорошо подумать:

RAG с векторной БД не так просто настроить так, чтобы ошибок практически не было. Что очень важно - вы усложняете архитектуру там, где можно обойтись проще, выплывают дополнительные расходы, потому что делать поиск по RAG - стоит денег, времени и т.д.

Что делать вместо этого:

Для структурированных данных в PostgreSQL - можно использовать Full-Text Search (FTS). Это быстрее, дешевле, проще в настройке и поддержке, и идеально подходит для задачи поиска.

По итогу, возможно для кого-то это очевидные вещи, но я реально видел много проектов, где тот же RAG служит тупо как поиск по документам в базе данных - это не его предназначение, особенно если данные структурированные.

Плюс в недавнем проекте сам думал имплементировать поиск по базе данных и первая идея пришла в голову - сразу сделать RAG, но подумав еще немного понял, что чисто для поиска - это не лучшее решение.

Хотел сказать, что не усложняйте системы там, где это не надо. Если реально можно обойтись без LLM в системе - лучше обойтись без LLM.

Сейчас занимаюсь разными проектами, много таких мыслей выплывает. Поэтому если этот пост был интересен и вам интересно почитать что-то подобное от меня - дайте знать реакциями + комментами под данным постом.

#AI #RAG #n8n #AI_Agent #supabase #python #langchain #langgraph #fastapi #aiassistant #agi