Пройдите по пунктам, когда обдумываете новый ИИ-продукт
Шаг 1. А нужен ли фреймворк вообще?
Если на оба вопроса ответ «нет» — фреймворк не нужен, зовите API модели напрямую:
☐ Модель должна отвечать по вашим данным (база знаний, документы, транскрипты)?
☐ В приложении есть цепочка шагов, которые хочется тестировать и менять по отдельности?
Шаг 2. Признаки «да, Haystack»
Чем больше галочек, тем увереннее выбор:
☐ Ядро продукта — поиск и ответы по данным (RAG, умный поиск, вопросы-ответы)
☐ Нужен качественный поиск: по смыслу, по словам или гибрид с ранжированием
☐ Важно менять модели/базы без переписывания приложения
☐ Продукт пойдёт в продакшн: нужны логи, оценка качества, предсказуемость
☐ Хочется self-hosted на своих серверах, без привязки к чужому облаку
☐ Есть кому писать Python (или это делает Claude)
Шаг 3. Признаки «посмотрите на альтернативы»
☐ Ядро — сложное агентное поведение с ветвистой логикой состояний → LangGraph
☐ Главная боль — быстро подключить десятки источников данных → LlamaIndex
☐ Задача — склеить сервисы без кода (формы → таблица → рассылка) → n8n
☐ Один-два запроса к модели, своих данных нет → прямой вызов API
Шаг 4. Проверка на трезвость
☐ Готовы к тому, что это Python-сервис: для JS-приложений — отдельный бэкенд с API
☐ Простые вещи потребуют чуть больше кода, чем в «магических» фреймворках — зато явно и надёжно
☐ Начнёте с пайплайна, а не с агента (агент — когда фиксированный маршрут перестал справляться)
☐ Начнёте с простого хранилища (InMemory → pgvector), мигрируете по мере роста
Правило одной строкой
Поиск и ответы по данным — Haystack. Ветвистые агенты — LangGraph. Склейка источников — LlamaIndex. Склейка сервисов — n8n. Ничего из этого — просто API модели.
💬 Сомневаетесь по конкретному проекту? Опишите его Клоду и попросите пройтись по этому чек-листу вместе.