Обновить

Комментарии 18

Признаком LLM-текста для меня зачастую являются слова, которые редко употребляются в обычном русском языке, а их аналоги часто употребляются в английском: нарратив, рамка, поверхность (API), удерживает (назначение), оптика... Но частое общение с LLM делает эти обороты более привычными. Это как "дорожная карта" (roadmap) - резало слух поначалу, затем попривык. Раньше всегда говорили "план" в таких случаях: "Есть ли у вас дорожная карта, мистер Фикс?"

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

Тут ещё и "про" )). У меня к нему личная антипатия, не могу изжить.

"Про" - это моё, "кожаное" :) Когда-то, давным давно, я, скорее всего, написал бы "о". В школе - так точно. Но... вот такие паттерны у меня сложились.

Любая конструкция, которая задаёт отношение между объектами — это инструмент мышления. Запрещая её, вы убираете не украшение, а связь.

Можно ещё выполнить постобработку текста - запросить ту же LLM убрать все эти шаблоны после генерации.

А насколько влияет, и в какую сторону, использование инструкций составленных на основе COSTAR/COSTAR-A prompting framework перед основным запросом?

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

COSTAR обычно и формирует основной запрос. O - и есть задача. В целом влияет положительно, в первую очередь, за счёт структуры промпта - вы точно не пропустите важные для ЛЛМ элементы. А остальное будет зависеть от наполнения. Если вы в T - тон, поставите требование сухого научного языка и одновременно, чтобы было понятно школьникам, модель поплывёт.

COSTAR обычно и формирует основной запрос. O - и есть задача.

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

Эффективнее, чем писать руками. Другой вопрос, что ллм не знает, чего не знает.

Я бы перед формированием базового промпта перечислил все требования к редактору, попросил бы ллм его раскритиковать и добавить свои пункты. И потом на основании этого попросил сформировать ролевой промпт.

А дальше итерационные исправления.в случае необходимости.

Немножко грустно для русского языка, когда в него впихивают иноязычные аббревиатуры, которым в нём самом наличествуют вполне общеупотребимые эквиваленты.

Автор 13 раз написал LLM, когда вполне мог бы написать БЯМ - "большая языковая модель".

БЯМ это более академично... СБЕР, ГОСТы, постановления правительства. В статье на Хабре, на фоне тысяч англоязычных терминов это как-то неуместно. В этом случае я подстраиваюсь под площадку..

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

PS "тысяч англоязычных терминов" - это вы как-то совсем уж черезчур загнули: среднестатистический программист с Хабра вряд ли и русских-то слов столько знает (памятуя о его чрезмерном увлечении англицизмами), а чего уж говорить про английские...

Крайне сомневаюсь в ваших предположениях.

Во-первых, позволю себе процитировать первый же, самый залайканый комментарий к “профильному обсуждению”:

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

Во-вторых, вы часто видите, чтобы кто-нибудь брал какой-нибудь общеизвестный термин, допустим, API, и превращал его в какое-нибудь ИПП? Или жаловался на то, что начальник поставил задачу “за день подготовить МЖП”? Может быть кому-то когда-то не хватало “процессорных линий шины МПК(б)?” В нормативных документах такое, конечно, встречается, если есть соответствующее нормативное требование к документу, и это обычно юристы пишут, а не технические специалисты, и там ВСЕГДА в конце документа должна быть расшифровка, что именно и как сокращается, потому что без этой расшифровки вообще ничего никому не понятно.

В-третьих, чем айтишники и нейронщики хуже коллег из других отраслей? Лётчики в тренировках и в кабине строго пользуются тем языком, который подразумевается изготовителем самолёта. В случае иномарок, это английский язык. И никто не ломится в кабину экипажа с томиком Ожегова в славянофильском угаре, потому что это правило написано кровью убитых пассажиров. То есть говорили бы мы про 1С-программирование, я ещё мог бы это понять. Но мы говорим о технологии, 99,9% научных исследований и кейсов практического внедрения которой - зарубежные. Зачем здесь это?

Речь шла об "устоявшихся общеупотребимых эквивалентах". Раз уж вы ввязались в дискуссию - приведите, не сочтите за труд, общеупотребимый русскоязычный эквивалент для "minimal viable product" (MVP). Ну и для "application programming interface" (API) заодно, чтобы два раза не вставать.

Полагаю, что у вас это не получится. А вот БЯМ - вполне себе и устоявшийся, и общеупотребимый. В чем моя претензия автору и состояла.

Быстро посмотрел вордстат - статистика запросов LLM и ЛЛМ раз в сто выше,чем БЯМ, причем отдельно

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

Ну и устоявшихся и общеупотребимых аналогов вы привести не смогли. ЧиТД.

Так у нас же есть два вида тестового вывода! Помимо окончательного ответа, есть ещё Reasoning, который предназначается для самой модели. Любая современная LLM отлично умеет редактировать уже написанный текст.

То есть мы можем можно явно указать, что в задаче есть два этапа: на первом этапе модель может и должна использовать абсолютно любые фразы и конструкции в процессе рассуждения, и ей нужно подготовить черновой вариант ответа, а затем уже на втором этапе мы просим этот черновик отредактировать так, чтобы из ответа не торчал слоп и он не выглядел клишированным.

Reasoning это просто часть вывода, для корректной правки, ей нужно вывести в реальный контекст оригинал текста, а потом его править. Есть ощущение что в однократной генерации ЛЛМ сгенерировать текст и корректно его поправить не сможет. Двумя отдельными промптами да, что-то получится

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации