На здоровье :). Может как-нибудь и доберусь до курса, но пока еще копаю. На Arxiv много интересных публикаций, скоро опубликую новую - о том, как тестировать связку RAG+LLM (в технических переводах это важный момент).
Благодарю за комментарий. У меня не было возможности сравнить то, как было раньше с тем, как есть сейчас, но могу уверенно сказать, что то, как есть сейчас, меня категорически не устраивает — модели постоянно зажевывают середину. Собственно, это и стало одной из причин, по которой я стал интересоваться вопросами RAG - без RAG возможности ИИ-перевода в профессиональных целях выглядят совсем грустно.
Здравствуйте. 1. Кодовые базы - совершенно не моя тема, поэтому не подскажу наверняка. Я больше для глоссариев, баз переводов и справочников использую - да и то пока не добился прямо "вау!" результатов (никак не могу поймать оптимальный размер чанка - нужно, чтобы и термины хорошо видел, и большие контексты). Пока склоняюсь к тому, что вести надо две базы - одну для мелких чанков (глоссариев), другую для крупных (справочных материалов). 2. В любом случае - надо тестировать, т.к. понятие "очень большая база" - очень растяжимое, для кого-то это терабайт, для кого-то 10 гигабайт. Я бы зашел на сайт llama, там много разных эмбеддинговых моделей, в т.ч. и для кодинга (где-то на форумах видел, что хвалили QWEN, но какую точно модель - не запомнил); развернул бы несколько вариантов и потестил бы. По крайней мере я так "свою" модель для переводов искал (как выяснилось, сильно раскрученные с моей спецификой справляются плохо). 3. Я больше ориентируюсь на облачное использование RAG, локальные варианты мой компьютер не тянет. Соответственно, это еще одно ограничение, по которому я не смогу дать хороший ответ.
У меня нет задачи их читать. У меня задача иметь корпус актуальных текстов и формулировок на заданную тему. Чтения мне на работе хватает, пока перевожу и редачу тексты :)
Публичные LLM, насколько я знаю, денег хотят.. Где же я их столько возьму? Хеши не храню. Они на лету считаются, скрипт принимает решение и видимо после обработки про хеши забывает. Что не так с хешем из 1000 знаков? Коллизий при 16 тыс. файлов я точно не ожидаю при таком размере хешируемого текста.
Ключевые слова, которые я отобрал для сортировки, прямо в коде гвоздями и прибиты, зачем мудрить, они более или менее статичны.
По поводу доступа напишите в личку, здесь я точно доступы вешать не буду :)
Спасибо. Положил в бэклог. Если кто-то из практикантов-переводчиков заинтересуется, сделаем перевод - вывесим здесь. Практикантов мне присылают регулярно, так что очень даже может получиться (правда, переводчики математику не жалуют :))).
Спасибо за критику, учту. Однако оговорюсь, что я именно поэтому метки и поставил: уровень - "легкий", тип публикации - "Туториал". Туториалов лучше иметь побольше разных, никогда не знаешь, кому какое объяснение лучше зайдет. Мне лично зашло это.
Про то, как вычислять Q, K и V - мне тоже интересно, буду копать в этом направлении, если найду что-то интересное, закину.
Спасибо, покопаюсь в этом направлении, мне туда тоже интересно идти. Для меня пока и эта инфа была новой, поэтому решил поделиться, вдруг кому-то еще такие объяснения как-то помогут разобраться.
Я в свое время утомился искать, и начал сам таких "выращивать". Занимаюсь наставничеством переводчиков с 2011 года, практика показала, что этот подход дает более предсказуемые результаты, чем если искать готовых спецов на рынке.
В целом переводчик с хорошими скиллами — это в первую очередь переводчик с хорошими подходами, а не с готовыми знаниями (все равно все на свете знать не будешь) — нужно приучать его/себя копать матчасть до тех пор, пока не исчезнет «магия» :).
Как показал опыт, начинающие переводчики вполне способны выдавать приличный результат, если им показать, как это делать и докуда копать + если приучить их не стесняться задавать вопросы, даже тривиальные (подобно тому, как это делают техписы-аналитики).
Нет, это будет хлопотнее и дороже. Во-первых, переводчику все равно придется вникать в смысл, ибо невозможно донести авторскую идею до читателя, не поняв ее самому. В этом легко убедиться, почитав технические переводы многих «гуманитариев» — многие не ведают, что пишут (верьте мне — я тоже гуманитарий, надеюсь, переучившийся).
Во-вторых, редактору тоже придется вникать в смыслы, так как он должен донести смысл до переводчика.
В итоге получится, что два специалиста делают одну и ту же работу, просто один останавливается на полпути, а другой идет до конца.
Редакторы на проектах, конечно, присутствуют, но они проверяют насколько доходчиво и грамотно донес смысл переводчик до читателя, но первым "под танк" лезет переводчик — читает исходник, углубляет матчасть, вникает в механизмы/технологии/фреймворки, раскладывает инфу в голове по полкам, потом переводит.
Если он просто переводит, он обречен гнать подстрочник, а с этой задачей быстрее и дешевле справляется гуглопереводчик.
Это понятно, но таковы реалии нашей работы — я уже забыл, когда видел хорошо причесанные тексты (причем, «текстового поролона», равно как и «недосказанностей» хватает и у англоязычных, и у русскоязычных авторов). Поэтому пропустить через редактуру — это мы, перевести с канцелярского на человечий — тоже мы :). И собственно говоря, именно это и есть самое сложное в работе переводчика — понять бизнесовый или технический смысл, оптимизировать и структурировать смысловые зерна, отсечь лишнее (дубликаты, очевидности). Именно тут переводчики делают до 80% ошибок.
Сам же перевод готового, разжеванного смысла в английские слова — это уже фигня делов, с ним и гуглопереводчик зачастую неплохо справляется.
Все зависит от контекста. В сплошном тексте такое оформление может быть неудобно. Да и вообще, когда много списков, читать их неудобно. Другое дело, что переосмыслять и распутывать "клубок" мыслей нужно почти всегда — если бы машинный перевод умел это делать, он бы давно нас, переводчиков, с рынка выкинул :).
На здоровье :). Может как-нибудь и доберусь до курса, но пока еще копаю. На Arxiv много интересных публикаций, скоро опубликую новую - о том, как тестировать связку RAG+LLM (в технических переводах это важный момент).
Благодарю за комментарий. У меня не было возможности сравнить то, как было раньше с тем, как есть сейчас, но могу уверенно сказать, что то, как есть сейчас, меня категорически не устраивает — модели постоянно зажевывают середину. Собственно, это и стало одной из причин, по которой я стал интересоваться вопросами RAG - без RAG возможности ИИ-перевода в профессиональных целях выглядят совсем грустно.
Здравствуйте.
1. Кодовые базы - совершенно не моя тема, поэтому не подскажу наверняка. Я больше для глоссариев, баз переводов и справочников использую - да и то пока не добился прямо "вау!" результатов (никак не могу поймать оптимальный размер чанка - нужно, чтобы и термины хорошо видел, и большие контексты). Пока склоняюсь к тому, что вести надо две базы - одну для мелких чанков (глоссариев), другую для крупных (справочных материалов).
2. В любом случае - надо тестировать, т.к. понятие "очень большая база" - очень растяжимое, для кого-то это терабайт, для кого-то 10 гигабайт. Я бы зашел на сайт llama, там много разных эмбеддинговых моделей, в т.ч. и для кодинга (где-то на форумах видел, что хвалили QWEN, но какую точно модель - не запомнил); развернул бы несколько вариантов и потестил бы. По крайней мере я так "свою" модель для переводов искал (как выяснилось, сильно раскрученные с моей спецификой справляются плохо).
3. Я больше ориентируюсь на облачное использование RAG, локальные варианты мой компьютер не тянет. Соответственно, это еще одно ограничение, по которому я не смогу дать хороший ответ.
У меня нет задачи их читать. У меня задача иметь корпус актуальных текстов и формулировок на заданную тему. Чтения мне на работе хватает, пока перевожу и редачу тексты :)
Публичные LLM, насколько я знаю, денег хотят.. Где же я их столько возьму? Хеши не храню. Они на лету считаются, скрипт принимает решение и видимо после обработки про хеши забывает.
Что не так с хешем из 1000 знаков? Коллизий при 16 тыс. файлов я точно не ожидаю при таком размере хешируемого текста.
Ключевые слова, которые я отобрал для сортировки, прямо в коде гвоздями и прибиты, зачем мудрить, они более или менее статичны.
По поводу доступа напишите в личку, здесь я точно доступы вешать не буду :)
вы мне или @avshkol?
Премного! Буду разбираться :)
Она непубличная. Напишите в личку.
Спасибо, гляну.
Спасибо. Положил в бэклог. Если кто-то из практикантов-переводчиков заинтересуется, сделаем перевод - вывесим здесь.
Практикантов мне присылают регулярно, так что очень даже может получиться (правда, переводчики математику не жалуют :))).
Спасибо за критику, учту. Однако оговорюсь, что я именно поэтому метки и поставил: уровень - "легкий", тип публикации - "Туториал". Туториалов лучше иметь побольше разных, никогда не знаешь, кому какое объяснение лучше зайдет. Мне лично зашло это.
Про то, как вычислять Q, K и V - мне тоже интересно, буду копать в этом направлении, если найду что-то интересное, закину.
Спасибо, покопаюсь в этом направлении, мне туда тоже интересно идти. Для меня пока и эта инфа была новой, поэтому решил поделиться, вдруг кому-то еще такие объяснения как-то помогут разобраться.
Возможно, у кого-то получается так, но у меня лично получается быстрее набрать вручную, чем голосом - правок очень много от голоса приходится делать.
Я в свое время утомился искать, и начал сам таких "выращивать". Занимаюсь наставничеством переводчиков с 2011 года, практика показала, что этот подход дает более предсказуемые результаты, чем если искать готовых спецов на рынке.
В целом переводчик с хорошими скиллами — это в первую очередь переводчик с хорошими подходами, а не с готовыми знаниями (все равно все на свете знать не будешь) — нужно приучать его/себя копать матчасть до тех пор, пока не исчезнет «магия» :).
Как показал опыт, начинающие переводчики вполне способны выдавать приличный результат, если им показать, как это делать и докуда копать + если приучить их не стесняться задавать вопросы, даже тривиальные (подобно тому, как это делают техписы-аналитики).
Да нет, вроде... немцы тоже грешат :).
Да, с артиклями вечная беда. Но это уже не про рунглиш, а просто про ненативный английский. Этими ошибками грешат все неносители :).
Нет, это будет хлопотнее и дороже.
Во-первых, переводчику все равно придется вникать в смысл, ибо невозможно донести авторскую идею до читателя, не поняв ее самому. В этом легко убедиться, почитав технические переводы многих «гуманитариев» — многие не ведают, что пишут (верьте мне — я тоже гуманитарий, надеюсь, переучившийся).
Во-вторых, редактору тоже придется вникать в смыслы, так как он должен донести смысл до переводчика.
В итоге получится, что два специалиста делают одну и ту же работу, просто один останавливается на полпути, а другой идет до конца.
Редакторы на проектах, конечно, присутствуют, но они проверяют насколько доходчиво и грамотно донес смысл переводчик до читателя, но первым "под танк" лезет переводчик — читает исходник, углубляет матчасть, вникает в механизмы/технологии/фреймворки, раскладывает инфу в голове по полкам, потом переводит.
Если он просто переводит, он обречен гнать подстрочник, а с этой задачей быстрее и дешевле справляется гуглопереводчик.
Это понятно, но таковы реалии нашей работы — я уже забыл, когда видел хорошо причесанные тексты (причем, «текстового поролона», равно как и «недосказанностей» хватает и у англоязычных, и у русскоязычных авторов).
Поэтому пропустить через редактуру — это мы, перевести с канцелярского на человечий — тоже мы :).
И собственно говоря, именно это и есть самое сложное в работе переводчика — понять бизнесовый или технический смысл, оптимизировать и структурировать смысловые зерна, отсечь лишнее (дубликаты, очевидности). Именно тут переводчики делают до 80% ошибок.
Сам же перевод готового, разжеванного смысла в английские слова — это уже фигня делов, с ним и гуглопереводчик зачастую неплохо справляется.
Все зависит от контекста. В сплошном тексте такое оформление может быть неудобно. Да и вообще, когда много списков, читать их неудобно.
Другое дело, что переосмыслять и распутывать "клубок" мыслей нужно почти всегда — если бы машинный перевод умел это делать, он бы давно нас, переводчиков, с рынка выкинул :).
Тут за меня уже ответили, я лишь дополню ответ цитатой из уважаемого мной Chicago Manual of Style:
5.220 GOOD USAGE VERSUS COMMON USAGE
...
help (to). Omit the to when possible {talking will help resolve the problem}.
...