Обсуждение — Flowise на VPS: собираем LLM-пайплайны без кода

Читала про Flowise с карандашом, как трудовой договор. Зацепилась за фразу из FAQ: «Наружу ничего не уходит». Флоу и ключи действительно лежат в /opt/flowise. Но типовой сценарий в той же статье работает через внешний LLM-API. Значит, вопрос сотрудника и куски регламента, которые нашёл поиск, всё-таки уходят провайдеру модели. А если эмбеддинги тоже внешние, то при загрузке туда по кусочкам уйдёт весь документ.

Для меня это и есть главная граница. Ради неё я вообще смотрю на свой сервер: положение о премировании и порядок увольнения не хочется отправлять в чужое облако. Ollama в статье упомянута одной строкой. Какие узлы тогда должны быть локальными, чтобы наружу правда ничего не уходило: только Chat Model или Embeddings тоже?

Второй вопрос уже кадровый. Виджет «на лендинг» — понятно, но мне нужен строго внутренний бот. Логин из статьи закрывает панель. А REST-эндпоинт prediction и виджет он тоже закрывает? Или по ссылке спросить про отпускные сможет кто угодно? Сотрудники будут путать «наш бот» и «бот на сайте», это я знаю заранее. Хочется, чтобы хотя бы сервер их не путал.

Признаюсь, слова «без кода» подкупили меня сильнее, чем следовало. Я уже представила, как сама таскаю стрелочки, а теперь сижу и выясняю, куда они ведут.

Про эмбеддинги, по-моему, вы правы: если они внешние, документ уходит к провайдеру целиком, просто кусками. Значит, локальными должны быть и эмбеддинги, и векторное хранилище, а не только модель. Меня здесь беспокоит ещё одно. Локальная модель эмбеддингов может оказаться попроще, и тогда сотрудник, набравший «отпусные», получит абзац про премирование) В нашем учебном каталоге запрос «Пушкен» однажды выдал сборник рецептов. Перед запуском я бы прогнала десяток запросов с опечатками.

С адресами то же: «Бауманв» с одной опечаткой геокодер уверенно ставил в другой город. В тестовые запросы я бы добавил и сокращения: «отп.», «б/л».

lena_library писал:
Перед запуском я бы прогнала десяток запросов с опечатками.

Десяток — это один вечер. Только эти расходы повторяются. Поменяли локальную модель эмбеддингов на поумнее — и всю базу регламентов надо переиндексировать заново. Потом снова гонять «отпусные», «отп.» и «б/л» от artem_maps. Поэтому список тестовых запросов лучше сразу сохранить файлом. Иначе через месяц полчаса уйдёт на то, чтобы вспомнить, как именно вы ошибались)

andryukha писал:
Поэтому список тестовых запросов лучше сразу сохранить файлом.

И рядом с каждым запросом стоит записать, какой абзац должен найтись. Без этого через месяц файл превратится в список странных слов: «отпусные» есть, а какой ответ был правильным, никто уже не помнит. У меня в таблице адресов так и было: столбец «запрос» и столбец «где должна стоять точка». После смены геокодера сразу видно, какие строки уехали.

artem_maps писал:
И рядом с каждым запросом стоит записать, какой абзац должен найтись.

Столбец «что должно найтись» нужен, согласен. Только сами запросы лучше не придумывать за людей.

У меня дома то же самое, только в мелком масштабе. Поднял для своих бота по домашней шпаргалке: где пароль от вайфая на даче, как перезагрузить Keenetic, когда менять фильтр в котле. Список проверок честно составил сам: «пароль дача», «роутер перезагрузка», пара опечаток. Всё находилось, я довольный.

Вечером жена пишет: «интернет у мамы не грузит что делать». Ни дачи, ни роутера, ни одного моего слова. Бот выдал абзац про фильтр в котле. Младший вообще надиктовывает голосом, и распознавалка вместо «кинетик» пишет «генетик». Таких опечаток я бы сам за год не придумал.

В итоге тестовый файл я пополняю не из головы. Это реальные вопросы домашних, которые бот не понял, а рядом правильный абзац. Для HR, думаю, так же: первые две недели собирать живые вопросы сотрудников, а не только «отп.» и «б/л» от того, кто настраивал. Свои ошибки ты и так знаешь, ловить надо чужие.

Живые вопросы собирать правильно. Только дома ты сам и читаешь журнал, и правишь шпаргалку. В отделе кто будет это разбирать через месяц? Без ответственного журнал непонятых вопросов быстро превращается в папку, которую никто не открывает. И ещё: туда попадут вопросы вроде «сколько мне дадут при увольнении», а если пишется, кто спрашивал, этот журнал надо закрывать не хуже самого бота.

Генетик хотя бы перезагружать не надо.

Принято, «генетик» меня добил) С картами похоже: по адресу люди ищут редко. Пишут «где раньше был Детский мир» или «остановка у рынка», а такой строки нет ни в одном справочнике. В живых вопросах я бы ловил не только опечатки, но и чужие названия: «у мамы» вместо «на даче», «интернет» вместо «роутер». Такие пары можно дописать прямо в шпаргалку. Тогда есть шанс, что нужный абзац найдётся и без смены модели.

artem_maps писал:
Такие пары можно дописать прямо в шпаргалку.

Из всего треда это самый дешёвый вариант. Дописать «у мамы = на даче» стоит минуту, и переиндексировать придётся один абзац. Смена модели — это переиндексация всей базы и повторный прогон всего тестового файла. Подвох один: минута уходит на каждую пару, а через полгода пар будет сотня. И дописывать их будет тот самый ответственный, которого пока нет)

andryukha писал:
через полгода пар будет сотня

Сотня — полбеды. Хуже, что пары со временем устаревают, а удалять их никто не догадывается.

На Маке есть замена текста в настройках клавиатуры: набираешь сокращение, система подставляет фразу. Я годами складывала туда всё подряд. На днях открыла список, а там восемьдесят строк. Половину я не узнаю. «адрр» раскрывается в адрес квартиры, из которой мы съехали три года назад. Хорошо, что заметила сама, а не курьер.

С шпаргалкой будет то же самое. «у мамы = на даче» верно ровно до того дня, когда мама переберётся в город и интернет у неё будет уже от другого роутера. Пара останется, бот продолжит уверенно отправлять человека на дачу. Никто не спросит, почему, ведь раньше это работало.

Поэтому я бы держала пары не внутри текста шпаргалки, а отдельным списком: пара, кто добавил, когда и из какого живого вопроса она взялась. Тогда ответственный, которого пока нет, сможет хотя бы раз в квартал пролистать список и вычеркнуть то, что уже неправда. Без даты рядом с парой понять это невозможно, проверено на моём «адрр».

andryukha писал:
И дописывать их будет тот самый ответственный, которого пока нет)

В учебном каталоге клуба этот ответственный пока я. Завела пару «детектив = криминальный роман», и запрос «детский» стал выдавать Агату Кристи: поиск принял его за опечатку. Дети довольны, я меньше.

Тестовый файл может проверять и пары. Убрали пару, прогнали файл. Если ничего не упало, её можно не возвращать.

lena_library писал:
Убрали пару, прогнали файл. Если ничего не упало, её можно не возвращать.

Тут есть ловушка. «Ничего не упало» иногда значит только одно: в файле нет ни одного запроса, который эту пару проверял.

У меня в таблице адресов была пара «где раньше был Детский мир = ул. Баумана, 51». Решил почистить старьё, убрал её и прогнал проверку. Всё зелёное, доволен. А зелёное оно потому, что строки «где раньше был Детский мир» в проверках не было вовсе. Пару я когда-то дописал из чужого вопроса, а сам вопрос в тестовый файл не перенёс. Через неделю кто-то снова так спросил, и точка улетела на другой конец города.

Поэтому правило простое: появилась пара, рядом в тестовом файле появляется живой вопрос, из-за которого её завели. Тогда удаление действительно что-то проверяет.

И раз уж «детский» нашёл Агату Кристи, нужна ещё обратная строка: запрос «детский», ответ «не детектив». Одна проверяет, что пара работает, другая — что она не задевает соседей.

andryukha, по твоему счёту это та же минута на пару, просто теперь в двух файлах. Зато ответственному не придётся гадать, откуда взялась сотая пара и можно ли её вычеркнуть.

artem_maps писал:
запрос «детский», ответ «не детектив»

Обратную строку я бы записала положительно: «детский» → в первой тройке «Денискины рассказы». Проверку «не детектив» пройдёт и пустая выдача, ведь там тоже нет Агаты Кристи. Я сначала так и записала. Полдня радовалась зелёному файлу, пока не заметила, что индекс просто не пересобрался и поиск не находил вообще ничего.