Бартов: про работу с ИТ- и медтекстами и про всякое

Ну ок, сами напросились.
Следующий хит, который вызвал нехилый такой фейерверк в моей голове — «размыв».


Идут три предложения:

В южной части участка наблюдается долинообразный размыв в кровле глин веневской свиты. Размыв дугообразно вытянут с запада на восток. Его ширина составляет 350-400 м.

Перевод первого предложения получается такой:

A valley-like erosional feature is observed in the roof of the Venevsky suite clays in the southern part of the site.

То есть размыв = erosional feature.

Как переведем «размыв» во втором предложении?
Снова что-то про erosion?
Хренушки — там «размыв» = washout.

The washout is an arcuate feature extending west to east with a width of 350-400 m.

Почему? Потому что эти предложения описывают «размыв» с разных точек зрения:

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

2. Во втором предложении геолог включает в себе экономиста и подсчитывает, сколько тонн глины физически в итог унесло водой, следовательно washout — это габариты «дыры», т.е. вымытой полезной породы (400 м).

То есть в тексте сначала описали форму (erosional feature), потом измерили масштаб (washout).

Продолжение следует...

Еще про геологию надо?

А то тут терминологические черти изо всех щелей полезли. Для профильных переводчиков они очевидны, но я что-то пока еще охреневаю (и еще, думаю, неделю-полторы буду охреневать, пока не сдам проект и не получу за него от клиента по башке 😉).

👍 - НАДО / 👎 - НЕ НАДО

То ли дело - ИТ, там все понятно :).

Занесла меня нелегкая судьба в тему русско-английского перевода по геологии (я не специально 🤓).

Тем, кто работает в ней, надо ставить памятник — это же сплошное минное поле.

• Московская синеклиза, Московское оледенение — Moscow Syneclise, Moscow Glaciation

НО:

• Московский ярус — Moscovian Stage

Есть еще "Московский горизонт" - можно и Moscow, и Moscovian, но в каждом варианте свои академические нюансы. И нидайбох вам написать Horizon с маленькой буквы :).

Shell command и CLI command: в чём разница и почему она важна

Спойлер: для многих переведенных мною авторов разницы нет.

Вот примеры из текущей книги:

Command injection is similar, except user input is able to execute arbitrary CLI commands on the system.

You can use several techniques to defend against these exploits... e.g. using allowlist shell commands or prompts or sandboxing the environment in which shell commands are executed.

Both of these vulnerabilities can be relevant to MCP servers, especially if your server is used to access a database or execute CLI commands.

Если не сильно заморачиваться, то в целом речь идёт о некоем чёрном окошечке, в котором моргает курсор и куда можно вбивать команды.

А вот если все же вникнуть, то разница есть. Будем разбираться.

Для начала надо понять, что такое shell.

Продолжение на https://teletype.in/@bartov/rxCyNkKrKvG?utm_source=teletype&utm_medium=feed_rss&utm_campaign=bartov

Ограничение частоты запросов: rate limiting vs request throttling

Встретилось предложение:

These attacks can be prevented by implementing rate limiting, request throttling, and other techniques to head these attacks off at the pass.

В плане перевода этих терминов по отдельности проблем не было — и то, и другое в разных источниках переводилось как что-то вроде «ограничение скорости/числа/частоты запросов».

Но вот они сейчас в одном предложении, и их надо развести, чтобы читатель не запутался. Окей, разберемся, в чем разница.

•••

Rate limiting — это жёсткое административное ограничение, устанавливаемое на сервере.

Сервер как бы объявляет клиентскому устройству правило: «У тебя есть лимит — 100 запросов в минуту. Соответственно, 101-й запрос я даже смотреть не стану». Термин так и переводится: «ограничение/лимитирование частоты запросов».

Такую защиту ставят от DDoS-атак или в рамках реализации тарифного плана (мой провайдер ИИ-модели часто тормозит меня этим ограничением: типа, посиди, остынь, не шли мне свои запросы слишком часто).

Продолжение на https://teletype.in/@bartov/65Kit58mzqx?utm_source=teletype&utm_medium=feed_rss&utm_campaign=bartov

#безопасность #перевод #терминология #ИТ

Многоликий «performance»: разбор ИТ-термина

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

1. Итак, в ИТ-переводах есть одно капризное слово — performance. Для чистоты эксперимента возьмем самый понятный пример:

Pagination allows servers to return a subset of a response to the requesting client along with a token that represents the current position in the overall response data.
This utility can help improve performance when dealing with large datasets both
locally and remotely.

Суть отрывка для ИТ-переводчика прозрачна: пагинация экономит оперативную память и снижает нагрузку на сеть (сокращается latency/задержка). Кастомный транспорт оптимизирует утилизацию процессора или скорость передачи пакетов. В обоих случаях мы оцениваем систему метриками «быстрее/меньше ресурсов», поэтому пишем «производительность» или «быстродействие» — классический перевод этого термина.

2. Но так бывает далеко не всегда. Возьмем парочку других примеров:

...you need to balance token efficiency with clarity and context that enables optimal tool-choice performance...

Like people, LLMs work best when they have a few examples to work from. This is called few-shot learning, a powerful technique for improving the accuracy and performance of LLMs.

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

Смысл здесь в том, что если у модели падает tool-choice performance, это НЕ значит, что она начинает медленнее генерировать токены. Это значит, что она начинает тупить и ошибаться — выбирать не тот инструмент или путать аргументы. Следовательно, речь идет о «точности и качестве работы LLM» или об «эффективность выполнения задач».

3. А вот извольте взглянуть на этот примерчик:

You will have to consider what you really want out of your prompt and evaluate its performance with different example sets across many runs.

Очевидно, что промпт не имеет «производительности» (он не работает быстрее или медленнее). Промпт сам по себе тоже не работает, это лишь инструкция для LLM. Таким образом, мы тут говорим о том, насколько стабильно (across many runs) данный промпт приводит к нужному результату. Здесь performance — это «эффективность» или «результативность» или «стабильность» промпта.

4. И приведу еще один примерчик ....

Продолжение на https://teletype.in/@bartov/sviRCHXdzlA?utm_source=teletype&utm_medium=feed_rss&utm_campaign=bartov

В контексте ИИ-ассистентов есть такой термин — completion.

Посмотрите на эти два отрывка:

Sampling allows your server to request chat completions from the client application’s language model, lending your server the capability to use the client application’s language model to augment the functionality of your tools.

In the completion message lifecycle, as the user fills in a prompt or resource-template argument, the client sends completion requests to the server, and each response narrows the suggestion list until the user selects a value.

Проблема с переводом этого термина в том, что специалисты используют его взаимозаменяемо с двумя другими терминами — chat completion и autocompletion.
А между собой эти термины различаются принципиально. Это два абсолютно разных механизма в работе ИИ-ассистентов и решают они противоположные задачи.

Первое прочтение

Думаю, большинству моих читателей такое явление, как chat completion, известно весьма хорошо. Это не что иное, как сообщение в чат-боте (в оранжевой рамке).
Суть этого completion (то есть chat completion) в том, что пользователь делает запрос к языковой модели, а она в ответ генерирует ответ. Поэтому перевод здесь будет, согласно хабру, «генерация ответа/текста».

Второе прочтение

Допустим, вы работаете с ИИ-ассистентом и вам нужно заполнить аргументы в шаблоне промптов — подставить туда значения переменных. Вы начинаете набирать эти значения или просто жмете Tab и ваш ассистент (а точнее, его клиентская часть, которая общается с MCP-сервером) запрашивает варианты подсказок (suggestions) у MCP-сервера, чтобы не ошибиться и не опечататься.
Вот эти подсказки и будут autocompletions/completions. На русский переводится как «автодополнения», «подсказки», реже — «комплишены».

Оригинал публикации (с картинками): https://teletype.in/@bartov/FQCIjjvSh-7

Есть такой контекст.

В переводимой сейчас мною книге речь идёт о том, что вы разработчик MCP-сервера (это сервер который общается с вашим ИИ-агентом и предоставляет ему контексты — см. схемку в статье по ссылке).

У вас есть всякие инструменты, которыми можно воспользоваться для взаимодействия с хостом. Вот в этих предложениях они и перечисляются:

The major utilities are completions, the context object, logging, progress notifications, and pagination. Other utilities are also available to you as a server developer, like server icons and manual notifications.

В целом вроде всё укладывается в логику: вы можете слать в чат-бот клиента подсказки, логировать общение, сообщать о прогрессе выполнения запроса, делить вывод на страницы (пагинация). В общем, всё путём — кроме последних двух слов: manual notifications.

Manual - это обычно руками. А руками — это как? Вот сижу я, разработчик или админ на сервере, в сервер летят тысячи запросов, и я тут вдруг решил кому-то отправить уведомление вручную? Нахрена?

• • •

Недолгие раскопки привели меня к тому, что manual здесь — вообще не про манипуляции руками.

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

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

Вот эти кастомные уведомления и будут manual notifications.

Получается, никакие они не ручные, а вполне себе автоматические. Просто источник автоматики — не дефолтовый конфиг, а ручки программиста, которыми он делает дополнительную автоматику.


Источник: https://teletype.in/@bartov/kMh5FmlQ-66

Провел небольшую оптимизацию/тюнинг своего конвейера переводов.
Второй день подряд фиксирую скорость получения отредактированного/локализованного перевода на уровне 1000 слов за 20-25 минут (т.е. 2500 - 3000 слов в час).
Текст без повторов.

Решил написать небольшую заметку-портфолио по итогу переведенных книг из ИТ:

https://teletype.in/@bartov/VBpsEr9Tg_B

Если кого забыл упомянуть, напишите плиз в личку, я добавлю вас в список.