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

Эти механизмы обычно остаются скрыты от обычных пользователей — для большинства из них работа ИИ это "магия". Для моих читателей — нет :).

Кстати, о магии. Авторы буквально с первых строк добавляют ложку дегтя в свой рассказ и объясняют феномен "lost in the middle" - это когда вы построили базу знаний, она вам извлекла кучу полезных фактов и передала в модель, а модель запомнила только первые и последние. Почему так происходит? Ответ в статье.

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

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

Как и обещал, опубликовал вторую часть разбора технологий RAG (баз знаний при работе с ИИ-переводом). Приглашаю почитать, обсудить в комментариях.
Также подвесил к терминам инфобоксы — на них можно тыкать мышкой и смотреть исходный термин и небольшое пояснение к термину.

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

Чем отличаются «галлюцинации» от «иллюзий» в контексте ИИ-перевода?

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


Про галлюцинации, думаю, слышали многие — это когда языковая модель (или упрощенно ИИ) сам придумывает факты и правдоподобно их подает.

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

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

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

В чем отличие от галлюцинации? В галлюцинации модель сама выдумывает факт, а в иллюзии - она делает неправильный вывод, опираясь на некорректно обработанную информацию.

Подробнее почитаете уже в статье, которую, надеюсь, сегодня донести до Хабра.

Иногда студенты спрашивают: "Почему, когда закидываешь в модель текст на перевод, ИИ ведет себя по-разному: где-то сильно перевод сжимает, а где-то передает, как надо?"

Дело в том, что ИИ оперирует только числами, а не смыслами. Для нее каждое слово - это определенный вектор (т.е. последовательность чисел, которые выступают чем-то вроде координат в смысловом пространстве). Следовательно, одно предложение - это скачки по этим смысловым координатам (красная линия).

Несколько предложений - еще больше скачков.

Когда вы в модель закидываете страницу, модели чисто математически проще посмотреть, куда в конечном итоге выходят смысловые координаты, и она выводит такой текст, который максимально коротким путем приходит из начальной координаты в конечную, без зигзагов (зеленая линия).

Отсюда вывод: хотите, чтобы модель не подъедала нюансы? Сокращайте объем текста в промпте.

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

ПРАКТИКА ДЛЯ ТЕХ, КТО ИНТЕРЕСУЕТСЯ ИТ- и ИИ-переводом.

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

Почему научных? Потому что именно на них можно хорошо увидеть, в чем ИИ силен, а в чем беспомощен + прокачать скиллы. Кроме того, можно эти я буду публиковать на Хабре с упоминанием тех, кто мне помогал (можете добавлять строчки в свои резюме и показывать клиентам).

Таким образом я могу предложить следующее:
1. Помогу разобраться с использованием ИИ в работе (вместе настроим ваше рабочее место: агент/ассистент + база знаний + промт-инжиниринг).
2. Предложу статьи на перевод, которые связаны с возможностями ИИ и профессией переводчика.
3. Вместе сможем разобрать технический смысл выбранной вами статьи.
4. Спланируем работу по статье, чтобы подготовить ее для публикации в Хабр.
5. Буду принимать от вас переведенные фрагменты и давать по ним обратную связь (так мы будем выявлять, где ИИ хорошо справился, а где за ним нужно больше человеческого контроля - это понимание пригодится на реальных проектах).
6. Опубликуем статью на Хабре (сможете добавить к себе в портфолио).

По деньгам:
За 1-й пункт - 5 тыс. руб., остальные - по 1 тыс. руб. за часовое занятие/консультацию/проверку.
Чек от ИП или самозанятого, если нужен.

Пишите в личку: t.me/bartov-e (Евгений).

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

Это значит, что сначала вы прогоняете весь исходный текст через промпт-объяснялку, чтобы ИИ вам объяснил технический смысл текста, а потом только вы приступаете к его переводу, чтобы уже по ситуации корректировать те фразы, где ИИ, мягко выражаясь, привирает.

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

### Роль:
1. Вы — **технический переводчик**, изучающий ИТ для последующего написания экспертной статьи на русском языке.
2. **Цель перевода:**
- 2.1. Проанализировать передаваемый текст с точки зрения описываемых концепций, технологий, приемов, практик, устройства, принципов работы и дать описание к каждому такому термину при первом упоминании в фигурных скобках в форме, понятной второкурснику.
- 2.2. Использовать терминологию, принятую на платформе https:\\habr.com.

---

### Инструкции:
1. **Этапы работы:**
- Пронумеровать каждое предложение исходного текста.
- Выбрать все термины, связанные с ИТ (в первую очередь аббревиатуры и узкоспециализированные термины).
- Перевести предложения на русский, соблюдая:
- Логическую связность.
- Единообразие терминов (согласно глоссарию).
- Стиль, характерный для Habr.
- **Адаптация для целевой аудитории:**
- Выделить **жирным** русскоязычные термины.
- При первом упоминании технического термина добавить:
- [английский эквивалент].
- {развернутое пояснение, из которого читателю становится понятно устройство, принципы, механизмы работы + решаемые задачи/проблемы/вызовы}.


2. **Формат вывода:**
- Таблица с колонками:
| № предложения | Исходное предложение | Адаптированный перевод предложения с подробными пояснениями по сложным терминам|
- После таблицы — сводка:
*Пример:*
"Принято в обработку 15 предложений, переведено 15 предложений, из них адаптировано 7 предложений. "
- После сводки — резюме по обработанным терминам:
*Пример:*
| Термин на русском | Термин на английском | Использованное объяснение |
| Пайплайн RAG | [Retrieval-Augmented Generation] | {Retrieval-Augmented Generation (RAG) — это гибридная ИИ-система, которая сначала ищет информацию в базах данных (как поисковик), а затем генерирует чёткий ответ (как ChatGPT). В отличие от обычных языковых моделей, RAG всегда опирается на актуальные источники, избегая выдуманных фактов. Технология применяет векторный поиск для быстрого нахождения релевантных данных и языковые модели для их обработки. Используется там, где важна точность: в поддержке клиентов, медицине или юриспруденции. По сути, RAG — это "эксперт", который сначала проверяет факты, а потом объясняет их простым языком.}|.


---

### Пример реализации в форматированной таблице:

| № предложения | Исходное предложение | Переведенное предложение |
| 001 | The RAG pipeline improves LLM outputs. | **Пайплайн RAG** [Retrieval-Augmented Generation] {метод дополнения генерации данными} улучшает результаты работы **LLM** [Large Language Model] {языковой модели на основе ИИ}. |


### Текст на анализ и разбор

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

Пришел запрос на индивидуальное обучение по переводу в теме ИИ.

Составил такую программу:

1. Чат-боты и NLP (Диалоговые системы, intent-распознавание, мультимодальные ассистенты.)
2. Рекомендательные системы (Персонализация, A/B-тестирование.)
3. Компьютерное зрение (CV) / Сегментация изображений, обнаружение аномалий, промышленное применение
4. Генеративный ИИ (Генерация текста, изображений, видео, настройка генерации)
5. Автономные агенты (GPT, RAG, планирование задач)
6. MLOps/AIOps (Развертывание моделей, мониторинг, feature store.)
7. ИИ в кибербезопасности (Обнаружение атак, анализ поведения, adversarial attacks.)
8. Мультимодальные модели (Обработка текста, изображений, аудио в одной системе.)

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

Учитывая, что ИИ может делать простые переводы почти без человека, акцент в практикуме делаю на сложных и серьезных публикациях (типа arxiv.org). Их не стыдно, если что, вешать на Хабр, я там укажу имя слушателя, будет проект для портфолио.

Вопросы в личку: t.me/bartov_e или в мыло bartov-e@ya.ru

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

Пришел заказ на подготовку цикла статей из видеовыступления.
Казалось бы - простая задача:
1. Выкачиваешь видео, выдираешь аудиодорожку.

2. Скриптом аудиодорожку прогоняешь через скрипт распознавания речи (тут, кстати, ждет первая засада - ИИ не принимает файлы больше 25 мб, значит, нужно сделать вспомогательный скрипт, который перед отправкой полуторачасовое выступление нарежет на файлики)

3. Распознанную речь по идее надо отправить на ИИ, занимающийся литературной правкой. Тут ждет проблема - если прямо вот так большим куском закинуть ИИ этот текст, ИИ может его отказаться принимать (контекстного окна может не хватить), или если примет - то середину жестко зажует (будет как в том анекдоте с вороной и сыром — "Нифига себе басню сократили!!")

4. Получается, нужно подробить текст на кусочки и скармливать их ИИ по очереди. Но как понять, где нужно логически разбить эти кусочки? Где у лектора суть, а где он просто сделал лирическое отступление? Где важная деталь, а где неважная? Чтобы нормально расчлениь текст на абзацы - нужно знать, о чем этот текст (следовательно, оператор тоже должен как минимум целиком просмотреть все видеовыступления - чтобы быть в контексте и понимать, где машина хорошо оптимизировала текст, а где перегнула палку).

Потом еще есть 5, 6, 7, 8 этапы, на которых ИИ то галлюцинирует (добавляя невесть откуда взявшуюся статистику), то своевольничает - выкидывая критически важные технические подробности под предлогом "Я посчитал, что для вашей целевой аудитории это чересчур дебри". В итоге ты скатываешься к тому, что буквально под роспись принимаешь каждое переработанное ИИ предложение.

И в итоге работа с ИИ превращается в постоянный надзор как за мартышкой в космосе - это не выкидывай, вон то не трогай.
Быстрее пошел процесс? Да, безусловно быстрее - раза в 3-5 ускорение получается.

Стало ли легче? Да, стало, раньше варианты набрасывал ты сам, сейчас их набрасывает машина, ты только выбираешь.

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

В своем недавнем выступлении в Челябинске (организаторы его на записали, но я что-то подобное недавно читал студентам из местного вуза, могу скинуть видео в личку), я упоминал технологию RAG, retrieval augmented generation — она предназначена для "докручивания" движка LLM, large language model = языковой модели (упрощенно говоря нейропереводчика) под проектную специфику или ваш узкий контекст.

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

Мои поиски привели меня к научной публикации на сайте arxiv.org (там много такого научного добра), и я решил, что надо эту тему как-то популяризовать. Насколько удачно получилось, не знаю, но перевод первой части подвесил по этой ссылке: https://habr.com/ru/articles/893650/

По замыслу в планах еще 4 части к переводу готовятся. Плюс коллеги другие материалы по LLM готовят, чтобы все было по науке, по взрослому и без хайпа.

Информация на подумать

Сегодня обратилась клиентка, Екатерина, записалась на обучение по ИТ. Поскольку под каждого студента я готовлю программу индивидуально, поговорили о ее целях обучения. Екатерина просто хотела переводить в теме СУБД, с английского на русский и с русского на английский. Ну, ок. Бывает.

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

— А как вы смотрите на то, что мы с вами отработаем вопросы с собесов? Они довольно практичные, там нет ненужной теории, сплошная практика - ее спрашивают со специалистов, за нее платят им деньги, и раз так — то и от современного ИТ-переводчика, который заявляет свою специализацию в теме СУБД, при переводе тоже будут ожидать этих знаний.
Вот я и предлагаю взять вопросники, и проработать упоминаемые там концепции. А учитывая, что в этих вопросниках очень много вопросов с подвохом, то значит и нюансы терминологические мы тоже отработаем. Значит, и работу у ИИ вы сможете вполне себе со знанием дела принимать и проверять.

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

Что думаете?

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

Просто к нам обратился клиент, попросил оценить бюджет на перевод его сайта, выгрузки сайта не было — сайт надо было качать. Можно это делать программой-качалкой, но они у меня что-то в последнее время криво работают и ломают структуру сайта, поэтому набросал скрипт на Питончике, который и кодировку нормально ловит, и структуру не ломает. Сайт в 200+ страниц скачался за 3 минуты.
Удобненько.
import os
import requests
from bs4 import BeautifulSoup
from urllib.parse import urljoin, urlparse, unquote
import re

# Настройки
BASE_URL = "https://example.ru" # Замените на URL сайта
SAVE_DIR = r"H:\Downloads\TheWebSiteFolder" # Папка для сохранения страниц

# Создаем папку для сохранения страниц, если она не существует
if not os.path.exists(SAVE_DIR):
os.makedirs(SAVE_DIR)

# Множество для отслеживания уже посещенных страниц
visited_urls = set()

# Функция для скачивания страницы
def download_page(url):
try:
response = requests.get(url)
response.raise_for_status() # Проверяем, что запрос успешен
response.encoding = response.apparent_encoding # Устанавливаем корректную кодировку
return response.text
except requests.RequestException as e:
print(f"Ошибка при загрузке страницы {url}: {e}")
return None

# Функция для создания пути к файлу на основе URL
def get_filepath(url):
# Убираем протокол и домен
parsed_url = urlparse(url)
path = parsed_url.path

# Убираем начальный и конечный слэши
if path.startswith("/"):
path = path[1:]
if path.endswith("/"):
path = path[:-1]

# Если путь пустой, используем index.html
if not path:
path = "index.html"
else:
# Если путь не заканчивается на .html, добавляем /index.html
if not path.endswith(".html"):
path = os.path.join(path, "index.html")

# Декодируем URL (например, заменяем %20 на пробелы)
path = unquote(path)

# Создаем полный путь
filepath = os.path.join(SAVE_DIR, path)

# Создаем папки, если они не существуют
os.makedirs(os.path.dirname(filepath), exist_ok=True)

return filepath

# Функция для сохранения страницы на диск
def save_page(url, content):
filepath = get_filepath(url)
with open(filepath, "w", encoding="utf-8") as file:
file.write(content)
print(f"Страница сохранена: {filepath}")

# Функция для извлечения всех ссылок на странице
def extract_links(url, content):
soup = BeautifulSoup(content, "html.parser")
links = set()
for link in soup.find_all("a", href=True):
full_url = urljoin(url, link["href"])
# Убираем якорь (#) из URL
full_url = re.sub(r"#.*$", "", full_url)
if full_url.startswith(BASE_URL): # Скачиваем только ссылки, относящиеся к этому сайту
links.add(full_url)
return links

# Рекурсивная функция для обхода сайта
def crawl_site(url):
# Убираем якорь из URL
clean_url = re.sub(r"#.*$", "", url)

if clean_url in visited_urls:
return
visited_urls.add(clean_url)

print(f"Обработка страницы: {clean_url}")

# Скачиваем страницу
content = download_page(clean_url)
if content is None:
return

# Сохраняем страницу
save_page(clean_url, content)

# Извлекаем ссылки
links = extract_links(clean_url, content)

# Рекурсивно обходим все ссылки
for link in links:
crawl_site(link)

# Запуск обхода сайта
crawl_site(BASE_URL)

print("Скачивание завершено!")

В личку обратился клиент, попросил сделать ему аудиокнигу на английском с помощью ИИ. У клиента жесткий цейтнот, при этом нужно готовиться к экзаменам по медицинской дисциплине.

Поскольку объем книги несколько сотен страниц, я посчитал, что целесообразно этот процесс автоматизировать. Использовал Python, подключил голосовую модель типа text-to-speech, сгенерил несколько голосов, сделал предложение клиенту по тарифу озвучки за 1000 слов.

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

P.S. Это к слову о новых скиллах переводчика (из прошлого поста) — учимся автоматизировать всё. Иначе ловить на рынке нечего, имхо.

P.P.S. Для внутренней автоматизации у меня пока личный рекорд - 80 тыс. проверенных слов за 2 суток. Примеры из этой проверки включу как раз в завтрашнюю презентацию.

Завтра в ЧелГУ (https://facultetus.ru/activity/248542) буду рассказывать про эволюцию переводческих инструментов и требуемых скиллов, место переводчика на рынке переводов при такой эволюции и в целом, как дальше жить.

Объясню немного про технологии LLM, Transformer, RAG, mixture-of-experts, температуру модели, контекстное окно, эмбеддинги - и чем это поколение технологий отличается от поколения CAT, TM, TB и fuzzy matches.


Если получится сделать запись, закину сюда.

«Генераторы» и «генераторы списков» в Python: в чем разница? 🤔

На одном из ИТ-проектов возникла путаница с терминами «генератор» [generator] и «генератор списка» [list comprehension]. Эти понятия выполняют разные задачи, давайте разбираться.

Генератор списка [List Comprehension] 📋

Генератор списка — это компактный способ создания списка в Python. Он позволяет быстро сгенерировать список на основе другого списка или итерируемого объекта (т.е. перебираемой последовательности). Например, если у вас есть список чисел, и вы хотите создать новый список, где каждое число возведено в квадрат, генератор списка сделает это в одну строку:

numbers = [1, 2, 3, 4]
squares = [x**2 for x in numbers] # [1, 4, 9, 16]

Синонимы: списковое выражение, comprehension.

Как переводить: «генератор списка» или «списковое выражение». Например: «Используйте генератор списка для создания нового массива».


Генератор [Generator] ⚙️

Генератор — это объект, который позволяет итерироваться по любой последовательности значений, не создавая их все сразу в памяти (иначе памяти не напасешься). Это особенно полезно при работе с большими объемами данных. Генератор создается с помощью функции с ключевым словом yield:

def generate_numbers():
for i in range(5):
yield i

# Использование
for num in generate_numbers():
print(num) # 0, 1, 2, 3, 4

Синонимы: итератор, ленивый итератор.

Как переводить: «генератор». Например: «Функция возвращает генератор, который последовательно выдает значения».



В чем разница? 🤷‍♂️

1. Память: Генератор списка создает весь список сразу, занимая память. Генератор выдает значения по одному, экономя ресурсы.
2. Использование: Генератор списка подходит для создания небольших списков. Генератор — для работы с большими или бесконечными последовательностями.
3. Синтаксис: Генератор списка использует квадратные скобки [], а генератор — круглые () или функцию с yield.

---

Пример для перевода 📝

Оригинал: «Use a list comprehension to filter even numbers and a generator to process large datasets.»

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

---

Вроде всё. Спасибо за внимание.

Довольно часто в ИТ-проектах приходится править переводы терминов null, zero, undefined — переводчики иногда считают их взаимозаменяемыми. Это, разумеется, грубейшая ошибка.

Если x = 0, значит, с ним уже можно делать разные математические операции. Это zero.

Если вы ввели в свою программу переменную х, но пока не присваиваете ей никакого значения, отложив сей ответственный шаг на потом, например, когда ситуация прояснится — то программисты в таких случаях используют термин null (т.е. значение не задано, и это точно не означает, что х равен нулю, если только по умолчанию где-то кто-то на x такое значение подвесит). Программистам категорически не рекомендуется оставлять переменные непроинициализированными, но тем не менее - название у такого явления есть. Иногда еще используют empty.

А вот если вы где-то в программе решили использовать переменную x, забыв при этом вообще ее ввести в программу, то эта ситуация undefined. Не перепутайте :).

P.S. В С# есть еще понятие nullable — о нем отдельно.

А еще вот такие переводчики тоже нужны :)))

Очень много букв. Изначально исходную статью писали для разработчиков — у них схожие с нами, переводчиками, опасения относительно ИИ. Кто-то запаниковал, автор считает, что зря. Подробности в статье.

Я прочитал ту статью и понял, что она тоже применима к нам, но с некоторыми оговорками и с учетом переводческой специфики. Адаптировал, получилась эта статья. Читайте. В первую очередь посвящается студентам переводческих факультетов.

P.S. В ней есть спорные моменты, но в целом наблюдения подтверждаются, в том числе и моими граблями работы с ИИ (на больших проектах с ИИ все не так просто, как кажется).

P.P.S. С удивлением для себя обнаружил, что даже многие ИТшники не дружат с ИИ.

http://vk.com/@tran_su-konec-perevoda-v-ego-nyneshnem-vide

Я смотрю, инженеры уже как-то философски относятся к хреново написанной документации..

Индикаторы.. идентификаторы... какая разница...😉

У меня примерно такая же проблема с устным английским вообще (не только индийским). В этом разница между устниками и письменниками. Стало чуть получше после того, как вебинары в статьи стали заказывать - подтянул аудирование.

А так совсем тугоухий был :-)

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

Хорошо, что в переводах такого не бывает. 😉

Получил от клиента правку, у меня было «заём», гуглодок подчеркнул слово, клиент исправил на «займ».

Прав ли клиент? Нет, клиент не прав.

Если посмотрим в Грамота.ру, то там русским по белому написано, что в именительном падеже ед. числа будет «заём» , а во всех остальных падежах уже будет основа "займ". (https://gramota.ru/biblioteka/spravochniki/slovar-trudnostey/zaem)

Возникает вопрос: речь же про именительный падеж, а про винительный не сказано. Значит там будет «займ», и клиент все же прав?

Ответ: нет, всё равно не прав. Правило написано неполностью, и справочная служба Грамоты это уточняет: форма именительного падежа и винительного совпадают, так что «заём» будет в двух падежах. А в остальных «займ» (https://gramota.ru/spravka/vopros/309473#question).

P.S. Сейчас на большинстве баннеров/постеров пишут «займ», в советское время за этим следили тщательнее (см. плакат).

Ну хоть доплату не требуют за право попереводить... 🤦‍♂

База.

Мысли вслух.

🤖 Чем больше работаю с ИИ-переводчиком, тем больше убеждаюсь, что это напоминает игру: «Верю — не верю».

💬 ИИ предлагает свою интерпретацию, и он, гад, научился-таки её формулировать правдоподобно.

🧐 Но каждый раз тебе нужно решить — правильный перевод он предложил или приврал где-нибудь?

💼 Это значит, что халява отменяется — если ты не знаешь предмет или не понимаешь исходный текст, он всё равно тебя подловит и выставит дураком.

Уроки спеллинга.

Волки тут есть? 🤓

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

🔍 В данном случае, метод find в коде пишется маленькими буквами, если начать его с большой — Python не поймёт. Поэтому приходится править.

✨ Как вариант, нужно формулировать так, чтобы имя метода или переменной в начале предложения не стояло. Здесь тоже можно начать как "Метод find()... ", но мне что-то не хочется.

Да-да, и на старуху бывает....
Взял проект на 2 месяца, в марте уже год ему исполнится, конца и края не видно 🤦‍♂️

В продолжение предыдущего поста (о редактуре, не о субботе).

Есть хороший вариант обходиться без родового слова — просто построить предложение так, чтобы на неудобный английский термин во мн. числе указывало слово, у которого есть категория мн. числа.
В данном случае:

... включая вездесущИЕ RESTful API, которЫЕ предоставляЮТ...

Просто у редактора случилась суббота :).

Также часто приходится править проскакивание "s" — окончания множественного числа в английском языке, попадающего в русский текст. 😅

Например, здесь проскочило в виде "APIs". Проблема усугубляется тем, что если убрать это "s", то по аббревиатуре вообще непонятно становится — множественное там число или единственное. 🤔 Решение классическое — просто в таких случаях добавляем родовое слово (в нашем случае "интерфейсы"), а английское окончание "s" всё равно убираем. ✨

Когда тебе позарез нужен перевод термина, а его, блин, нет ни в одном словаре... 🤓

Тоже одна из частых правок в ИТ-переводах 😊— это как обозначить одну версию относительно другой.

Проблема в том, что чем ВЫШЕ ⬆️ номер версии, тем она МЛАДШЕ 👶🏻. И наоборот, чем НИЖЕ ⬇️ номер версии, тем она СТАРШЕ 🧓🏼.

Но по привычке переводчик может переносить логику человеческого возраста на понятие программы, в результате чего получается так как на скриншоте 😉.

Тоже одна из частых правок в ИТ-переводах 😊— это как обозначить одну версию относительно другой.

Проблема в том, что чем ВЫШЕ ⬆️ номер версии, тем она МЛАДШЕ 👶🏻. И наоборот, чем НИЖЕ ⬇️ номер версии, тем она СТАРШЕ 🧓🏼.

Но по привычке переводчик может переносить логику человеческого возраста на понятие программы, в результате чего получается так как на скриншоте 🤷🏿‍♂️.

Отмазки не принимаются

Отмазки не принимаются.

Из диалогов:
- Я запрещаю вам использовать ИИ для редактирования моей книги.
- Любопытно. Почему?
- Я не доверяю его возможностям.
- Очень странно это слышать от автора книги об использовании ИТ и ИИ в нацпроектах.

Вакансия без лишних слов.

Еще одна причина учить иностранные языки 😱

Представьте, что REST (Representational State Transfer) — это кодекс законов для идеального города 🏛📜. В нём прописано:
• Как должны называться улицы (URL-пути).
• Как общаться между районами (HTTP-методы: GET, POST, PUT, DELETE).
• В каком формате передавать посылки (JSON/XML).
• Какие флаги поднимать при успехе или ошибке (статус-коды: 200 OK, 404 Not Found).

А RESTful API — это город, построенный строго по этим законам 🏙✅. Здесь всё предсказуемо:
• Пожарная станция всегда на углу /fire-stations/{id}.
• Письма доставляются только курьерами в униформе (POST-запросы для создания данных).
• Даже указатели (HATEOAS) говорят: «Чтобы найти больницу, иди налево» 🗺.
• Возможно, даже жители ходят строем и в ногу, но это неточно 😉

А что такое REST API?
Это город, где законы соблюдают... иногда 🏘🚦. Например:
• Магазин называется /getGroceries, хотя по правилам должен быть /groceries + метод GET.
• Почта принимает посылки в формате «как получится» (например, текстовые строки вместо JSON).
• Фонари горят розовым, но все делают вид, что это «почти как в законах REST» 🌸😅.
• И шаурму делают с заливной рыбой 🐟 , а не с куриным мясом 🐓. Какая гадость 🤢.

Метафора из жизни
REST — рецепт супа 🥣: ингредиенты, порядок, время варки.
RESTful API — суп, где всё по рецепту: морковь нарезана кубиками, бульон кипит ровно 20 минут.
REST API — суп, где вместо картошки батат, а вместо соли — соевый соус. Вкусно? Может быть. По рецепту? Нет ❌.

👉 Почему это важно?

RESTful API как лего: детали идеально стыкуются, и любой разработчик поймёт, как с ними работать.
REST API как конструктор с нестандартными деталями: собрать можно, но придётся допиливать 🔧🪚.

🎯 Что в итоге?

Если API полностью следует принципам REST — используйте RESTful API (как знак качества 🏅).
Если есть отклонения — пишите REST API, но уточняйте: «основано на REST, но с изменениями» 🔄.

🚀 Запоминаем:

REST = правила.
RESTful API = идеальная реализация правил.
REST API = реализация правил с компромиссами.

Часто наблюдаю, что переводчики не различают REST API и RESTful API, и при переводе используют их взаимозаменяемо, предпочитая более короткий вариант (RESTful >>> REST). Однако это разные понятия. Попробую пояснить на пальцах.

О — оптимизация.

Письмо?! Для начала — отредактировать ...

📚 В книге говорится, что Майк Босток (кстати, кто это?) снял шляпу перед Полом Айришем (а это кто?) за то, что тот как-то круто оптимизировал базовую структуру HTML4. Посмотрел на разницу. Ну в целом, да, наворотов стало меньше (см. ещё скриншот №2), хоть клавиатура теперь не так сильно изнашиваться будет. Заодно выяснил и про шляпу на UrbanDictionary (см. скриншот №3) — к шляпе это никакого отношения не имеет, это просто проявление благодарности в отношении автора какой-то удачной идеи (один другого поблагодарил в блоге). Ну типа, "отдельная благодырочка [такому-то товарищу] за суперидею".

🌟 Осталось выяснить, кто эти персонажи. Выяснить труда не составило, потому что это широко известные в узких кругах люди. Майк Босток — разработчик мощного JS-пакета D3 для графики (если в интернете вы видите крутую динамичную инфографику, скорее всего, она построена на этом пакете), а Пол Айриш — это разработчик браузера Google Chrome и — виновник этого поста — HTML5, за который он и получил свою шляпу благодарственную грамоту от Майка.

🔄 Возвращаемся к переводу. Надо ли его править? Думаю, что надо — нужно убрать оттуда "шляпу" и добавить хотя бы минимальные пояснения по этим товарищам. Сказано — сделано, см. скриншот №5.

🕵️‍♂️ При разборе ИТ-перевода мне попалась фраза (см. скриншот №1), которая напомнила «Трёх мушкетёров», где мушкетёры постоянно снимают шляпы друг перед другом в знак благодарности. 🎩 Правда, есть небольшой нюанс — времена мушкетёров давно прошли, Майк Босток это всё-таки не Майк Боярски, поэтому какого фига он тут размахивает шляпами? И по какому поводу? Полез в книгу (см. скриншот №2).

Каждый препод должен уметь объяснить на пальцах сложные вещи. Вот, учимся. 😳🤓😜

⚡️ Итак, при выполнении какого-то условия — например, успешного завершения уровня — игра сохраняется. В программировании, при отладке приложений, такие автоматические сохранения называются "условными точками останова". 🛑

Как вариант, если ты пишешь компьютерную игру и вдруг в какой-то точке твой герой начинает внезапно вести себя как после большого бодуна, разработчик ставит условную точку останова прямо перед этой точкой, и выполнение кода останавливается прямо в ней. 🕵️‍♂️ Можно в остановленной игре/программе посмотреть состояние переменных, окружения и т.п., чтобы понять, что пошло не так.

👿 Другой пример. Снова проходим Doom 2, ты знаешь, что сейчас перед тобой поле с лавой — и пройдешь ты его или нет, особенно, когда тебя атакуют манкубусы, большой вопрос. 🔥 В таких случаях ты сохраняешься сам в этой точке — в случае чего к ней же и вернёшься. В программировании, в теме отладки кода это называется "параметрической точкой останова". 🧐 Опять же по аналогии с написанием программы: герой ходит, собирает аптечки, вдруг в руках вместо базуки у него оказывается балалайка. 😱 Потом пропадает. Потом снова собирает аптечки и патроны, появляется снова балалайка. Да откуда, блин? Вот можно поставить точку останова, что при срабатывании определённого параметра ("появления в арсенале балалайки"), игра останавливается. 🛠 Дальше уже можно лезть под капот и смотреть, откуда она появилась.

➡️ Подытожим: условная точка останова — это остановка программы в заранее заданных местах, параметрическая точка останова — это остановка программы при срабатывании заданного условия.

🤔 К чему это я?

В переводе переводчик перевёл parametric breakpoint (см. скриншот) как «условная точка останова».

🗣 Спрашиваю: "Почему не параметрическая?"

🙄 Ответ: "А разве это не одно и то же?"

📝 Отвечаю: "Нет. Щас накатаю ответ."

Ну вот. Накатал. 🖋

🎮 Я раньше любил играть в Doom 2, естественно, там надо было проходить уровни. 🏃‍♂️ При прохождении уровня, если я правильно помню, игра автоматически сохранялась (перепроходить уровень не надо было). 💾 Соответственно, если на новом уровне меня вдруг замочат, я всегда мог начать этот же уровень заново.

Вы думаете причем тут перевод? Про него чуть ниже.

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

Как я потом выяснил, я не один такой. Одна из моих слушательниц, очень офигенный препод по английскому (жила в Америке и знает инглишь, как боженька), тоже благополучно завалила экзамен на знание английского. 🙈

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

Был один проект, где после этой фразы с клиентом случилось еще 15 раундов правок 🎻

Я тогда сказал команде: когда мы сдадим этого клиента, я уйду в запой на три дня 🥃

📝 Краткая заметка про amortize 🎉

Amortize – это не всегда про устаревание (к этому больше подходит глагол depreciate). 😜

В случае со скиллами, оно даже по логике не подходит — если у читателя нет деменции, и он не забывает изученное 🙂.

Речь идет о том, что читатель быстро окупит свои усилия/вложения/время/ресурсы, вложенные в получение этих базовых навыков! 💪✨

Автор написал несколько двусмысленную фразу о происхождении этой разницы в точности измерения времени между языками программирования, и её можно понять так, будто мы сами что-то округлили для удобства. Конечно, пришлось не только исправить, но и уточнить, почему это произошло: «JavaScript использует миллисекунды, а Python — микросекунды».

Также убрали слово «обратно» (об этом сделаем Прим. пер., разумеется), ведь иначе могло показаться, что это наша прихоть, а не особенности реализации временных форматов. 🐍📱

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

Вопрос: имеет значение, на каком языке программирования написано это приложение — на JavaScript или на Python? Оказывается, да: JavaScript измеряет время в миллисекундах, а Python — в микросекундах. Соответственно, кому-то из спортсменов такой нюанс может стоить победы. По продолжительности это примерно столько же времени, сколько понадобилось вашему мозгу, чтобы обработать эту информацию. 🧠⚡️

Казалось бы, при чём тут переводы? А вот причём.

Ну что, дорогие мои. Настроились уже? Скоро уже, потерпите чуть-чуть.... 😜

С моей, редакторской колокольни эта новость выглядит так: «А вот не надо черточки где-попало ставить».

Рискну предположить, что числа прописью формирует уже банковский софт. В итоге он, софт, "-" перед числом преобразовал в прописное слово "минус", естественно, договор манагер перечитывать не стал (ибо чтение — это забава для задротов) — и опс... попадалово на 4 ляма.

А все началось с всуе поставленной черточки...

Кредитная компания из Тюмени подарила 2 млн рублей своему клиенту из-за опечатки в документах. Предприниматель занимал 10 млн под 20% годовых, но менеджер опечатался и прописал в документе «минус 20% годовых». Теперь мужчина должен вернуть только 8 млн рублей, а расторгнуть договор компания не может без согласия клиента. @bankrollo

Когда затягивает в редактуру...

Как думаете, когда в вакансии пишут "технический переводчик с релевантным опытом работы", какую именно технику эйчары имеют в виду?

Я тут чатбота спросил, даже он мальца растерялся и насыпал вариантов :)

Ну всё, неделька закончилась, настраиваемся на понедельник :) Какой-нибудь...

Все так, но базу от Аль Капоне не забываем: "Хороший переводчик и ИИ смогут сделать больше, чем просто хороший переводчик". 😉

Учимся формулировать мысли корректно с медицинской точки зрения.

Эта загадка в общем-то тоже не вызвала особых сложностей.
Довольно часто advanced в ИТ переводят как "современный" (advanced technologies), чтобы не лепить кальку в виде "продвинутый" (хотя ИТшники к ней уже привыкли). Назвать декораторы современным механизмом у переводчика рука не поднялась, т.к. им сто лет в обед и впервые они появились в версии Python 2.4 (т.е. в 2004 году). Собственно, поэтому уточнение в переводе и появилось.

Проблема в том, что под advanced автор здесь подразумевал не современность, а сложность. То есть для джунов и новичков это не самая базовая конструкция, но для миддлов/сеньоров - она уже вполне себе рабочая и рутинная. Вот и получилось - relatively advanced.

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

Не психи, а переводы.

Автор снова решил устроить весёлую головоломку своими двусмысленностями! 😜 На экране скриншот абзаца. Ключевой вопрос — к чему относится keyword?

Грамматика намекает, что это про __tablename member__. Но если посмотреть на код, то __tablename member__ оказывается всего лишь именем атрибута (как у гантельки бывают атрибуты под именем "вес", "длина", "цвет"). 🏋️‍♂️

Логика Python подсказывает, что keyword относится к name, но грамматика против, поскольку автор сделал name глаголом (to name). 😮‍💨

В итоге, кунг-фу логика Python оказывается сильнее грамматики и всё-таки побеждает name. Вариант перевода пришлось слегка перекроить, иначе смысл совсем уплывает . 🌊

Stay tuned! 👀 🦻📻

Кажется, что у меня есть небольшая навязчивая идея... 😅 Дело в том, что у меня начинает дергаться глаз, когда встречаю абстрактные или "бесхозные" местоимения. Это такие штуки, которые вроде бы должны что-то обозначать, но читателю приходится гадать, что именно! (Тоже много раз про это писал, попался хороший пример)

Например, вот эта фраза на скриншоте: "Если всё нормально...". "Всё" - это что конкретно? 😕

В таких ситуациях приходится делать за писателя его работу и разворачивать формулировку, чтобы читатель не нафантазировал там себе всякое. Автор вообще ленивый, я смотрю — у него просто If successful! 💪😄
Имхо, лучше перебдеть.

Айтишники осваивают фонетику.

Тоже мотаем на ус.

Пожалуй, на вечер добавлю вам и вторую загадку 🤫. На этот раз от автора.

Следите за руками – сейчас будет магия 🎩✨. Итак, автор приводит код и объясняет, что он якобы сортирует строки по алфавиту 😏.

Вопрос: почему на выходе по алфавиту выстроились не все строки? (Я отметил, какая строка решила пойти своим путём 🚶‍♂️).

Подсказка: проблема не в Python 🐍 - с ним всё хорошо. Проблема в голове. Какая?

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

Пишут обычно, как вдохновение ляжет, здесь это:
- you need to tell...
- we'll sort ...
- writes ...

При переводе категорически топаю ногой и требую рекомендую все приводить к единому знаменателю (если вписывается в логику):
- Указываем...
- Сортируем ...
- Записываем ...

Как раз одна из тех книжек про зоологию, которые мы шпарим :)

Насчет heddggehog не знаю, но bugs там хватает :)

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

P.S. Ответ дам через 24 часа. Пока набрасывайте гипотезы.

Че-то последние 4 дня ношусь, как белка в центрифуге, причем не по бюрошным делам.

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

Стэй тьюнд.

Я в устном переводе не силен, но кажись, переводчица тоже :-))

Я в устном переводе не силен, но кажись, переводчица тоже :-))