Клиент и база знаний могут описывать одну задачу разными словами. Поиск по совпадениям пропускает подходящие материалы, а сравнение по смыслу позволяет их найти. В Staqflow появился узел «Эмбеддинги»: он преобразует текст в числовой вектор для поиска, классификации обращений и работы с векторными базами.
Эмбеддинг — числовое представление текста. Близкие по смыслу тексты имеют близкие векторы; расстояние между ними используют для отбора документов или сравнения заявок. Узел рассчитывает один вектор для каждого входного элемента и может сохранить рядом исходные поля: текст, идентификатор и ссылку.
Длинный документ нужно заранее разделить на фрагменты. Узел не выполняет такое разбиение самостоятельно. Назначение вектора также важно: документ для базы и поисковый запрос могут обрабатываться по-разному.
Поддерживаются шесть вариантов подключения: OpenAI, Gemini, Mistral, Qwen, Yandex Cloud и собственный OpenAI-совместимый сервер. На дату публикации OpenAI и Mistral принимают до 200 текстов в одном запросе, Gemini — 100, Qwen — 10, Yandex Cloud — один. Для собственного сервера по умолчанию используется пачка из 16 текстов, точный предел задаётся в настройках.
По умолчанию размер пачки равен 16; при превышении лимита провайдера узел уменьшает его автоматически. Для тысячи фрагментов пачка 200 позволяет выполнить пять запросов вместо тысячи. Векторы сопоставляются с текстами по номерам из ответа. Если их количество не совпало с числом входных текстов, узел останавливается с ошибкой.
У Yandex модель определяется назначением: документ или запрос. Gemini поддерживает пять вариантов назначения. У OpenAI и Qwen можно сокращать размерность параметром, у Mistral это предусмотрено для codestral-embed. Более короткий вектор экономит место, но выбор размерности нужно проверять по качеству поиска.
Результат содержит embedding, provider, model, purpose и dimensions. Поле dimensions используют при создании коллекции. Параметры, не принятые сервисом, возвращаются в ignored. Расход tokens указывается для одного текста: провайдер считает токены всей пачки, и такой расход нельзя корректно приписать каждому элементу отдельно.
Первый workflow забирает новые документы, разделяет их на фрагменты, рассчитывает векторы с назначением «документ» и записывает их вместе с текстом и ссылкой. Он запускается по расписанию или событию и использует крупные пачки.
Второй workflow получает вопрос, рассчитывает один вектор с назначением «поисковый запрос» и ищет ближайшие фрагменты. Они становятся ответом, контекстом языковой модели или данными карточки заявки. Такой подход позволяет независимо настраивать частоту индексации и обработку запросов.
В каталоге Staqflow доступен Qdrant: создание коллекций, запись, обновление, поиск похожих и удаление точек. Размерность берут из результата модели, а метрику задают при создании коллекции. Для хранения также можно использовать подходящие узлы PostgreSQL, MongoDB, ClickHouse или Supabase.
Расходы зависят от количества обрабатываемого текста и тарифа провайдера; крупные пачки уменьшают число обращений. Работа workflow в Staqflow оплачивается отдельно. Для оценки качества используйте реальные вопросы и документы, а не только скорость наполнения базы.
Нет. Каждый фрагмент нужно подать отдельным элементом, например после обработки в узле «Код».
Используйте размерность из поля dimensions. Модель индексации и модель запросов должны формировать совместимые векторы.
Да. После векторного поиска можно добавить узел переранжирования и передать модели лучшие фрагменты.
Подробнее о возможностях автоматизации — на сайте Staqflow.