За исследователей не скажу, но лично я регулярно сталкиваюсь с тем, что модель не задает вопросов, если ее специально об этом не просить. Поэтому я когда пишу ТЗ для модели на написание кода, обязательно заканчиваю фразой "Если у тебя есть вопросы по заданию, спрашивай, и ТОЛЬКО ПОСЛЕ МОЕГО ОТВЕТА выводи полный код".
Модель задает вопросы, но не факт, что она правильно их поняла (или не факт, что я правильно ей донес), и она снова, зараза, будет молчать.. Поэтому когда я отправляю ей ответы, я повторяю ту же самую фразу. И так до тех пор, пока у нее не кончатся вопросы и ТЗ не будет для нее исчерпывающим.
Правда надо контекстное окно бесконечное иметь для таких бесед, поэтому в агенте я просто возвращаюсь к своему первому сообщению, редактирую его... в общем, это уже другая история, но модели без разрешения вопросы не задают, могут лишь во время включенного вывода ризонинга формулировать эти вопросы, как бы внутренне их обсуждая.
Это не мои тесты. Я переводчик исследования, а не его автор. Но описанные здесь проблемы и подходы мне знакомы - либо сталкивался, либо пользуюсь.
Это частные случаи, с которыми исследователи работали почти год назад. Исследование было опубликовано в феврале этого года, следовательно, исследовать они начали задолго до этого, думаю, смело можно считать, что речь идет о работе как минимум в течение второй половины 2024 года.
Опровержение этих частных случаев ничего не дает, модели быстро учатся. Те ошибки, которые я у них обнаруживал еще 3 месяца назад, уже не повторяются сейчас. Из свежего: я проверял работу переводчика, где он в первом предложении говорит про "B-лимфоциты", а в следующем — про "эти клетки". Ризонинговая модель посчитала, что переводчик ошибся, т.к. речь идет не о "клетках", а о "B-лимфоцитах". Как-то видимо, не смогла она сопоставить, что B-лимфоциты - это разновидность клеток. Не удивлюсь, если я через пару дней повторю тот же самый запрос в модель, и она уже вполне уверенно подтвердит, что оказывается B-лимфоциты — это клетки.
В целом эта статья не про частные косяки, а в целом про проблемы доверия ризонинговым моделям и о том, как построить с ними работу так, чтобы им можно было СРАЗУ больше доверять, а не ЧЕРЕЗ условных 2 дня/месяца/года.
Книга в договоре указана как "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 тыс. файлов я точно не ожидаю при таком размере хешируемого текста.
Ключевые слова, которые я отобрал для сортировки, прямо в коде гвоздями и прибиты, зачем мудрить, они более или менее статичны.
По поводу доступа напишите в личку, здесь я точно доступы вешать не буду :)
Автор несколько витиевато излагает эту идею, я перевел так, как его понял (по другому у меня слова в нормальный смысл не складывались).
Если вдруг вы видите ошибку интерпретации его слов, дайте знать, плиз.
Пардон, лопухнулся, не отследил. :(
Да, я опоздал с ответом. Всё верно, я не автор, я переводчик.
За исследователей не скажу, но лично я регулярно сталкиваюсь с тем, что модель не задает вопросов, если ее специально об этом не просить. Поэтому я когда пишу ТЗ для модели на написание кода, обязательно заканчиваю фразой "Если у тебя есть вопросы по заданию, спрашивай, и ТОЛЬКО ПОСЛЕ МОЕГО ОТВЕТА выводи полный код".
Модель задает вопросы, но не факт, что она правильно их поняла (или не факт, что я правильно ей донес), и она снова, зараза, будет молчать.. Поэтому когда я отправляю ей ответы, я повторяю ту же самую фразу. И так до тех пор, пока у нее не кончатся вопросы и ТЗ не будет для нее исчерпывающим.
Правда надо контекстное окно бесконечное иметь для таких бесед, поэтому в агенте я просто возвращаюсь к своему первому сообщению, редактирую его... в общем, это уже другая история, но модели без разрешения вопросы не задают, могут лишь во время включенного вывода ризонинга формулировать эти вопросы, как бы внутренне их обсуждая.
Мысли простые.
Это не мои тесты. Я переводчик исследования, а не его автор. Но описанные здесь проблемы и подходы мне знакомы - либо сталкивался, либо пользуюсь.
Это частные случаи, с которыми исследователи работали почти год назад. Исследование было опубликовано в феврале этого года, следовательно, исследовать они начали задолго до этого, думаю, смело можно считать, что речь идет о работе как минимум в течение второй половины 2024 года.
Опровержение этих частных случаев ничего не дает, модели быстро учатся. Те ошибки, которые я у них обнаруживал еще 3 месяца назад, уже не повторяются сейчас. Из свежего: я проверял работу переводчика, где он в первом предложении говорит про "B-лимфоциты", а в следующем — про "эти клетки". Ризонинговая модель посчитала, что переводчик ошибся, т.к. речь идет не о "клетках", а о "B-лимфоцитах". Как-то видимо, не смогла она сопоставить, что B-лимфоциты - это разновидность клеток. Не удивлюсь, если я через пару дней повторю тот же самый запрос в модель, и она уже вполне уверенно подтвердит, что оказывается B-лимфоциты — это клетки.
В целом эта статья не про частные косяки, а в целом про проблемы доверия ризонинговым моделям и о том, как построить с ними работу так, чтобы им можно было СРАЗУ больше доверять, а не ЧЕРЕЗ условных 2 дня/месяца/года.
Книга? Или глава про булевы типы?
Книга в договоре указана как "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?
Премного! Буду разбираться :)
Она непубличная. Напишите в личку.
Спасибо, гляну.