Книга в договоре указана как "100 ошибок PostgreSQL и как их избежать(PostgreSQL Mistakes and How to Avoid Them), автор Джимми Ангелакос (Jimmy Angelakos) ", это рабочее название, с каким названием дойдет до печати - не знаю, это от переводчика не зависит.
Спасибо за обзор, хотел сам что-то подобное написать. Скоро, думаю, книга появится на русском языке, на этой неделе заканчиваю ее перевод (по заказу издательства «Питер»).
Помимо описанных типов данных, автор в конце книги еще довольно развернуто пишет про "глюки", которые могут вызвать разные реализации булевых типов в известных СУБД при миграции в Postgres.
Если позволите, на правах коллеги, ИТ-переводчика, который не чужд автоматизации и ИИ, немного выскажусь:
1. Про объем переводов
Профессиональный перевод через ИИ (я про SOTA-модели с хорошими бенчмарками, типа DeepSeek) - это пока вообще не про объем. Это скорее про некоторое ускорение рутины. Это по прежнему довольно кропотливая работа, только если раньше я переводил по предложениям, сейчас по абзацам. Чуть больше 2 абзацев текста в модель закинешь, будь готов к тому, что она начнет жертвовать деталями, в т.ч. и смысловыми. Тут конечно, многое зависит от длины самих предложений - на длинных предложениях модель захлебывается быстро (даже с хорошо отдебаженным промтом на длинных предложениях технические нюансы плывут — то предлог не тот, то термин близкий, но не тот, то причина со следствием перепутаны или изложены двусмысленно). Поэтому о том, чтобы грузить главами/книгами или даже цельными страницами, и ожидать, что будет коммерческий перевод, пока речь не идет.
2. Про терминологию
Частично проблема терминологии решается промт-инжинирингом и RAG. Но там тоже нужно учитывать, что классические глоссарии, в которых термины отсортированы по алфавиту, не подходят. Я пока пришел к решению, что термины нужно раскладывать группами вокруг однословных терминов, тогда эмбеддинги у таких групп точнее соответствуют запросу и термины подтягиваются. Как нибудь напишу статью про этот подход, но вкратце изложил здесь - https://t.me/alliancepro/3484, здесь - https://t.me/alliancepro/3428, и здесь - https://t.me/alliancepro/3389.
3. Адекватность исходного текста.
Тут я скажу слово в защиту ИИ - при хорошо подобранных материалах для RAG модель неплохо страхует. Как минимум она заставляет обратить внимание на вещи, которые при прочих равных я бы упустил или истолковал бы иначе.
А вот от подхода - сделать машинный перевод всего текста без корректировок, а потом только корректировать - я отказался. Причина простая - текст выходит настолько грязный, что приходится его местами переписывать заново. Одна из причин, модель смотрит историю своей выдачи - и даже если там полная фигня, она все равно считает ее приемлемой (пользователь же не возмутился?), и делает еще больше допусков на ошибки (на рекуррентных моделях это кажется, называлось в духе взрыв/затухание градиента, но могу ошибаться).
Поэтому сейчас подход (как я уже упомянул выше) такой: закинул 2 абзаца, получил выдачу, почитал - если не шлак - закидываю в черновик, для последующей вычитки. Если шлак - корректирую промпт или прямо в черновике. Как правило, при таком подходе корректировки в итоге выходят минимальными. В общем, тут напрашивается аналогия со студентом, сессией и гвоздями (https://pikabu.ru/story/s_univera_zapomnil_anekdot_9750706)
4. Проблема эксперта Она была вообще всегда, что с кожаными переводчиками, что с цифровыми. К ИИ тут претензий нет, тем более, что он даже подстраховывает.
В частности, я иногда преподаю ИТ-перевод в вузе, и до ИИ, то что студенты мне сдавали в своих работах, без слез читать было невозможно. Сейчас переводы у них стали поприличнее - сказывается помощь ChatGPT :).
Добавлю лишь, то что "эксперт" тоже не гарантия. Я когда переводил PCI DSS, в аннотации к стандарту было написано, что его проверяло более 600 экспертов по всему миру. Тем не менее, мы с аудиторами-консультантами после этих 600 экспертов еще пару добрых десятков смысловых косяков выловили, в т.ч. со взаимоисключающим смыслом. Я даже на одной ИБэшной конфе на эту тему доклад делал :).
5. Конфиденциальность. Я вообще скептически к ней отношусь, поскольку занести деньги - если уж на то пошло, могут и к почтовому провайдеру отправителя или получателя (мы же не голубиной почтой пользуемся, верно?). Да и сервисами мы часто пользуемся со смартфона - тоже весьма уязвимая штука. Так что, на мой взгляд, ИИ тут особо картину не меняют - просто одной дырой больше.
==
В остальном со статьей согласен. ИИ безусловно помогает, но намного меньше, чем кажется многим заказчикам. Пока терпим, улыбаемся и пашем - хороший перевод как был рутинным, так пока им и остается. Терпимо хреновенький да, стало делать в разы проще.
Боюсь, не смогу ответить на этот вопрос, т.к. никоим образом не в курсе планов издательства — мое дело маленькое. Могу лишь предположить, что ИТ-литературу оно должно выпускать оперативно, т.к. иначе она быстро протухает.
Рискну предположить, что ближе к концу года, наверное, выпустят.
Здравствуйте. Вы столько много умных слов написали, я их не знаю. Наверное этос связано с тем, что домашними решениями не пользуюсь и не рассматриваю - возможности компа не позволяют (я же переводчик, а не ML-инженер), пользуюсь облачными провайдерами. Использую text-embedding-3-large + реранкинг от BAAI
Спасибо, Мария, за развернутое описание процесса и за то, что упомянули нашу скромную команду как локализаторов и переводчиков. Если позволите, немного дополню.
Отмечу, что с момента нашего разговора утекло много воды, и мы улучшили наш подход к работе с терминами, чтобы подготовленный словарь можно было использовать в системах RAG (ИИ).
Основная проблема в том, что когда слова расположены по алфавиту в глоссарии, RAG их плохо видит - для него суммирующий эмбеддинг чанка из куска глоссария выглядит как средняя температура по больнице, поскольку между соседними словами нет ничего общего.
В итоге я доработал Python-скрипт, чтобы он мне выдавал термины группами, вокруг гнездового термина. Например, если у меня в есть гнездовой термин team, то вокруг него можно подтянуть/сгруппировать термины sales team, support team, team member и т.д.
Разумеется, для каждого термина подтягивается группа предложений, из которых он был взят. Это нужно для дальнейшей обработки термина через LLM - когда ей на вход подают термин и группу предложений, и просят найти оптимальный перевод конкретного термина, модель в целом справляется неплохо (у вас упомянут Гигачат, но я так и не понял из вашей методологии, просили ли вы просто его дать определения, или просили дать определения с учетом ваших контекстов).
В итоге мы получаем глоссарий, который можно прицеплять в базу знаний модели и пользоваться им. Алфавитный глоссарий в LLM работает явно хуже.
На здоровье :). Может как-нибудь и доберусь до курса, но пока еще копаю. На Arxiv много интересных публикаций, скоро опубликую новую - о том, как тестировать связку RAG+LLM (в технических переводах это важный момент).
Благодарю за комментарий. У меня не было возможности сравнить то, как было раньше с тем, как есть сейчас, но могу уверенно сказать, что то, как есть сейчас, меня категорически не устраивает — модели постоянно зажевывают середину. Собственно, это и стало одной из причин, по которой я стал интересоваться вопросами RAG - без RAG возможности ИИ-перевода в профессиональных целях выглядят совсем грустно.
Здравствуйте. 1. Кодовые базы - совершенно не моя тема, поэтому не подскажу наверняка. Я больше для глоссариев, баз переводов и справочников использую - да и то пока не добился прямо "вау!" результатов (никак не могу поймать оптимальный размер чанка - нужно, чтобы и термины хорошо видел, и большие контексты). Пока склоняюсь к тому, что вести надо две базы - одну для мелких чанков (глоссариев), другую для крупных (справочных материалов). 2. В любом случае - надо тестировать, т.к. понятие "очень большая база" - очень растяжимое, для кого-то это терабайт, для кого-то 10 гигабайт. Я бы зашел на сайт llama, там много разных эмбеддинговых моделей, в т.ч. и для кодинга (где-то на форумах видел, что хвалили QWEN, но какую точно модель - не запомнил); развернул бы несколько вариантов и потестил бы. По крайней мере я так "свою" модель для переводов искал (как выяснилось, сильно раскрученные с моей спецификой справляются плохо). 3. Я больше ориентируюсь на облачное использование RAG, локальные варианты мой компьютер не тянет. Соответственно, это еще одно ограничение, по которому я не смогу дать хороший ответ.
У меня нет задачи их читать. У меня задача иметь корпус актуальных текстов и формулировок на заданную тему. Чтения мне на работе хватает, пока перевожу и редачу тексты :)
Публичные LLM, насколько я знаю, денег хотят.. Где же я их столько возьму? Хеши не храню. Они на лету считаются, скрипт принимает решение и видимо после обработки про хеши забывает. Что не так с хешем из 1000 знаков? Коллизий при 16 тыс. файлов я точно не ожидаю при таком размере хешируемого текста.
Ключевые слова, которые я отобрал для сортировки, прямо в коде гвоздями и прибиты, зачем мудрить, они более или менее статичны.
По поводу доступа напишите в личку, здесь я точно доступы вешать не буду :)
Спасибо. Положил в бэклог. Если кто-то из практикантов-переводчиков заинтересуется, сделаем перевод - вывесим здесь. Практикантов мне присылают регулярно, так что очень даже может получиться (правда, переводчики математику не жалуют :))).
Спасибо за критику, учту. Однако оговорюсь, что я именно поэтому метки и поставил: уровень - "легкий", тип публикации - "Туториал". Туториалов лучше иметь побольше разных, никогда не знаешь, кому какое объяснение лучше зайдет. Мне лично зашло это.
Про то, как вычислять Q, K и V - мне тоже интересно, буду копать в этом направлении, если найду что-то интересное, закину.
Спасибо, покопаюсь в этом направлении, мне туда тоже интересно идти. Для меня пока и эта инфа была новой, поэтому решил поделиться, вдруг кому-то еще такие объяснения как-то помогут разобраться.
Я в свое время утомился искать, и начал сам таких "выращивать". Занимаюсь наставничеством переводчиков с 2011 года, практика показала, что этот подход дает более предсказуемые результаты, чем если искать готовых спецов на рынке.
В целом переводчик с хорошими скиллами — это в первую очередь переводчик с хорошими подходами, а не с готовыми знаниями (все равно все на свете знать не будешь) — нужно приучать его/себя копать матчасть до тех пор, пока не исчезнет «магия» :).
Как показал опыт, начинающие переводчики вполне способны выдавать приличный результат, если им показать, как это делать и докуда копать + если приучить их не стесняться задавать вопросы, даже тривиальные (подобно тому, как это делают техписы-аналитики).
Книга? Или глава про булевы типы?
Книга в договоре указана как "100 ошибок PostgreSQL и как их избежать (PostgreSQL Mistakes and How to Avoid Them), автор Джимми Ангелакос (Jimmy Angelakos) ", это рабочее название, с каким названием дойдет до печати - не знаю, это от переводчика не зависит.
Спасибо за обзор, хотел сам что-то подобное написать. Скоро, думаю, книга появится на русском языке, на этой неделе заканчиваю ее перевод (по заказу издательства «Питер»).
Помимо описанных типов данных, автор в конце книги еще довольно развернуто пишет про "глюки", которые могут вызвать разные реализации булевых типов в известных СУБД при миграции в Postgres.
Если позволите, на правах коллеги, ИТ-переводчика, который не чужд автоматизации и ИИ, немного выскажусь:
1. Про объем переводов
Профессиональный перевод через ИИ (я про SOTA-модели с хорошими бенчмарками, типа DeepSeek) - это пока вообще не про объем. Это скорее про некоторое ускорение рутины. Это по прежнему довольно кропотливая работа, только если раньше я переводил по предложениям, сейчас по абзацам. Чуть больше 2 абзацев текста в модель закинешь, будь готов к тому, что она начнет жертвовать деталями, в т.ч. и смысловыми. Тут конечно, многое зависит от длины самих предложений - на длинных предложениях модель захлебывается быстро (даже с хорошо отдебаженным промтом на длинных предложениях технические нюансы плывут — то предлог не тот, то термин близкий, но не тот, то причина со следствием перепутаны или изложены двусмысленно). Поэтому о том, чтобы грузить главами/книгами или даже цельными страницами, и ожидать, что будет коммерческий перевод, пока речь не идет.
2. Про терминологию
Частично проблема терминологии решается промт-инжинирингом и RAG. Но там тоже нужно учитывать, что классические глоссарии, в которых термины отсортированы по алфавиту, не подходят. Я пока пришел к решению, что термины нужно раскладывать группами вокруг однословных терминов, тогда эмбеддинги у таких групп точнее соответствуют запросу и термины подтягиваются. Как нибудь напишу статью про этот подход, но вкратце изложил здесь - https://t.me/alliancepro/3484, здесь - https://t.me/alliancepro/3428, и здесь - https://t.me/alliancepro/3389.
3. Адекватность исходного текста.
Тут я скажу слово в защиту ИИ - при хорошо подобранных материалах для RAG модель неплохо страхует. Как минимум она заставляет обратить внимание на вещи, которые при прочих равных я бы упустил или истолковал бы иначе.
А вот от подхода - сделать машинный перевод всего текста без корректировок, а потом только корректировать - я отказался. Причина простая - текст выходит настолько грязный, что приходится его местами переписывать заново. Одна из причин, модель смотрит историю своей выдачи - и даже если там полная фигня, она все равно считает ее приемлемой (пользователь же не возмутился?), и делает еще больше допусков на ошибки (на рекуррентных моделях это кажется, называлось в духе взрыв/затухание градиента, но могу ошибаться).
Поэтому сейчас подход (как я уже упомянул выше) такой: закинул 2 абзаца, получил выдачу, почитал - если не шлак - закидываю в черновик, для последующей вычитки. Если шлак - корректирую промпт или прямо в черновике. Как правило, при таком подходе корректировки в итоге выходят минимальными. В общем, тут напрашивается аналогия со студентом, сессией и гвоздями (https://pikabu.ru/story/s_univera_zapomnil_anekdot_9750706)
4. Проблема эксперта
Она была вообще всегда, что с кожаными переводчиками, что с цифровыми. К ИИ тут претензий нет, тем более, что он даже подстраховывает.
В частности, я иногда преподаю ИТ-перевод в вузе, и до ИИ, то что студенты мне сдавали в своих работах, без слез читать было невозможно. Сейчас переводы у них стали поприличнее - сказывается помощь ChatGPT :).
Добавлю лишь, то что "эксперт" тоже не гарантия. Я когда переводил PCI DSS, в аннотации к стандарту было написано, что его проверяло более 600 экспертов по всему миру. Тем не менее, мы с аудиторами-консультантами после этих 600 экспертов еще пару добрых десятков смысловых косяков выловили, в т.ч. со взаимоисключающим смыслом. Я даже на одной ИБэшной конфе на эту тему доклад делал :).
5. Конфиденциальность.
Я вообще скептически к ней отношусь, поскольку занести деньги - если уж на то пошло, могут и к почтовому провайдеру отправителя или получателя (мы же не голубиной почтой пользуемся, верно?). Да и сервисами мы часто пользуемся со смартфона - тоже весьма уязвимая штука. Так что, на мой взгляд, ИИ тут особо картину не меняют - просто одной дырой больше.
==
В остальном со статьей согласен. ИИ безусловно помогает, но намного меньше, чем кажется многим заказчикам. Пока терпим, улыбаемся и пашем - хороший перевод как был рутинным, так пока им и остается. Терпимо хреновенький да, стало делать в разы проще.
Боюсь, не смогу ответить на этот вопрос, т.к. никоим образом не в курсе планов издательства — мое дело маленькое. Могу лишь предположить, что ИТ-литературу оно должно выпускать оперативно, т.к. иначе она быстро протухает.
Рискну предположить, что ближе к концу года, наверное, выпустят.
Здравствуйте. Вы столько много умных слов написали, я их не знаю. Наверное этос связано с тем, что домашними решениями не пользуюсь и не рассматриваю - возможности компа не позволяют (я же переводчик, а не ML-инженер), пользуюсь облачными провайдерами. Использую text-embedding-3-large + реранкинг от BAAI
Спасибо, Мария, за развернутое описание процесса и за то, что упомянули нашу скромную команду как локализаторов и переводчиков. Если позволите, немного дополню.
Отмечу, что с момента нашего разговора утекло много воды, и мы улучшили наш подход к работе с терминами, чтобы подготовленный словарь можно было использовать в системах RAG (ИИ).
Основная проблема в том, что когда слова расположены по алфавиту в глоссарии, RAG их плохо видит - для него суммирующий эмбеддинг чанка из куска глоссария выглядит как средняя температура по больнице, поскольку между соседними словами нет ничего общего.
В итоге я доработал Python-скрипт, чтобы он мне выдавал термины группами, вокруг гнездового термина. Например, если у меня в есть гнездовой термин team, то вокруг него можно подтянуть/сгруппировать термины sales team, support team, team member и т.д.
Разумеется, для каждого термина подтягивается группа предложений, из которых он был взят. Это нужно для дальнейшей обработки термина через LLM - когда ей на вход подают термин и группу предложений, и просят найти оптимальный перевод конкретного термина, модель в целом справляется неплохо (у вас упомянут Гигачат, но я так и не понял из вашей методологии, просили ли вы просто его дать определения, или просили дать определения с учетом ваших контекстов).
В итоге мы получаем глоссарий, который можно прицеплять в базу знаний модели и пользоваться им. Алфавитный глоссарий в LLM работает явно хуже.
На здоровье :). Может как-нибудь и доберусь до курса, но пока еще копаю. На Arxiv много интересных публикаций, скоро опубликую новую - о том, как тестировать связку RAG+LLM (в технических переводах это важный момент).
Благодарю за комментарий. У меня не было возможности сравнить то, как было раньше с тем, как есть сейчас, но могу уверенно сказать, что то, как есть сейчас, меня категорически не устраивает — модели постоянно зажевывают середину. Собственно, это и стало одной из причин, по которой я стал интересоваться вопросами RAG - без RAG возможности ИИ-перевода в профессиональных целях выглядят совсем грустно.
Здравствуйте.
1. Кодовые базы - совершенно не моя тема, поэтому не подскажу наверняка. Я больше для глоссариев, баз переводов и справочников использую - да и то пока не добился прямо "вау!" результатов (никак не могу поймать оптимальный размер чанка - нужно, чтобы и термины хорошо видел, и большие контексты). Пока склоняюсь к тому, что вести надо две базы - одну для мелких чанков (глоссариев), другую для крупных (справочных материалов).
2. В любом случае - надо тестировать, т.к. понятие "очень большая база" - очень растяжимое, для кого-то это терабайт, для кого-то 10 гигабайт. Я бы зашел на сайт llama, там много разных эмбеддинговых моделей, в т.ч. и для кодинга (где-то на форумах видел, что хвалили QWEN, но какую точно модель - не запомнил); развернул бы несколько вариантов и потестил бы. По крайней мере я так "свою" модель для переводов искал (как выяснилось, сильно раскрученные с моей спецификой справляются плохо).
3. Я больше ориентируюсь на облачное использование RAG, локальные варианты мой компьютер не тянет. Соответственно, это еще одно ограничение, по которому я не смогу дать хороший ответ.
У меня нет задачи их читать. У меня задача иметь корпус актуальных текстов и формулировок на заданную тему. Чтения мне на работе хватает, пока перевожу и редачу тексты :)
Публичные LLM, насколько я знаю, денег хотят.. Где же я их столько возьму? Хеши не храню. Они на лету считаются, скрипт принимает решение и видимо после обработки про хеши забывает.
Что не так с хешем из 1000 знаков? Коллизий при 16 тыс. файлов я точно не ожидаю при таком размере хешируемого текста.
Ключевые слова, которые я отобрал для сортировки, прямо в коде гвоздями и прибиты, зачем мудрить, они более или менее статичны.
По поводу доступа напишите в личку, здесь я точно доступы вешать не буду :)
вы мне или @avshkol?
Премного! Буду разбираться :)
Она непубличная. Напишите в личку.
Спасибо, гляну.
Спасибо. Положил в бэклог. Если кто-то из практикантов-переводчиков заинтересуется, сделаем перевод - вывесим здесь.
Практикантов мне присылают регулярно, так что очень даже может получиться (правда, переводчики математику не жалуют :))).
Спасибо за критику, учту. Однако оговорюсь, что я именно поэтому метки и поставил: уровень - "легкий", тип публикации - "Туториал". Туториалов лучше иметь побольше разных, никогда не знаешь, кому какое объяснение лучше зайдет. Мне лично зашло это.
Про то, как вычислять Q, K и V - мне тоже интересно, буду копать в этом направлении, если найду что-то интересное, закину.
Спасибо, покопаюсь в этом направлении, мне туда тоже интересно идти. Для меня пока и эта инфа была новой, поэтому решил поделиться, вдруг кому-то еще такие объяснения как-то помогут разобраться.
Возможно, у кого-то получается так, но у меня лично получается быстрее набрать вручную, чем голосом - правок очень много от голоса приходится делать.
Я в свое время утомился искать, и начал сам таких "выращивать". Занимаюсь наставничеством переводчиков с 2011 года, практика показала, что этот подход дает более предсказуемые результаты, чем если искать готовых спецов на рынке.
В целом переводчик с хорошими скиллами — это в первую очередь переводчик с хорошими подходами, а не с готовыми знаниями (все равно все на свете знать не будешь) — нужно приучать его/себя копать матчасть до тех пор, пока не исчезнет «магия» :).
Как показал опыт, начинающие переводчики вполне способны выдавать приличный результат, если им показать, как это делать и докуда копать + если приучить их не стесняться задавать вопросы, даже тривиальные (подобно тому, как это делают техписы-аналитики).