Комментарии 30
Очень круто! И, надеюсь, будет полезно для меня!
Но, пока, интересует вопрос не по теме. Может ли ИИ работать с Интернетом, брать оттуда данные и обрабатывать их? Например, я даю ссылку на файл Excel на каком-нибудь сайте, нужно определить количество строк в нем. Или, пример, чуть сложнее. Сможет ли ИИ проанализировать работу бинарного файла, хоть локального, хоть глобального? Или, в идеале, создать проект кода по нему, с аналогичной функциональностью. Или это фантастика?
У вас, на первый взгляд, два принципиально разных кейса, отвечу по очереди.
Есть множество средств для добавления в контекст файлов в интернете, вы даже сами можете создать такой инструмент для своих нужд. Вопрос механики добавления чего-либо в контекст все же второстепенный по сравнению с сутью требуемой интеллектуальной работы над этим контекстом, его формой и содержанием.
В случае файлов Excel я бы лично использовал ИИ для создания скрипта, который будет надёжно считать строки для сколь угодно длинных файлов, если задача повторяющаяся. Либо можно посмотреть в сторону о3 - она вроде как умеет пользоваться питоном в процессе своих размышлений, чтобы как раз добиться точности в таких вычислениях без необходимости разрабатывать скрипт под задачу, если она разовая. Понадеяться на точный подсчет строк силами самой LLM конечно тоже можно, но я бы не стал, я бы и своим собственным подсчётам на пальцах не доверял в такой задаче.
Задача с бинарным файлом конечно не "чуть" сложнее. Смотря что за бинарный файл и как бы его анализировал человек. LLM в любом случае пока практически не способны делать того, что недоступно человеку. В общем случае, я бы отбросил идею, что ИИ вам сделает полноценный реверс-инжиниринг в красивый исходник по бинарнику
Спасибо, за подробные разъяснения, я примерно так и думал.
Когда я общался с бесплатными ИИ (к другим у меня нет доступа), то, они как бы могут работать с некоторыми файлами из Интернета, но, практически, под разным предлогом, уклоняются от этого. Думал, в платных версиях дела обстоят лучше, но, скорее всего, без дополнительных «танцев с бубном» и там, с разбегу, нужный результат не получишь.
Конечно, все нужные мне данные я могу обработать локально, а всякие там файлы из Интернета, просто, тупо скачать. Но меня интересует вопрос в принципе: Может ли ИИ работать с Интернетом, например, по конкретным ссылкам или нет?
Задача с бинарным файлом конечно не "чуть" сложнее. Смотря что за бинарный файл и как бы его анализировал человек. LLM в любом случае пока практически не способны делать того, что недоступно человеку. В общем случае, я бы отбросил идею, что ИИ вам сделает полноценный реверс-инжиниринг в красивый исходник по бинарнику
Подобный вопрос возник в связи с дискуссиями, что ИИ скоро заменять большинство программистов. Вот я и подумал. Хорошо, есть, допустим простой пет-проект, например мой («Новая компьютерная программа для запоминания иностранных слов и фраз» : https://habr.com/ru/articles/848836/ ). Лучшим ТЗ для программиста, на мой взгляд, является готовая программа-прототип, Программисту нужно написать код, которые делает ровно то, что делает эта программа. Плюс есть какое-то описание в статье и во встроенной помощи. Для профессионала тут работы на пару месяцев, от силы. Но, для ИИ, чтобы сделать аналогичный проект, нужно все подробно разжевывать, а для этого надо обладать уровнем, сопоставимым с вашим, чего, естественно, нет. Вот и возникла мысль. Ну, если LLM такая умная, то пусть возьмет эту программу, запустит ее у себя, проанализирует поведение и выдаст конечный результат в виде исходного кода (в данном случае на С++). Не может? Ну, тогда, что получается? ИИ не может заменить даже меня, программиста-любителя? Тогда думать ей о замене профессионала вообще не стоит?
Ну, хорошо! А как, допустим человеку составить промпт для этой программы? Я бы не смог, хотя сам написал её. Это мне интересно, чисто теоретически. Практически, естественно, ничего делать не надо.
Мнение, что лучшее ТЗ для программиста - это пример программы, неверно. Перед программистом в таком случае должен как минимум плотно поработать системный аналитик. Конечно, я не раз задумывался о том, чтобы автоматизировать работу аналитика, но это в любом случае качественно иная задача, чем написание исходного кода.
Дискуссии о замене программистов ИИ конечно идут, но это ведь только дискуссии. Если бы это было возможно уже сейчас, никто бы не дискутировал. На данный момент ИИ точно не может заменить программиста, но уже способен делать существенную часть интеллектуальной работы, которая еще недавно входила в его основные трудовые обязанности.
Мнение, что лучшее ТЗ для программиста - это пример программы, неверно. Перед программистом в таком случае должен как минимум плотно поработать системный аналитик. Конечно, я не раз задумывался о том, чтобы автоматизировать работу аналитика, но это в любом случае качественно иная задача, чем написание исходного кода.
Как все сложно! Я ведь веду речь не о профессиональном проекте, а о любительском. Там нет никаких заумных алгоритмов. Интерактивная озвучка звуковых фрагментов, ввод / вывод текста на экран, рисование фоновых изображений, вывод данных по таймеру и выбор варианта из доступных. Вот и всё! Зачем нам «кузнец»? («Кузнец нам не нужен!» (с)). То бишь, аналитик. Не, ну расписывать на бумаге, что должна делать программа, конечно, можно. Я это делал, не раз, для себя. Но, тогда я еще точно не знал, что хочу получить на выходе. Сейчас знаю, но как составить оптимальный промпт для ИИ – нет.
Когда-то пробовал просить дать мне код на С++, для игры в «крестики-нолики». Код выдали, он даже компилировался, но был не рабочим. Разбираться было влом, проще реализовать подобный проект, без всяких ИИ, самому. Тем более что, про оптимальность машина не думает, ей главное дать тебе хоть что-нибудь, лишь бы отстал.
Однако, когда я просил сгенерировать скрипты на Питоне, результат был лучше. Некоторые вещи я просто не знал, что сэкономило мне много времени.
На данный момент ИИ точно не может заменить программиста, но уже способен делать существенную часть интеллектуальной работы, которая еще недавно входила в его основные трудовые обязанности.
Согласен, поэтому и посматриваю, краем глаза, в эту сторону. Когда задача имеет однозначное решение, то результат получить легче, например, перевести текст и дать его транскрипцию. Для более неопределенных задач и результат – так себе. Но буду пробовать дальше. Когда смогу заставить ИИ сделать код, полностью реализующий мой пет-проект, тогда мое отношение к этой технологии, думаю, измениться… :)
Всё это, конечно, прекрасно, но в реальной жизни солюшена на 300-500 проджектов 95-99% времени уходит не на написание кода, а поиск куда бы его впихнуть, найти что с чем связано и вообще кто придумал этот бред. Ну хорошо, еще бывают задачи, когда 95% времени ищещь в какой из десятков sql бд, монги, сотен индексов эластика лежат требуемые данные и пытаешься их поджойнить теми самымы 10 строками кода, которые ты искал где написать в задаче перед этим. Как в этом поможет нейронка без каких-либо глубинных интеграций и доступа ко всем данным (ведь документации-то нет, само собой) - решительно непонятно. Вот когда эти вопросы придумают как порешать - заценим. А пока вот разве что сферический regexp в вакууме спросить как написать.
Дать ИИ доступ к таблицам и попросить построить структуру, найти требуемые данные и построить SQL. Работает хорошо, процесс приятнее, чем самому искать по таблицам.
Проблема не праздная конечно)) По хорошему, она должна решаться семантической индексацией проекта (как описано в статье под написанием саммари вместо кода) или проще говоря составлением документации. Некоторым из нашей команды было удивительно даже не только что я тут ИИ раскочегарил, но что я ему внятно объяснил как устроен наш проект. Сейчас к тому же есть Claude Code, который может интеллектуально поползать по репо и написать неплохой черновик архитектуры, Gemini с его огромным контекстом, MCP для доступа к бд, так что в целом-то, инструменты, как минимум, для облегчения связывания рандомных частей проекта вместе и документирования есть. Хотя фокус статьи конечно в первую очередь на генерации нового кода
Спасибо за столь подробный разбор.
Хорошо понимаю вас в качестве начинающих аналитиков, они как лишнее звено между бизнес заказчиком и разработкой и проще самому задать вопросы заказчику и не потерять ничего. По этой причине обязательно надо выяснить UserStory. Это же видимо будет лучшим контекстом для LLM?
Начинающий аналитик пишет в понятиях uml моделей? Почему не человеческом языке или ubiquitous language домена?
Пример на абстрактном классе для меня воспринимается хуже, чем если бы использовался ubiquitous language.
В данном случае претензия к аналитику была не в том, что он что-то упустил (хотя и это имело место), а просто в том, что он невнятно сформулировал алгоритм.
UserStory - хорошее дополнение для основной постановки, позволяющее лучше ее понять, но не всегда достаточное само по себе. На проекте принято писать постановки в терминах бд сущностей, почему - не могу подсказать, но такие постановки часто напоминают псевдокод и ввиду детальности могут уже служить достаточно четким описанием нужного алгоритма.
В принципе можно поэкспериментировать и с постановками в другой форме - я думаю, что они тоже могут дать хороший результат, если глобально при работе с ИИ соблюдаются описанные в статье правила. Вообще, при дальнейшем движении в сторону автоматизации работы аналитика стоит рассмотреть самые разные формы спецификации требований, и возможно, найдется объективно оптимальная для работы с ИИ.
Спасибо за статью, очень интересное чтиво 🤌
Я не программист, поэтому абзацы с кодом пропускал, но в остальном - крайне интересно и полезно. Спасибо!
Отличная, глубокая статья!
Приятно видеть, что многие принципы, описанные в вашей «методологии здравого смысла», пересекаются с тем, что я вывел для себя на практике.
Я прихожу к выводу, что универсального «лучшего» подхода или инструмента нет — у каждого формируется свой, оптимальный для его стека, задач и личного стиля работы, и этот подход рождается именно из практики проб и ошибок.
Благодарю за систематизацию. Как дополнение — для тех, кто не очень понимает нейронные сети, удобно пользоваться оптимизацией промтов от самой нейронной сети. То есть перед постановкой задачи спрашивать, как могла бы выглядеть её постановка.
А затем проверять доработанный человеком промт на неоднозначность и целостность. Мне реально помогает это, так как я веду диалог на русском, а уже финальные промты перекладываю в английский с помощью LLM. Это помогает и в задачах программирования, и в задачах по формированию промтов.
Я тоже часто использую LLM для рендера финального промпта.
На начальном этапе формулирования задачи, просьба задать уточняющие вопросы заставляет модель «проявить» места, где ей не хватает информации или где есть неоднозначность с ее точки зрения. Вопросы модели часто касаются именно тех моментов, где она видит несколько возможных вариантов и не знает, какой выбрать.
Или использую итеративный подход с проверкой результата. Вначале описываю задачу максимально просто, как если бы говорил с коллегой. Смотрю на первый результат LLM. Если он не соответствует замыслу, это сигнал, что формулировка неоднозначна или неполна. Тогда я начинаю сужать эту неоднозначность, добавляя в промпт уточнения, детали, контекст, примеры — редактируя промпт, пока он не станет достаточно точным для модели.
Первый результат часто является тестом для моего промпта. Он показывает, как модель «поняла» мой запрос, и где нужно внести ясность.
Метод оптимизации промптов от самой нейронной сети действительно широко используется, но я пришел к выводу, что такая оптимизации заведомо не может быть глубокой: потому, что LLM по своей архитектуре не способны решать задачу оптимизации.
LLM предлагает результат применения интересных эвристик, но это не решение задачи оптимизации.
Лучшее, что можно попросить от LLM, это написать код для вычислений, который вычислит оптимальное значение.
Немного поработав с нейронками стал воспринимать человека как нейронку, но которая может отказать и обидеться :) как пример: дали задачу дизайнеру нарисовать для определенных соревнований афишу. Выдали человеку словесный Промт :). На следующий день посмотрели на наброски. Там было не то, что нам нужно. Выдали на hagginface нескольким нейронкам , основанным на разных моделях, Промт для дизайнера, только в текстовом формате. За 10 секунд получили красивую картинку почти один в один как накидал дизайнер. Решили доубучить дизайнера. Собрали картинки и сказали, надо чтобы было похоже на это. Ничего сложного, но дизайнер сказал, что нет времени и похоже немного обиделся. Я художник, я так вижу. В итоге дообучил модель и получаю очень классные картинки без нашего необучаемого дизайнера. :)
Ваши оценки совпадает с моими, потому как все правильные ответы совпадают :).
Так же могу поделиться еще парой идей из своего опыта:
1) чтобы ответ был более достоверным и верифицирумым, нужно требовать от модели выводить свой "reasoning" по тому, как был получена каждая единица ответа
2) для обучения модели нужно приводить "reasoning" в примерах тоже
3) если модель выдает неправильные ответы, то эти ответы нужно задать в контрпримерах и обязательно указать в reasoning, почему эти примеры неправильные
4) для еще большего акцента на вопросе можно использовать такую фразу: если от модели требуется найти X, то нужно дописать "Х очень важно <по такой-то причине>".
---
Используя эти техники я реализовал систему проверки, обработки и генерации технической документации. LLM работают конечно офигенно... :).
Не совсем представляю ваш воркфлоу с такими приемами, но применительно к коду и моему подходу, прокомментирую пункты:
1) Это возможно удобно для проверки, почему модель делает не то что ожидалось - заставить ее объяснить, как она что получила. При этом в рабочих промптах излишние комментарии как будто только засоряют выход, не влияя при этом на качество результата.
2) Да, только я включаю интеллектуальные операции не в примеры, а в постановку задачи. Примеры же добавляю отдельно для демонстрации этих операций (опять же отчасти чтобы у модели не возникало желания писать обоснование в выходе, но это не принципиальный момент, и его думаю можно обойти).
3) Можно, но на моем опыте, это признак недоработанного промпта. Как правило, надёжные и стабилизировавшиеся промпты не содержат указаний "как не надо".
4) Может быть, но если имеется в виду мотивация в духе "это вопрос жизни и смерти", по мне это уже шаманство) По-хорошему, код нужно уметь писать без этого, я даже системный промпт не пишу и роли всякие не задаю. Но если "важно по такой-то причине" добавляет понимания о сути задачи, тогда звучит нормально.
Круто, что у вас получается, я тоже тащусь)
по 1)
"reasoning" - это не комментарии в коде, т.к. если код уже написан, то "reasoning" уже не нужен :). Т.к. вижу, что идею не поняли, что еще чуть распишу:
1.1) LLM генерируют токены последовательно, но новые токены сильно зависят от предыдущих
1.2) LLM нужно дать "время" подумать. В текущей архитектуре LLM это означает, что нужно потребовать расписать "reasoning" ДО генерации ответа.
В задаче генерации кода есть особенность: генерация структурно-сложной длинной последовательности. Возможно, что для такого случая есть смысл требовать "reasoning" тоже в структурированной форме, например, сначала потребовать сгенерировать общий план решения и тесты.
---
по 4)
с одной стороны шаманство, но с другой стороны не нужно забывать, что LLM - это "умножитель" на матрицу числовых весов, в которую пихают много информации: LLM бывает трудно расставить приоритеты и у нее мало "памяти". Поэтому в текущих реалиях нужны акценты :).
Советую следующий универсальный промпт как базу всех возможных промптов :)
In a context of {{area}}.
You're an expert.
{{prompt}}
{{response_format}}
area - нужно обязательно
для технических задач, as expert - нужно обязательно
для response_format - рекомендую JSON Schema
В 1 у вас получается классический chain of thought? Если задача комплексная, и вы не уверены, что у вас есть достаточно точный контекст, тогда да, поэтапная генерация рабочий вариант, тоже иногда пользуюсь. В общем же случае мне удается получить от LLM все что нужно без всяких "think step by step", тем более, что у рассуждающих llm аналогичный механизм уже встроен и оптимизирован, а современные не рассуждающие каждый токен в любом случае генерируют не независимо, а внутри планируют решение на много шагов вперёд. Но в целом, chain of thought рабочая техника и не повредит.
По поводу 4, в целом, такой промпт не помешает, но я пока как-то принципиально стараюсь инструктировать LLM так, как инструктировал бы человека, и пока что такого подхода хватает для отличных результатов. Но если вдруг что-то никак не будет получаться, такие приемы конечно доступны)
да, идея очень похожа на COT. Но к этому, требуя описание reasoning, мы (а) понимаем, на основании чего модель принимает решение, (б) беря начало reasoning как выдает модель и дописывая другие аспекты и вывод в reasoning в контр-примере, мы почти гарантируем, что модель будет принимать те решения, которые нам нужны.
По 4). Под человеком вы наверное таки подразумеваете, что (а) человек умеет программировать на языке X и возможно знает что-то в более узкой области, (б) человек не чайник. :)
В 4 я скорее имею в виду, что от того, что я человеку скажу, что он эксперт, квалификации у него особо не прибавится) Просто инструктирую как абстрактного разумного ассистента, прикидывая уровень его знаний и интеллектуальных способностей, без каких-либо фишек, предназначенных специально для "железного друга"
а) LLM обучены на текстах в Интернете и LLM не знает, с каким уровнем экспертности нужен ответ. То, что LLM поняла, что тексты вообще отличаются уровнем экспертности - это её догадка, которую нужно поддержать в промпте. Без этого LLM будет генерировать ответ "среднего" уровня экспертности, которого может быть недостаточно. Т.е. LLM может знать ответ, но не скажет его вам, т.к. он по экспертности выше, чем вы просили :). Обратная сторона: экспертных источников информации гораздо меньше, чем всех остальных.
б) если вы дадите человеку инструкцию "ты - эксперт", то я бы не сказал, что это ничего не меняет: после такой инструкции человек должен проверить, действительно ли его решение соответствует этому уровню и должен иначе оценивать риски.
Звучит здраво, хотя мне до сих пор не требовалось как-то особо усиливать промпты, так как при грамотной постановке у модели в любом случае проявляются лучшие качества, а без нее даже эксперт не будет знать что делать, но с использованием системного промпта не просто при генерации текста (где роль является по сути частью постановки), а при решении формализованных задач, можно также поэкспериментировать👍
Хотя опять же, при решении технических задач это больше как микрооптимизация, не заменяющая фундаментальные принципы
Каким образом осуществляется проверка (верификация) ответа, выданного сетью?
Покажу вопрос на примере, который был, когда я в последний раз пытался применить LLM.
Задача: соединить два подобных документа (скажем, две версии статьи по мотивам модуля) в один или переписать один документ в более компактном виде за счёт исключения повторений. При этом необходимо считать, что потенциальный читатель знает содержание некоторого третьего документа (скажем, список реализованных в модуле функций с их типами), чтобы 1) удалять то, что уже известно, 2) отождествлять то, что обычно не отождествляют.
Метод решения: просим LLM решить задачу, описывает ситуацию, добавляем все три документа, явно маркируя их границы, описываем выходной формат.
Проблема: бывает, что сетка игнорирует фрагменты документов (иногда фразы, иногда предложения, иногда разделы). Выходной результат неправильный.
Я пробовал использовать LLM для верификации, но столкнулся с двумя проблемами: или результат верификации ненадёжен, или требуется размер контекста больше, чем я могу предоставить (особенно если для верификации загружать и «рассуждения» первой сетки).
В моем случае верификация идёт полностью вручную, так как я хотел получить не просто достаточно хороший, а идеальный результат (то есть лучше которого я бы сам не сделал), поэтому мне нужно было убедиться, что он хорош во всех моментах, а не выборочно.
Постановка задачи в примере у вас не очень понятная. Статья по мотивам модуля (учитывая, что в модуле есть функции, значит это наверное модуль ПО) - это типа неформальной документации? Отождествлять то что обычно отождествляют - тоже достаточно расплывчатая формулировка.
Непонятно, что значит игнорирует фрагменты документов в контексте данной задачи. Не совсем понятно как длина контекста исправляет ненадежность верификации.
В целом, использовать LLM для верификации - нормальный подход. Из быстрых советов, которые могу дать даже не углубляясь в детали вашей проблемы - используйте о3 (отрабатывает для чуть ли не на 100% при простой проверке текстов вроде упомянутой вплоть до 100к слов) или Gemini 2.5 Pro (отрабатывает хорошо даже для 500к слов). Но если у вас настолько длинные тексты, я бы скорее всего не стал работать с ними целиком, а попробовал декомпозировать задачу. На первый взгляд, напоминает попытки загрузить в контекст весь исходный код проекта, когда можно этого не делать
Задача состоит в том, чтобы на основе 3 документов составить один так, чтобы он содержал всю информацию, что содержится в первых двух документах, без повторов, компактно, с учётом того, что информация в третьем документе истинна и будущий читатель её знает. Дополнительная задача: обосновать соответствие полученного документа исходному заданию.
Непонятно, что значит игнорирует фрагменты документов в контексте данной задачи.
Вам дали задачу написать обзор на книгу. Вы берёте, вырываете случайные страницы клочками, что целые главы идут в топку, а только после этого садитесь её читать. Со вниманием, с усердием. Вот на что это похоже.
Не совсем понятно как длина контекста исправляет ненадежность верификации.
Я этого не говорил. Правда, я допускал, что кто-то может это сказать, мол, «докинь памяти побольше и будет тебе надёжность», к чему я отношусь скептически. Я же утверждаю, что если длина контекста с гулькин нос, но надёжности неоткуда взяться.
С подобными задачами у меня нет особо опыта, но чисто умозрительно могу предположить, что не стоит ожидать, что вы дадите LLM первый документ, второй и третий, и она все сама сделает без ошибок даже когда документы длинные. Нейросети все равно не на уровне машин обрабатывают кучу информации, у некоторых даже возникает сопротивление, когда вывод достаточно длинный.
Можете попробовать опытным путем подобрать длину фрагментов, с которой ошибок минимум и попробовать декомпозировать задачу на сопоставимые по сложности подзадачи. Например, в исходных документах выделить разделы, сильно связанные по смыслу внутри и слабо между собой, либо если изложение последовательное, просто разделить на части, не знаю.
В любом случае при работе с нейросетью очень полезно понимать, на какие интеллектуальные подзадачи, обрабатывающие ограниченный объем контекста, разбивается основная задача. Что-то более конкретное сложно сказать, так как нужно смотреть задачу подробнее. Вообще, из того что слышал, писатели до сих пор не могут довериться нейросетям как раз в том числе из-за большой длины текстов.
Промпт-инжиниринг на основе здравого смысла: как понимать LLM и получать от них предсказуемый результат