Поиск (Retrieve)

Нода Поиск выполняет семантический поиск по базе знаний организации и возвращает наиболее релевантные фрагменты. Это реализация подхода RAG (Retrieval-Augmented Generation) -- обогащение контекста LLM актуальной информацией из ваших документов.

Поиск выполняется через retrieval-пайплайн (тип RETRIEVAL), который определяет, какая модель эмбеддингов используется, в какой коллекции искать и применяется ли реранжирование.

Парная нода -- Индексация: Ingest (через INGESTION-пайплайн пишет) → ... → Retrieve (через RETRIEVAL-пайплайн читает).

Назначение

Поиск релевантной информации в корпоративных документах
Обогащение контекста агента перед генерацией ответа
Построение вопросно-ответных систем на основе документации
Проверка фактов по базе знаний

Настройки

Retrieval-пайплайн

Обязательное поле. Список заполняется активными пайплайнами организации с типом RETRIEVAL. Пайплайн определяет:

Модель эмбеддингов для запроса (должна быть совместима с пайплайном, которым был проиндексирован документ)
Коллекцию в векторном хранилище (Qdrant)
Применяется ли реранжирование, и какой моделью
Дополнительные фильтры на уровне пайплайна

Создать или отредактировать пайплайны можно в разделе База знаний → Пайплайны.

Без выбранного пайплайна нода падает с ConfigurationError ещё до обращения к rag-service.

Поисковый запрос

Текст запроса для семантического поиска. Поддерживает подстановку переменных через {{переменная}}:

{{input.question}}

Кнопка справа от поля позволяет вставить ссылку на переменную из workflow.

Если поле оставлено пустым, нода берёт вывод предыдущей ноды:

Строковый выход upstream-ноды используется как запрос напрямую
Поле query / text / question / output объекта-выхода
str(input_data) -- крайний случай

Максимум результатов

Количество возвращаемых фрагментов. По умолчанию: 5.

Чем больше результатов, тем полнее контекст, но тем больше токенов уйдёт на обработку downstream-нодой (LLM или агентом).

Порог релевантности

Минимальная косинусная близость для включения фрагмента в результат. Диапазон: 0.0 -- 1.0, по умолчанию 0.7.

Значение	Поведение
0.9	Только высокорелевантные результаты, риск пустого ответа
0.7	Баланс полноты и точности (рекомендуется)
0.5	Широкий поиск, включая частично релевантные
0.0	Возвращает все, что нашлось -- порог отключён

Метаданные

Помимо текста запроса, нода автоматически передаёт в пайплайн:

organization_id -- из контекста workflow, обязателен для изоляции
project_id -- из контекста workflow, для фильтрации по проекту

Входные данные

Текст запроса из настроек ноды или из выхода предыдущей ноды (через fallback-цепочку, см. раздел «Поисковый запрос»).

Выходные данные

{
  "success": true,
  "__success": true,
  "__error": false,
  "query": "исходный текст запроса",
  "results": [
    {
      "text": "найденный фрагмент",
      "score": 0.89,
      "source_id": "src_abc123",
      "metadata": {
        "filename": "manual.pdf",
        "page": 12,
        "project_ids": ["proj_x"]
      }
    }
  ],
  "count": 3,
  "pipelineId": "pl_default"
}

Поле	Описание
`query`	Текст запроса после подстановки переменных
`results[]`	Массив фрагментов в порядке убывания релевантности
`results[].text`	Сам найденный фрагмент текста
`results[].score`	Оценка релевантности (0.0--1.0). Зависит от пайплайна: после реранжирования это финальная оценка
`results[].source_id`	ID источника, из которого пришёл фрагмент
`results[].metadata`	Метаданные документа (имя файла, страница, теги, project_ids и т.д.)
`count`	Длина `results[]` -- удобно для условных переходов
`pipelineId`	Использованный пайплайн (для отладки и трейсинга)

При ошибке:

{
  "success": false,
  "__success": false,
  "__error": true,
  "error": "rag-service returned HTTP 404",
  "errorType": "APIError",
  "status": 404,
  "results": []
}

Возможные значения errorType: ConfigurationError (нет pipelineId, нет organization_id, пустой запрос), APIError (ошибка от rag-service), TimeoutError (rag-service не ответил за 30 секунд), и имя класса исключения для прочих случаев.

Подключения

Вход: один вход (слева)
Выход: один выход output (справа)

Примеры использования

Ответы на вопросы по документации

Классический QA-сценарий:

Старт -- пользователь задаёт вопрос ({{input.question}}).
Поиск
- Retrieval-пайплайн: default-retrieval
- Поисковый запрос: {{input.question}}
- Max results: 5
- Score threshold: 0.7

Сообщение -- собрать промпт с контекстом:

Ответь на вопрос пользователя, используя контекст ниже.

Контекст:
{{lastOutput.results}}

Вопрос: {{input.question}}

LLM или Агент -- генерация ответа.

Условный путь на основе релевантности

Если ничего не нашлось -- запросить уточнение у пользователя:

Поиск -- score_threshold: 0.75.
If/else -- условие {{lastOutput.count}} == 0.
Branch true -- сообщение «Не нашёл по вашему запросу, уточните, пожалуйста».
Branch false -- стандартный RAG-ответ.

Проверка фактов

Высокий порог релевантности, минимум результатов:

Retrieval-пайплайн: facts-strict
Поисковый запрос: {{lastOutput.claim}}
Max results: 3
Score threshold: 0.85

Мультиисточниковый поиск

Несколько Поиск-нод с разными пайплайнами, результаты объединяются:

Поиск (техдокументация) -- пайплайн tech-docs.
Поиск (FAQ) -- пайплайн faq-pipeline (например, с реранжированием и return_field=answer).
Функция -- мерж результатов с дедупликацией и сортировкой по score.
Агент -- ответ пользователю.

Связь с другими нодами

Нода	Как взаимодействует
Индексация (Ingest)	Парная нода. Кладёт текст в KB; через какое-то время этот текст станет видим Поиску
OCR	Распознаёт документ → передаёт в Ingest → позже находится через Поиск
Агент	Может вызывать `search_knowledge_base` инструмент (под капотом -- тот же retrieval-пайплайн)
LLM	Получает результаты Поиска как контекст для генерации
ForEach	Можно итерироваться по `results[]` для построчной обработки фрагментов

Подбор retrieval-пайплайна

Эмбеддинги в запросе должны быть совместимы с эмбеддингами, которыми был проиндексирован документ. Если документы загружались через OpenAI ada-002, а Поиск использует text-embedding-3-small -- они не найдутся. Пайплайны (ingestion и retrieval) должны использовать одну модель эмбеддингов и одну Qdrant-коллекцию.

Реранжирование

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

Async-задержка после Ingest

Только что проиндексированный документ может не появиться в результатах Поиска сразу -- индексация выполняется в фоне через Celery-воркер rag-service. Между Ingest и Retrieve в одном workflow обычно стоит разрыв (другой запуск, ожидание подтверждения от пользователя и т.д.). Для интерактивных «залей и сразу спрашивай» -- предупредите пользователя об ожидании или разделите на два workflow.

Изоляция между проектами

project_id автоматически передаётся в пайплайн как фильтр. Документы, загруженные в одном проекте, не находятся в другом -- даже в рамках одной организации. Это поведение определяется пайплайном (фильтр project_ids) и в большинстве дефолтных пайплайнов включено.

Назначение​

Настройки​

Retrieval-пайплайн​

Поисковый запрос​

Максимум результатов​

Порог релевантности​

Метаданные​

Входные данные​

Выходные данные​

Подключения​

Примеры использования​

Ответы на вопросы по документации​

Условный путь на основе релевантности​

Проверка фактов​

Мультиисточниковый поиск​

Связь с другими нодами​