Обсуждение — Сколько стоит свой ИИ-сервер против подписок

Расчёт аккуратный, но он заканчивается на строчке с curl на localhost:4000/spend/logs.

Чтобы LiteLLM вернул что-то по тратам, ему нужна база: учёт расходов он пишет в Postgres, без неё отвечать будет нечем. В Compose это отдельный сервис и том под данные. Если не объявить volume, после docker compose down и пересоздания контейнера месяц, за который предлагают «последить за расходом», начнётся заново. Как раз когда захочется сверить его со счётом провайдера.

Второе — порт 4000. Если в compose написать просто "4000:4000", шлюз с мастер-ключом будет доступен из интернета, и экономия на подписках превратится в бесплатный ИИ для посторонних за ваши токены. Лучше "127.0.0.1:4000:4000" и выход наружу только через nginx с TLS. А если веб-чат живёт в той же сети compose, порт можно вообще не публиковать.

И одной строки в формуле не хватает: кто всё это обновляет. LiteLLM, веб-чат, Postgres, сертификат — четыре компонента, и у каждого свой цикл релизов. Одному человеку это вечер в месяц, в команде — уже чья-то обязанность.

И ещё по тексту: подписки «нельзя оплатить российской картой», а за токены статья предлагает платить «напрямую провайдеру». Каким способом — не сказано. Для читателя из РФ это тот же самый барьер)

Строчку «кто всё это обновляет» в нашем учебном каталоге клуба задали первой. Хотели ИИ, чтобы поиск находил «Дастаевского» и «Гарри Потера» с одной «т». Четыре компонента ради опечаток показались роскошью: Postgres и так стоит, а расширение pg_trgm ищет по похожести слов без всяких токенов. Буквальный поиск у нас, кстати, на «мир» первым выдавал «Мираж») Прежде чем сравнивать сервер с подписками, стоит проверить, не хватит ли одной базы.

Я бы первым делом вбила в этот каталог «Lfcnjtdcrbq». Это «Достоевский», набранный в английской раскладке, и рано или поздно кто-нибудь так его наберёт. Триграммы здесь бессильны: у латиницы и кириллицы нет общих кусков, похожесть нулевая. Но и это решается без ИИ: если поиск ничего не нашёл, переводим запрос через таблицу соответствия раскладок и ищем ещё раз. Вывод тот же, просто проходов будет два.

nina_test писал:
переводим запрос через таблицу соответствия раскладок и ищем ещё раз

У нас в Ереване к этой таблице добавляется ещё пара столбцов. На многих компьютерах стоят три раскладки: армянская, русская и английская. Переключаются по кругу, и промахнуться можно в обе стороны. Сам так однажды отправил коллеге целый абзац армянскими буквами вместо русского текста. Он вежливо спросил, всё ли у меня хорошо)

К тому же армянских раскладок несколько, например фонетическая и стандартная, и буквы у них стоят на разных клавишах. Одна таблица превращается в две-три, и надо угадать, какая была у человека.

Но это ещё механика. Труднее с транслитом. Многие здесь годами набирают русские слова латиницей нарочно, без всякой ошибки: Dostoevskij, Dostoyevsky, Dostoevski — кто как привык. Таблица раскладок тут бесполезна, потому что клавиши нажаты правильно. Зато сработает третий проход: перевести латиницу в кириллицу по правилам транслита, а потом отдать результат тем же триграммам. Вариантов написания много, но после перевода они дают почти одинаковую кириллицу, и pg_trgm их догонит.

Вывод у меня тот же: ИИ пока не нужен. Проходов становится три, а не два, и порядок у них важен: сначала как есть, потом раскладки, потом транслит.

arsen_evn писал:
Проходов становится три, а не два, и порядок у них важен

Важнее условие перехода. Если порог похожести низкий, триграммы редко возвращают пустоту. Найдётся какой-нибудь мусор, и второй проход не запустится. Надёжнее построить все три варианта запроса сразу и взять лучший similarity. Каталог от этого не поумнеет, но хотя бы перестанет довольствоваться «Миражом».

Вариант «все три сразу» на Python получается совсем коротким, набросал за пару минут:

EN = "qwertyuiop[]asdfghjkl;'zxcvbnm,."
RU = "йцукенгшщзхъфывапролджэячсмитьбю"
LAYOUT = str.maketrans(EN, RU)

def variants(q):
    q = q.lower().strip()
    out = {q}
    if q.isascii():
        out.add(q.translate(LAYOUT))
        out.add(translit_to_ru(q))  # своя функция, тут не показана
    return list(out)

В базу уходит один запрос с массивом, наружу возвращается лучший score:

SELECT title,
  (SELECT max(similarity(title, v)) FROM unnest(%s::text[]) v) AS s
FROM books
ORDER BY s DESC
LIMIT 10;

Тут две оговорки. Это минимальный пример: в таком виде он проходит по всей таблице, триграммный индекс ему не поможет. Для учебного каталога это терпимо, для большого нужен WHERE с title % v по каждому варианту, а использует ли план индекс, покажет EXPLAIN. Гадать не буду.

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

tema_py писал:
порог нужен в любом случае

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

У Whisper такая же беда: не расслышал — впаял похожее слово. Я однажды чуть не сдала в номер «министра» вместо «магистра». Дымило бы знатно.

tema_py писал:
порог нужен в любом случае

Даша, в расшифровке тоже: сомнительное слово лучше подсветить, чем вписать молча. «Магистр?» спасает номер.

тред начинался со стоимости ИИ-сервера, а дошли до того, что лучшая модель — честный знак вопроса после слова)

У нас на регистратуре этот знак вопроса дороже любого сервера. Администратор набирает фамилию с одной ошибкой, а поиск услужливо подставляет похожую. Открывается карта другого человека, иногда даже с близкой датой рождения. Поэтому в клинике я бы настраивала поиск строже: если похожесть ниже порога, пусть ничего не показывает и просит уточнить дату рождения. Лишняя минута у стойки, зато карта точно своя.

vera_med писал:
если похожесть ниже порога, пусть ничего не показывает и просит уточнить

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

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

Бота я, кстати, понимаю. На прошлой неделе сама искала в папке положение о премировании и минут десять внимательно читала положение о материальной помощи. Слова похожие, деньги разные.