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

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

2026-10-27T00:01:03.995Z

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

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-атак или в рамках реализации тарифного плана (мой провайдер ИИ-модели часто тормозит меня этим ограничением: типа, посиди, остынь, не шли мне свои запросы слишком часто).

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

В итоге сервер искусственно замедляет (притормаживает) обработку запросов, размазывая пиковую нагрузку во времени. Запросы выстраиваются в очередь и выполняются постепенно.

К этому механизму прибегают, чтобы спасти бэкенд от всплесков трафика и плавно распределить ресурсы системы.

Переводится как «троттлинг запросов», реже — «дросселирование».

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

2026-10-26T23:38:23.558Z

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

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

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.

Shell (оболочка) — это интерпретатор команд, который принимает ввод и передаёт его на выполнение ядру или другим программам. Оболочка может выполнять как свои внутренние, встроенные команды, так и запускать сторонние программы по команде.

Встроенные команды оболочки — это, как правило, команды, которые выполняются внутри самого процесса оболочки. Эти команды могут изменять состояние самого процесса: например, изменить его рабочий каталог, переменные окружения, таблицу функций и т. д. И эти команды — первое, что проверяет оболочка, когда их в ней запускают. Именно тут речь идёт о shell command — командах оболочки.

А вот запуск из оболочки внешнего файла — например, git, docker или, скажем, python — это явно не встроенные в оболочку команды/инструменты. Это уже будет считаться CLI command.

В этой путанице с точки зрения ИТ, пожалуй, ничего особо страшного нет — ну мало ли, в каком порядке там команды исполняются. А вот с точки зрения ИБ разница более ощутимая: в первом случае компрометируется контроль над всей системой, а во втором — над одним из сторонних файлов/инструментов/утилит внутри системы.

Конечно, многое зависит от критичности этого стороннего файла, но это уже другая тема. А пока, я надеюсь, как смог объяснил разницу между shell command (команда оболочки, команда интерпретатора) и CLI command (терминальная команда, консольная команда, команда CLI, команда интерфейса командной строки — пардон за тавтологию).

Роль резиновой уточки в сосудистой хирургии

2026-10-26T18:43:21.141Z

#заметки_на_полях

#учимся_переводить

Надеюсь, было познавательно.

Ваш Евгений Б.

Английский в картинках: сonjunctions and punctuation

2026-10-26T18:38:42.513Z

#английский_в_картинках

Надеюсь, было познавательно.

Ваш Евгений Б.

Английский в картинках: предложения и пунктуация

2026-10-26T18:28:47.357Z

#английский_в_картинках

Надеюсь, было познавательно.

Ваш Евгений Б.

Английский в картинках: причастный оборот

2026-10-26T18:12:16.335Z

#английский_в_картинках

Источники:

THE ELEMENTS OF Style BY WILLIAM STRUNK Jr. with Revisions, an Introduction, and a Chapter on Writing BY E. B. WHITE. COPYRIGHT © 2000, 1979. ALLYN & BACON
Ali Dabbagh • Antonio Hernandez Conte Lorraine Lubin Editors Congenital Heart Disease in Pediatric and Adult Patients Anesthetic and Perioperative Management
Joep Perk, Peter Mathes, Helmut Gohlke, Catherine Monpère, Irene Hellemans, Hannah McGee, Philippe Sellier, and Hugo Saner,Editors Cardiovascular Prevention and Rehabilitation. © Springer-Verlag London Limited 2007
Complete Java J2EE Questions. JavaEra.com ®

Автор: Мария Соловьева, переводчик БП «Альянс ПРО».

Надеюсь, было познавательно. Спасибо за внимание.

Ваш Евгений Б.

Автоматизируем работу переводчика: разбиваем том на главы, каждую главу в файл

2026-10-26T17:48:14.609Z

#nlp

На днях возникла задача — надо было проалайнить книгу (= сделать из книги translation memory), а из доступных инструментов, которые делают автоалайнмент, на руках был только SDL Trados Studio 2021.

Я распознал через Finereader две книги по 400 страниц — одну на русском, одну на английском — скормил автоалайнеру, и оставил на ночь. Утром прихожу — он еще в раздумьях, где-то до середины дошел и в общем-то вроде как и не завис, но по ощущениям он нифига не алайнит. Ступор какой-то.

Провел эксперимент: вырезал ручками по одной главе из каждой книжки, и скормил их алайнеру — через 2 минуты он их проалайнил. Ага, значит, кошечка по имени Традос тупо поперхнулась большим объемом книжки.

Отсюда вывод, надо скармливать алайнеру книгу главами. Но как это сделать? Ручками? Но там ок. 30 глав в каждой, задолбаюсь. Тут я вспомнил, что мы недавно переводили на эту тему ролик, там этот процесс автоматизировался через Python.

Привожу здесь код на примере файла alice.txt и разделительного слова CHAPTER:

#читаем TXT-файл
with open("alice.txt", "r") as f:
    text = f.read()
#ставим разделительные символы перед найденным разделителем
    formatted_text = text.replace("CHAPTER", "=-CHAPTER")   
#режем по добавленным символам
    split_text = formatted_text.split("=-")
#убираем первый кусок, он пустой
    del split_text[0]
#каждый найденный кусок нумеруем, даем название и сохраняем в отдельный файл 
    for i in split_text:
        name = i.split("\n\n")
        form_name = name[0].replace(".", "_").replace(" ",
                                                      "_").replace("?", "")
        print(form_name)
        with open(f"./chapters/{form_name}.txt", "a+") as f:
            f.write(i)

Когда у вас в книжке 5 глав, это можно сделать и ручками. Если их по 30-50 в каждом томе — имеет смысл автоматизировать.

Подробнее см. в видео (ниже) и Google.Colab.

Надеюсь, было познавательно. Спасибо за внимание.

Ваш Евгений Б.

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

2026-10-26T16:03:59.447Z

#заметки_на_полях

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

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. И приведу еще один примерчик, который вроде как и пересекается по смыслу с примерами выше, но все же немного стоит особняком:

You can also use tricks to improve your prompts that are model specific, but they may not necessarily reduce performance when used on other models.

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

В 3-м примере мы тестируем один конкретный промпт и замеряем его «стабильность» во времени. В 4-м примере мы берем стабильный для одной модели промпт и запускаем его на другой модели.

Но другая модель обладает иной архитектурой. Хак, который заставлял, скажем, Claude выдавать шедевры, в чужой модели может вызвать ступор, галлюцинации или игнорирование системных инструкций. И фраза "reduce performance" означает не то, что промпт станет менее "эффективным" в плане выполнения задачи или менее "стабильным", а то, что чужая модель начнет ломаться и выдавать некорректные/неадекватные ответы.

То есть речь идет о деградации базового поведения модели. Соответственно, здесь performance будет уместно переводить как "качество работы", "адекватность ответов" или "корректность поведения".

Надеюсь, было познавательно. Спасибо за внимание.

Ваш Евгений Б.

Двоякий перевод 'completion' в контексте ИИ-ассистентов и MCP

2026-10-23T18:27:00.883Z

В контексте ИИ-ассистентов есть такой термин — 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. На русский переводится как «автодополнения», «подсказки», реже — «комплишены».

Почему 'manual notification' — это не про руки

2026-10-22T22:34:48.712Z

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

В переводимой сейчас мною книге речь идёт о том, что вы разработчик 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.

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