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

Ограничение частоты запросов: 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

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

Давным давно, когда я писал дипломную работу по теме особенностей английской грамматики, я был немало удивлен тому, что слово "musting" - как -ing-овая форма от глагола must существует (да простит меня г-жа Каушанская, если вы понимаете, о ком я), правда эта форма имела немного иной смысл.

В помощь мне тогда была брошюрка Г. А. Вейхмана (между прочим фронтового переводчика) "Новое в английской грамматике", где автор объяснял сие явление так:

"Must, must, must. Who's musting me?" (M. Dickens). Модальные глаголы употребляются не в своих обычных значениях, а в значении "говорить + значение модального глагола" (в данном случае musting = saying "must").

Я тогда защитился, и на 24 года благополучно про этот нюанс забыл. А вот сейчас вспомнил, увидев "shoulds" (!). Контекст - на скриншоте :).

Кстати, когда мы обсуждали заказ на перевод книги по теории информации, клиент предложил мне просто скриншотить формулы, чтобы он их потом просто вставил в книгу (MS Word).

- А как же локализация формул?
- Евгений, не пугайте меня. Их разве надо локализовать?
- Разумеется. Поэтому скриншотами не обойдемся.

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

(https://teletype.in/@bartov/H-mSGIlFVGQ )

Пара терминов из математики вам в копилку + занимательный ребус.

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

Написали клиенту под заказ новую статью — на этот раз о том, почему дешевый ИИ на самом деле весьма дорогая игрушка для бизнеса.

https://habr.com/ru/articles/1090778/

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