Обсуждение — ИИ-перевод на своем сервере

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

Но в примере текст передаётся в параметре URL. Для «Hello world» удобно; с внутренним документом уже хочется сначала разобраться, что попадёт в журналы. Второй вопрос — построчная обработка: переводить строку субтитра и строку обычного абзаца, кажется, не одно и то же.

Кто бы с чего начал такой разбор: с качества нескольких фраз, с формата входного файла или с самого сервиса? Команды из статьи пока не запускал. Хочу сначала выбрать маленький пример, по которому будет понятно, что именно получилось.

Костя, POST не прячет текст, если тот остаётся в URL. Строка запроса может попасть в журналы приложения или прокси — зависит от настройки. Для чувствительного текста сначала определить формат передачи и журналирование, а не проверять приватность по слову «локально».

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

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

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

В статье «дешевле» получилось раньше, чем объём работы. В вашей десятке фраз сервер уже может быть самым дешёвым пунктом, а вычитка — самым дорогим. В смету положил бы проверку перевода тоже. Особенно если язык назначения никто из участников не читает)

Мне ещё важно заранее назвать языки. Пример из статьи про английский и русский не проверяет другую пару. Даже если сообщение обработалось без ошибки, это пока говорит о работе сервиса, а не о том, что перевод можно отдавать читателю.

А имя человека и номер заказа в этих десяти сообщениях оставьте неизменными. Для первой проверки подойдут номера А-1 и Б-2. Если перевод красивый, но две заявки обменялись номерами, пользователю от этой красоты будет мало пользы.

Начну с обычного текста, не с файла субтитров. У сообщения будет свой номер, исходная строка и результат рядом. Направление одно, отсутствие пакета — видимая ошибка. Отдельно разберу передачу текста и журналы. Это уже проверяемая маленькая штука; очередь всего архива пока подождёт.

Таблица «исходник рядом с результатом» — тоже копия текста, не только журналы. Для первой проверки бери выдуманные фразы, не живую переписку.

kostya_gw писал:
Отдельно разберу передачу текста и журналы.

n1kita верно сказал про таблицу. Я бы ещё сразу записал, где она лежит и кто её удаляет после проверки. Иначе через полгода на общем диске найдётся файл «перевод_тест_финал2», и никто не вспомнит, чей он. Временное у нас обычно самое долговечное.

pavel_63 писал:
Я бы ещё сразу записал, где она лежит и кто её удаляет после проверки.

Записать полезно. Но запись про удаление обычно читают уже после того, как файл прожил полгода. Надёжнее сделать так, чтобы у таблицы просто не было шанса попасть на общий диск.

Картина знакомая каждому, кто передавал чужой проект. Открываешь сервер, там compose, рядом папка без описания, в ней «перевод_тест_финал2.csv». Удалять страшно: вдруг это кому-то нужно. Оставлять тоже не хочется: там чьи-то фразы, пусть и выдуманные. Поэтому файл живёт дальше, по той же причине, что и раньше.

Для проверки, которую задумал kostya_gw, я бы держала всё внутри каталога проекта и одним списком:

— таблица «исходник — результат» лежит в отдельной папке test-run рядом с compose-файлом, а не в домашнем каталоге и не на общем ресурсе;
— в имени дата прогона, а не «финал»; через месяц по дате видно, что проверка давно закончилась;
— в README одна строка: что это, кто запускал, когда удалить.

И второе место, о котором при разговоре про таблицу забывают. Если сервис перевода пишет входной текст в stdout, этот текст оседает в логах контейнера. Таблицу удалят, а копия фраз останется в журнале Docker. Ротацию логов стоит указать заранее, до первого прогона. Пример, имя сервиса и образ здесь условные:

services:
  translator:
    image: <ваш_образ>
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

Логи это не удалит, зато не даст им копиться бесконечно. Лучше вообще не писать в журнал сами фразы, только номер сообщения и статус. Тогда n1kita прав дважды: копия текста останется в одном месте, и это место известно.

Если тестовые данные лежат в именованном томе, помните: docker compose down том не трогает, а down -v удаляет тома этого проекта целиком. Перед таким шагом проверьте, что в томе нет ничего, кроме теста. Иначе вместе с «финал2» уйдёт что-нибудь действительно нужное, и о бережном отношении к временным файлам вспомнят уже совсем в другом тоне)

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

kate_ekb писал:
Таблицу удалят, а копия фраз останется в журнале Docker.

Куда именно она осядет, зависит от драйвера логов. От этого же зависит, как её потом убирать.

Если у контейнера json-file, журнал лежит в каталоге этого контейнера. После docker rm он исчезнет вместе с контейнером. Если драйвер journald, строки уходят в системный журнал хоста. Тогда контейнер можно пересоздать хоть десять раз, а тестовые фразы останутся в journalctl, пока их не вытеснит ротация самого journald. Это уже не настройка compose-файла, а политика хранения на сервере.

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

docker info --format '{{.LoggingDriver}}'
docker inspect --format '{{.HostConfig.LogConfig.Type}} {{.HostConfig.LogConfig.Config}}' <имя_контейнера>

Первая команда покажет драйвер по умолчанию для демона. Вторая покажет, что реально стоит у контейнера: в compose могли переопределить. В той же строке будут max-size и max-file, если их задавали.

В README к test-run я бы добавил этот драйвер одной строкой. Тот, кто через месяц будет удалять папку, хотя бы узнает, что удаления папки мало. Иначе он честно сотрёт CSV, увидит пустой каталог и закроет вопрос, а фразы так и останутся в журнале.

pavel_63 писал:
Временное у нас обычно самое долговечное.

Ещё два места, где оно живёт без README. Если kostya_gw будет гонять фразы через curl прямо из терминала, они осядут в истории шелла. Если текст уйдёт в query-строке GET, его запишет access-лог прокси перед сервисом. Поэтому тест лучше слать POST-телом из файла в той же test-run. Тогда чистить придётся одну папку, а не искать «заявку А-1» по трём журналам.

n1kita писал:
Тогда чистить придётся одну папку, а не искать «заявку А-1» по трём журналам.

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

Когда у нас проверяли новую форму записи, попросили регистратуру набросать десяток примеров. Девочки старались и придумывали честно. А потом читаешь: фамилия редкая, год рождения, жалоба, район. Никто ничего не копировал, просто голова сама подсовывает вчерашний приём. Я тоже честно сочинила пациентку и через минуту поняла, что описала свою тётю, только переставила ей отчество. Фантазия у администратора клиники, как выяснилось, ограничена журналом записи.

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

— имена явно служебные: «Тестов Первый», «Пробная Вторая»;
— даты в будущем или заведомо невозможные;
— никаких реальных районов, отделений и фамилий врачей;
— номера в духе А-1 и Б-2, как тут уже предлагали.

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

vera_med писал:
Поэтому для медицинских текстов я бы не полагалась на «придумайте сами».

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

И у каждой строки один и тот же маркер в начале, например «ТЕСТ-ПЕРЕВОД:». Не ради красоты. Это ответ на то, что написал lexa92 про драйверы логов.

lexa92, ты прав, что после docker rm при json-file журнал уходит вместе с контейнером, а при journald остаётся на хосте. Но «уходит» и «остаётся» — это пока предположение. С маркером его можно проверить, не читая журналы глазами. После прогона и удаления тестового контейнера, если драйвер journald, пример, имя подставить своё:

journalctl CONTAINER_NAME=<имя_контейнера> | grep -c 'ТЕСТ-ПЕРЕВОД'

Ноль — сервис тело запроса не пишет, и вопрос закрыт. Не ноль — фразы лежат в системном журнале. Выборочно их оттуда не вырежешь, только общей очисткой journald по сроку или размеру, а это уже затронет журналы всего сервера. Такое решение принимает тот, кто отвечает за хост, а не тот, кто тестирует перевод.

Поэтому для тестового сервиса я бы не спорила с политикой сервера, а просто вынесла его из неё. Пример куска compose, остальное у kostya_gw своё:

services:
  <сервис_перевода>:
    logging:
      driver: json-file
      options:
        max-size: "1m"
        max-file: "2"

Тогда журнал прогона живёт рядом с контейнером, ограничен по размеру и умирает вместе с ним. Если же grep показал маркер в выводе, честнее поправить сам сервис, чтобы он писал номер сообщения и длину, а не текст. Номер А-1 в логе полезен для отладки, сама фраза — нет.

А теперь картинка, ради которой всё это. Через полгода кто-то открывает сервер, видит test-run, README и файл фраз. Запускает тот же grep по маркеру, получает ноль и спокойно удаляет папку. Ему не надо помнить, кто в регистратуре сочинял примеры и не была ли это чья-то тётя. Ему нужно проверить одну строку и получить ноль.

Выдуманные данные хороши ровно настолько, насколько их легко найти и доказать, что их больше нигде нет)

kate_ekb писал:
Тестовые фразы должны жить в репозитории как обычный файл

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