Comments 18
>Модели проще вас понять на английском. Если недостаточно хорошо владеете языком - переводите с Google Translate, это может существенно повысить качество ответов
Есть исследование гугла с ровно обратными выводами - общаться лучше на том языке, который именно вы лучше знаете, автоперевод на другой язык ухудшает результат. А начиная с GPT-4o даже токенизацию улучшили для русского в 1.7 раз по сравнению с 4.0 - теперь контекст модели расходуется эффективнее.
Попозже посмотр статью и поищу примеры с запросами и вам отвечу, то что я видел - логические задачи, (типа в комнате было три стола, пять человек и шесть яблок, три яблока забрали, сколько осталось человек ) Вот такие штуки на английском пока решает лучше. Токенизатор вы правы эффективнее, но в 1.7 раз относительно предыдущего меньше символов уходит на русский язык, но эозначает ли это что он ффективнее английского?
Влияние токенизатора на результативность ответов мне неизвестно, упомянул скорее как дополнительную причину отказа от автоперевода запросов.
Частные задачи могут показывать разные результаты, но в рамках статьи исследовали 108 языковых пар и 6 больших датасетов с тестами ответа на выбор / свободным ответом и статистически результаты лучше у запросов на языке носителя. И чем больше и лучше модели - тем меньше смысла в переводе на английский (в статье модель GPT-3.5 работает чуть лучше при автопереводе, но уже для GPT-4.0-32k это не актуально). Статья "старая", 4o тогда еще не было
Смотрите, в вашей статье речь идет про PALM2 это предшественник Gemini и сравнивается два подхода:
· Перевод через API Google Translate без последующей корректировки подается в LLM
· прямой ввод в LLM на языке оригинала
Потом еще обратный перевод где-то тестируется.
Google translate – хорош, но, конечно, не идеален, он может просто некорректно перевести некоторые вещи. Я кусочек вашей статьи им сейчас перевел, он слово «accounting» в контексте подсчета результатов перевел как «бухгалтерия». Так, конечно, можно запороть любой запрос.
Я согласен, что некорректно выразился. Правильнее сказать пользуйтесь Google Translate, но пишите на английском, в смысле переведите Google Translate и доведите до ума. Если пользователь может только Ctrl-C - Ctrl-V (не можете понять, что написано на английском), т.е. довести до корректного текста на английском нет возможности, то похоже стоит писать на родном языке. Но давайте обозначим, что это исследование не утверждает, что грамотный запрос на английском работает хуже или хотя бы так же как такой же запрос на родном языке. Тут мы упираемся в вопрос - как измерить такие вещи, это действительно нетривиально. Я погуглю, если найду подходящие исследования - напишу попозже
Разумеется, если человек является носителем английского языка и может корректно написать запрос сам (или довести до ума результат автоперевода) - тут результат будет скорее всего немного лучше. Вопрос насколько лучше - кажется, что начиная с версии GPT-4 модели довольно хорошо научились в мультиязычность и генерализацию знаний, чтобы заметно не ухудшать результаты на языках, отличных от английского.
Тут можно привести простой контрпример - стихи и рифмы хорошо даются на английском и посредственно на русском, но GPT-4o и Claude Opus все же показывают лучшие результаты, чем младшие модели
Поговорил с коллегами, похоже что это исследование имеет отношение только к PALM 2 - эти модели специально были обучены на мультиязычность т.е. они тренировалась на сбалансированном мультиязычном наборе данных и от этого и давали такие результаты. Все логично. Похоже даже к другим гугловским моделям типа Gemini это уже не применимо т.к. они тренировались гораздо больше на англоязычных данных, чем на других языках и перекос там значительно больше. Так что вероятно для многих моделей даже полностью автоматический перевод в среднем все еще может быть эффективнее, но лучше конечно корректно промпт перевести
Для многих - возможно, тот же Gemini не очень хорошо освоил русский. Но ведь в статье упоминаются GPT-3.5 и GPT-4, общие выводы относительно PALM-2 коррелируют и с GPT-4.
К сожалению, не располагаю статистикой по распределению языков по объему в исходных данных при обучении в OpenAI, но сомневаюсь что там значительный перекос в сторону только английского, иначе LLM просто не освоила бы на достаточном уровне другие языки. Кажется что для следующих поколений LLM необходимость использования английского еще больше должна снизиться.
Там как-то немного странно написано в приложении в конце, что в среднем по больнице у GPT4 выигрывает перевод, но в некоторых языках директ-промптинг. Вот нагуглил большое исследование от апреля 24 https://arxiv.org/pdf/2311.07463 - насколько я понял в целом выводы такие, что нам нужны данные для тестирования, но английский все же похоже выигрывает
Честно говоря, самые современные модели типа command-r-plus довольно не плохо справляются с задачами. При этом, я не замечал эффекта от запроса вести себя как крутой программист и т.д.
Зато сильно повысит качество если модели сообщить вводные, которые, возможно для вас очевидны, а у модели есть вариативность их выбора и она может исходить из других вариантов. Например, если вам нужен скрипт переключения провайдеров и вы используете shorewall, показать модели как у вас устроены таблицы маршрутизации, как лучше включить основной провайдер, как вы вручную включаете дополнительный и как их тестировать, нужно ли вести логи и что и в каких случаях надо в них записывать, а что не надо логировать и т.д. а затем привести релевантные участки конфигурационных файлов shorewall, если это необходимо учитывать. Чем подробнее и непротиворечивее вы опишете что вам надо, тем качественнее будет код. Да, в самом начале напишите на каком языке вам нужен скрипт.
Ещё полезно написать о стиле программирования, например: для bash, пиши коротко и лаконично, bash-like style, используй pipe и подстановки переменных типа ${val/subst/newsubst}. Такое замечание сильно повлияет на результат. У меня это сократило количество строк раз в 5, т.е. скрипт изпроствни кода превратился в несколько компактных строк.
Говоря о написании, например, делового письма, "вместо веди себя как", мне показалось полезнее прямо наложить ряд ограничений и дать ряд требований к результату, например, в ситуации когда ваша бухгалтерия накосячила и, к примеру не выставляли счета из-за чего у контр-агента возникла задолженность: напиши деловое письмо..., не отрицая нашей вины, вежливо, но твердо, потребуй оплаты задолженности до конца года; имей в виду, что это очень важный контр-агент, важно не поссориться.
Кстати чатжипити особенно хорошо может управлять эмоциональной составляющей текста, например, можно попросить убрать памсивную агрессию из письма вашего колоеги или наоборот, добавить пассивную агрессию в ваше письмо, можно сделать текст более вежливым, более деловым, добавить иронию и т.д.
Т.е. я пишу что мне нужно получить в итоге, а не как модель должна себя вести и другие подобные не косвеннве приёмы. Мне показалось, что прямой подход работает лучше.
Согласен, у меня похожие ощущения что с последним поколением моделей "ты великий программист" это все уже не особо принципиально, а примеры и точные указания работают (собственно как и с людьми). Некоторые вещи становятся заметны при борьбе с галлюцинациями, т.е. если вам надо чтобы 100 раз из 100 запрос отработал корректно. Я тестирую и по мере получения ошибок добавляю всякие сначала логичные (типа не ошибайся так, вот еще один корректный пример с таким видом данных ), а потом уже и "шаманские" практики. Из шаманских - повторить запрос очень эффективна.
А Сommand-r-plus - вы используете как самую лучшую из бесплатных? На Lmsys - Llama-3-70b-Instruct по идее на пару позиций выше в лидерборде.
Да, command-r-plus как самую лучшую для написания скриптов в bash, но и другие задачи решает не плохо. Мне даже показалось что иногда лучше chat-gpt, например, когда просишь у модели нереалистичную чушь, она вместо глюцинирования так и пишет, что так не получится - я удивился, когда обнаружил, но не всегда так срабатывает. Просто заметно что модель сопротивляется таким попыткам "продавить" её.
> Из шаманских - повторить запрос очень эффективна.
Ещё лучше, повторить запрос на английском языке, логично упорядочив информацию. Во первых, почти бесплатно получаем перевод на английский, опираясь на который, возможно, модель получше решит задачу, во вторых, модель структурирует задачу как ей удобно, а вы заодно проконтролируете ход её "мыслей" и можно что-то подправить, если английский вариант вас не устроит и подложить, заменив её собственный вывод.
Совсем недавно вышла codestral:22B она в неквантинизированном виде (fp16) убирается в две мои RTX3090 и пишет со скоростью 16 токенов в секунду. У меня появились новые приёмы: напиши скрипт 3 раза уникальным образом, оцени каждый из вариантов указав сильные и слабые стороны, затем напиши суперскрипт, который будет обладать сильными сторонами всех трех и которого не затронут найденные недостатки. Забавно наблюдать за ходом такой работы. Она реально так всё и делает, да ещё довольно быстро.
Правда косячит примерно как человек, например может грепнуть статус виртуальных машин не задумываясь что будет если встретится машина с именем "stopped" или "running". Но если спросить её об этом, не указать на ошибку, а просто спросить, обнаруживает проблему и исправляет. Предпочитает исправляя выдавать исправленный кусок кода - это удобно, но если попросить написать скрипт целиком, выполняет - это тоже удобно.
Удивительно то, что codestral:22B очень хорошо понимает русский, правда, если специально не попросить, часто отвечает на английском, тоже самое и с комментариями к коду. Заметно, что хорошо понимает когда вы пишите "датасет" вместо dataset или что-то вроде "забекапить", а "суперскрипт" у неё даже какую-то едва уловимую иронию вызывает, как мне показалось.
Попробовал сегодня Сodestral:22B с пормптом из поста, результат хуже чем у GPT4o и "Im-also-a-good-gpt2-chatbot". Код написала правдоподобный, но половину требований не выполнила, сортировку не сделала, данные не в те колонки внесла. Ну, т.е. на самом деле вполне неплохо для свободной модели, но есть лучше)
Заметил интересную особенность: Если в самом начале кода вы увидите, что Сodestral:22B нарушила какое-то условие задания или проигнорировала требование, то дальше будет косяк на косяке. Я не дожидаюсь и сразу делаю перегенерацию и если вдруг видно что модель неожиданно учла что-то малозаметное, скорее всего, весь код будет хорошим, но возможные мелкие ошибки, их приходится вылавливать вручную.
Я ожидал, что ошибки будут встречаться равновероятно, но, на самом деле, это не так. Заметно большое различие в качестве решений. Бывает, неудачное начало приводит к тупейшим ошибкам, а бывает, если в начале проскочили абзац без ошибок, дальше идёт всё как по маслу.
Благо, модель работает быстро и можно сразу сделать 5 генераций. Я с 4о не сравнивал, т.к. не ожидаю что она её превзойдёт, мне просто нужен локальный инструмент, но сравнивал с command-r-plus 104B q8_0 - она огромная, а код делает хуже. кроме того, даже в q8 заметно снижение качества, например, модель иногда код не оформляет markdown-разметкой или отступы плывут, по моему это признак того, что нужна меньшая или отсутствующая квантинизация. в fp16 такого нет, но приходится запускать на процессора. У меня 24-яденый AMD EPYC, очень медленно. Там перегенерация не самая удачная идея.
В целом, для всех моделей полезно сначала добиться создания некого упрощенного, но концептуально правильного шаблона, а потом попросить его доработать под более сложные требования и так итеративно, ошибок меньше возникает. С моделью Сodestral:22B я предпочитаю чаще перегенерации делать, заодно выбираю понравившиеся мне приемы, которых в bash она знает много.
Лучшие ответы получаются, если коммуницировать с моделью, как с живым разумным существом.
Источник: личный опыт
Посоветуйте, пожалуйста, в каком формате лучше подавать таблицу в промпт для больших языковых моделей? Пробовал разные варианты, включая Markdown и дублирование информации о столбце/строке для каждой ячейки, но бывают ошибки при вопросах с конкретными условиями, где нужно достать значение из определённой ячейки.
Может быть есть какие-то лайфхаки?
Вообще говоря в любом, и csv, и excel хоть картинкой. Смотря какие задачи вы решаете и в какой модели. Если прямо в промпт запихнуть таблицу в тысячи или даже несколько сотен строчек - могут начать ошибаться, если десятки строчек - на моей практике все хорошо считает, сортирует, ищет и т.д.. Большие таблицы я бы аттачментом кидал. Часто для подсчетов LLM пишет python код, в OpenAI это раньше называлось Advanced Data Analysis. Сейчас кажется модель сама как-то определяет тип задачи и входит в такой режим. Если отказывается считать - как вариант дать пример файла с данными - 10-20 строчек, попросить модель написать код для вашей задачи, а запустить самостоятельно уже локально у себя, так будет больше уверенности в результате, если вы понимаете python. В Gemini кажется можно и без подписки файлы подгружать.
Шпаргалка для создания идеального промпта LLM