Горшочек варит

Не люблю заниматься предсказаниями. Но прогнозы вокруг AI стали настолько навязчивыми и при этом, как мне видится, поверхностными, что я решил написать свой. И он лежит немного в стороне от популярных вроде «AI всех заменит» или «весь код скоро будет писать AI».

Немного о том, что я наблюдаю в своём «пузыре».

— Всё больше скептиков и критиков AI, которые ещё вчера говорили, что это баловство и «не трушно», начинают активно им пользоваться. Причём часто делают вид, будто никогда и не критиковали. А иногда начинают «бегать» и всем вокруг показывать насколько это круто. Есть те, кто «бегал» и раньше — теперь они бегают ещё быстрее. Хотя большинство и так это видит: нехватки «бегающих» никогда не было, они вещают из каждого утюга. Есть и те, кто посередине — потихоньку въезжают или делают действительно интересные вещи с AI.

— Постепенно складывается консенсус: использование AI действительно повышает продуктивность. Спорящих с этим становится всё меньше. Более того, спорить с тем, что не использовать AI и оставаться востребованным в ближайшем будущем будет сложно, уже практически невозможно.

— Модели и инфраструктура вокруг них за последний год заметно выросли. Рост эффективности я впервые отчётливо заметил ещё в конце прошлого лета — с тех пор всё стало ещё полезнее и лучше.

— Конкретную модель или сервис имеет смысл менять только если вы энтузиаст, исследователь или очень нетерпеливы. Все у всех учатся и быстро перенимают. Конкуренция сейчас высока как никогда, и всё лучшее так или иначе доезжает до всех — вопрос времени.

— Всё это создаёт ожидание, что инженеры скоро станут не нужны. По крайней мере в том виде, в котором мир знает их сегодня. Модели и агенты уже пишут код на уровне выше среднего разработчика — и делают это быстрее. Поэтому довольно устойчиво звучит мысль, что скоро весь код будет писать AI. Но к этому я еще вернусь ниже.

— При этом никто на самом деле не понимает, куда всё движется. Есть только гипотезы. Сейчас слишком много новых эффектов и последствий. После серии волн увольнений наступила пауза: бизнес, похоже, тоже пытается понять, что происходит. Уволить всех инженеров не проблема. Вопрос — что делать дальше. Кто будет решать проблемы, если они возникнут? Как понять, что они вообще возникли? То, что инженеры «не пишут код», никак не снимает вопросы: кто отвечает, кто чинит, кто обеспечивает SLA и т.д.

Это очень грубое описание того, что я сейчас наблюдаю. Во всей этой истории, как мне кажется, упускают главное: инженеры не пишут код — инженеры решают проблемы. Не все, конечно. Некоторые ничего не делают, а некоторые эти самые проблемы и создают. Но если исходить из основ, то она именно в этом.

Проблема в том, что большинство прогнозов сегодня строится вокруг скорости генерации кода. А не вокруг реального решения проблем, для которых этот код вообще существует.

Я попробовал посмотреть на происходящее именно с этой точки зрения и написал небольшую статью с прогнозом на ближайший год. Через год посмотрим, насколько точно попал.

https://medium.com/@rdvornov/ai-and-the-coming-correction-e93bb31b9476

Давно не писал про CPUpro и мои продвижения в профилировании. Я не перестал этим заниматься — скорее наоборот. За это время очень многое поменялось, и я продвинулся дальше, чем ожидал.

Несколько месяцев назад я сделал, в какой-то степени, безумный шаг. Я стал записывать каждую аллокацию как отдельное событие. Делал это и раньше, но теперь нашёл способ делать это, не убивая рантайм. Однако этого оказалось недостаточно — нужно было ещё научиться работать с новым классом данных. В итоге я значительно переписал CPUpro: его модель обработки и сам подход к работе с данными.

Параллельно я закончил ряд экспериментов и сделал прототипы в смежных направлениях. Как оказалось позже, это были необходимые и важные компоненты всей истории. Хотя, признаться, в моменте я о них так не думал. В итоге пазл сложился.

В середине декабря я смог написать свой вижен — документ, который описывает общую картину профилирования на ближайшие несколько лет, каким оно может стать. Описание разбивается на шесть слоёв:

• runtime — сбор данных
• транспорт — передача и кодирование данных
• обработка данных — вычисления и структуры
• представление данных — не столько в визуальном плане, сколько в том, как мы оперируем данными и представлениями
• связь с кодом — исполняемого с исходным, в том числе через карты кода
• анализ – интерпретация результатов и когнитивная нагрузка

И всё это — в масштабе больших и сложных приложений (систем). В масштабе современных зрелых продуктов, а не «to-do list». На каждом слое есть свои большие вызовы и фундаментальные проблемы, которые не решаются на протяжении многих лет. Решение только на одном из слоёв ситуацию в целом не меняет. И вот у меня, наконец, на руках оказались все «ответы».

Это не значит, что всё решено и готово. Это значит, что принципиальных инженерных препятствий нет. Но есть препятствия иного плана. И да, всё это ещё предстоит реализовать и обкатать. Главное же, я уже вижу, куда всё это ведёт. И сам не заметил, как сделал качественный переход к новому классу профилирования. Пока ещё не в практическом смысле, впереди много работы, но в ментальном, концептуальном плане.

Когда сейчас я рассказываю другим о профилировании, каким оно может быть в некотором будущем, меня не понимают. Но не потому, что я говорю что-то слишком сложное, хотя и такое случается. Проблема в другом. То, о чём я рассказываю, собеседники приземляют на свой текущий опыт — на то, что они уже знают и умеют. Я же, по сути, говорю из «будущего». Ведь они ещё не сделали тот самый качественный переход, который у меня произошёл в процессе моей работы.

Поэтому я понял — признаться, не сразу — что нужно найти способ «синхронизироваться». В итоге написал статью, которая задаёт необходимую рамку, чтобы начать говорить о профилировании, каким оно может быть, на одном языке. Статья не даёт ответов. Она подводит к тому, чтобы задуматься, что такое профилирование и как мы об этом думаем. И это не только про поиск узких мест, когда что-то тормозит. Мне видится, что профилирование может, и должно, стать чем-то значительно большим – нашим пониманием как работают сложные системы.

Возможно, после этой статьи вы тоже это почувствуете.

https://medium.com/@rdvornov/why-profiling-leaves-you-guessing-58f36a97e36f

Сегодня сделал наблюдение. Оно выглядит простым, но становится некомфортным, если посмотреть на него повнимательнее:

Стабильность и объективность сложных систем возникают из структурированного сосуществования конфликтующих оценочных перспектив.

Если вы подумали про инженерные системы – вам не показалось.
Если вы подумали про институты – вам не показалось.
Если вы подумали про человеческие формации любых форм и масштабов – вам не показалось.
Это универсальный принцип.

https://medium.com/@rdvornov/stability-comes-from-tension-fa341c9bb719

Занятный арт получается, в попытках нарисовать полезный граф переходов в байткоде.
А еще с удивлением узнал, что часть D3 можно применять для канваса, например, укладка графа это на его API (d3.forceSimulation), но не только. Сам бы не стал использовать такую комбинацию, но есть кому подсказать ;)

А может быть вы знаете хорошие примеры отображения флоу исполнения программы, где видно наиболее частые переходы?

Я стараюсь не "общаться" с LLM на русском, потому что проще описывать и читать технические моменты на английском, без путаницы в терминах, без кривых объяснений и проблем перевода. А еще LLM часто выдают странный сленг, местами переходящий в кринж. Уж не знаю на каких текстах обучают модели, что они выдают такое.

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

Так вот, моё слово дня – "низведение" (lowering, подходит и для desugaring). Встречал его когда то в институте, в математике, но тогда это был еще один скучный термин. Сейчас же, в контексте моих задач, оно заиграло новыми красками. Настолько понравилось, что не смог не поделиться :)

Написал 7 спек для одного нового проекта со вчерашнего вечера. Это вот такие документы, 5-18кб текста, где расписаны все детали. Планировал расписать лишь 2 спеки, а остальные 5 появились уже по ходу. 3 из них – это совсем новые идеи, о которых даже не думал пока не начал работать над документами, и пока в контексте – проработал и расписал. Еще одна – решил заодно описать идею, над которой не планировал работать, из разряда nice to have, она не очень сложная в реализации, но провалился в проектирование на пару часов. И еще одна скорее систематизация, но тоже оказалось полезно.

И вот так одно за другим тянется. Стоит лишь войти во вкус. А самое удивительное, насколько хорошо получилось проработать, еще не имплементировано – а мне уже нравится как все работает. Хотя насколько хорошо еще предстоит выяснить :)

Но сейчас одназначно можно сказать, что получилось весьма быстро проработать весьма сложные штуки. Без ИИ было бы в разы дольше. Хотя я бы и не занимался этим проектом без ИИ – не потому что не справился бы, а потому что даже самые оптимистичные оценки по временным затратам выглядят слишком нереалистичными. А с ИИ всегда кажется, сейчас за 5 минут соберу, чего там. А потом "Few moments later..." пролетели дни, недели... и у тебя из простой идеи уже космический корабль получается :)

А еще приятно получать комплименты от агентов про проработанность после часов работы над спеками, хотя этого не просишь. Более проработанные спеки = лучше анализ для планирования и имплементация. Ну и больше комплиментарных комментариев 🙂

Вот я специально скопировал с моим небрежным промптом, чтобы показать что я не просил оценки спек и самих фич (возможно "cool features" повлияло, но не думаю что сильно). От агента лишь требовалось, чтобы новые спеки были учтены в планировании предстоящих работ, и только – то есть расширение контекста и горизонта планирования. А он (Claude 4.5) вон чего.

То что наш образ (опыт) работы с приходом ИИ поменяется – это правда.

Я все больше занимаюсь тем, что проектирую и пишу спеки/дизайн документы, а имплементацию отдаю агентам. Конечно, я делаю ревью, инструктию и направляю, заставляю переделывать, провожу интервенции в процесс написания кода, через рефакторинг руками. И при всех недостатках текущих моделей/агентов, и издержках с этим связанных – я замечаю, такой подход к процессу более эффективный и быстрый. Может казаться, что самому руками быстрее, и в каких то задачах действительно так. Но в основном, наоборот руками медленее – хотя может восприниматься по другому. Но чтобы получалось действительно эффективно, нужно учиться и нарабатывать опыт взаимодействия с ИИ.

Раньше я кидался реализовывать самостоятельно, экспериментируя и подбирая решения по ходу. Теперь описываю сырую идею (идеи) ИИ и затем в несколько раудов мы доводим до ума, и финализируем в виде доки (дизайн документ, спека, вижн или подобное). Раунды достаточно длинные – пока вычитаешь в деталях ответ модели, выпишешь замечания или опишешь новые мысли, подумаешь глубже, проходит от нескольких минут до часа и больше. Получаешь новый ответ – снова вычитываешь, и так пока ошибок, нестыковок и пропущенных моментов не останется. Раундов обычно около 5, иногда значительно больше – зависит от масштаба и сложности.

Просто копипастить результат, прочитав по диагонали, потому "выглядит похоже на правду" – не лучшая идея. Потому практически всегда остаются недаработанные моменты, искажения идеи, нестыковки, да и нередко просто фатальные ошибки, которые при беглом просмотре не распознаешь. Если такое отдаешь в работу агенту (и не агенту), то в итоге придется разгребать последствия, когда уже дорого менять и усилия могут быть выше чем перепроектировать и переимлементировать с нуля. Причем не всегда получается починить неработающее (например, ошибочный подход или решение), все равно придется переделывать с нуля. В любом случае получается большой штраф в виде потерянного времени. И если не вкладываться в проектирование, то можно наступать на те же грабли не раз, и не два.

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

Кроме того, остаются артифакты в виде документов в хорошем состоянии, которые в последствии можно переработать в документацию. Из таких документов получается более проработанная документация – меньше править. Документация, или сами документы, хороший материал для будущих фич, и даже для задач на других проектах в качестве референса. И для тест плана такие документ безценный материал, если проработы нюасы, примеры и крайние случаи. В общем сплошные плюсы.

Но нужно учитывать, что работать с документацией и ИИ – это тоже особый навык, который нужно нарабатывать. Много букв и умные слова по тексту не равно полезный документ.

Mozilla проводит опрос для выявления интереса использования ReadableStream в fetch в качестве тела (body) запроса, для поточной передачи данных. Я писал об этой фиче сколько то месяцев назад, поддерживается в Chromium, Node.js, Deno и Bun. А вот в Firefox и Safari пока такой поддержки нет. Надеюсь результаты опроса подтолнут разработчиков поскорее это имплементировать, тогда дело останется лишь за Safari.

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

Прямая ссылка на опрос (короткий, на 1-2 минуты)

Мой первый патч в V8 – только что смержен! 🥳

Я все еще разбираюсь в процессах, и то что первый патч дошел до мержа – большое для меня свершение. Патч небольшой (одна строка, может поэтому и доехал первым), но исправляет неприятный баг.

Когда записывается V8 лог с флагом --log-deopt, то помимо добавления записей о деоптимизациях лог, V8 также выводит сообщения о деоптимизациях в консоль (stdout). Так быть недолжно, ведь вывод в консоль – это трейсинг. Но дело, конечно, не в нарушении разделения функциональности, а в том, что так захламляется консоль и смешивался с выводом профилируемой программы. Могло доходить до того, что приходилось выбирать: либо лог деоптимизаций, либо работающий скрипт.

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

Так я раскопал в чем корень проблемы, которой уже более 4х лет. В ходе очередного рефакторинга флагов, в V8 добавили новый флаг --log-deopt, который должен был включать логирование деоптимизаций. Но в ходе рефакторинга этот флаг по ошибке добавили в условие активации трейсинга деоптимизаций. В итоге, когда включаешь логирование деоптимизаций, также включается и трейсинг деоптимизаций, и этот трейсинг никак не отключить (например, через другие флаги). Теперь этого происходить не будет, каждый флаг (--log-deopt и --trace-deopt) делает ровно то, что должен делать. Мелочь, но сколько сэкономленых нервов!

Раскопал и подобрал патч я еще в мае, но вот только сейчас это доехало до апстрима V8. Путь был тернист. Но дорожка понемногу протаптывается, придет время – будет быстрее.

Speeding up the JavaScript ecosystem - Semver

Несколько дней назад вышла очередная статья от Marvin Hagemeister из его серии про ускорение экосистемы JavaScript, которую он ведёт аж с 2022 года.

Наткнулся на неё случайно: просматривал, кто недавно лайкнул CPUpro на GitHub, увидел Marvin'а, зашёл в его профиль, оказался на его сайте — и там обнаружил совсем свежую публикацию. Решил почитать и уже в первом абзаце увидел ссылку на cpupro, что приятно удивило 😊

Если честно, я ожидал, что автор покажет как использовал CPUpro для анализа, но в статье нашлось лишь два похожих скриншота из CPUpro — топ по пакетам (до и после). Кроме того, Marvin применил инструментирование, чтобы определить горячие точки в коде. Не имею ничего против инструментирования — сам нередко использую. Да и это позволило ему собрать бенчмарк для дальнейших экспериментов. Но с CPUpro и V8 log в таких случаях необходимость в инструментировании часто отпадает. Я предположил, что Marvin использовал .cpuprofile и пользовался ограниченным набором возможностей.

Я также решил повторить эксперимент из статьи: склонировал Preact и записал V8 log на npm install. Результат у меня получился иной: влияние semver оказалось в 2–3 раза меньше (в относительных величинах), чем в статье. «Возможно, я что-то делаю не так» — подумал я. Зато при анализе результатов профилирования обнаружил несколько багов в CPUpro, исправил их — так что, в любом случае, упражнение оказалось не бесполезным. Еще я заметил пару опечаток в статье (вместо cpupro было cpuprof :), и одно число было неверно перенесено со скриншота).

В общем, поводов написать письмо набралось достаточно, и я написал. Через пару дней получил ответ. Моё предположение подтвердилось: Marvin действительно использовал .cpuprofile и не знал, что в CPUpro есть поддержка V8 log. Пообещал изучить и, возможно, написать об этом в следующей статье. Будем ждать.

Что касается результатов профилирования, он повторил замеры, и у него они тоже оказались ниже, чем описанные в статье. Это его озадачило — он предположил, что мог профилировать в энергосберегающем режиме (такое бывает, сам сталкивался). Как бы то ни было, это не сильно что-то меняет — статья хорошая и полезная (как и другие из этой серии). Конкретные цифры не так важны, как используемые подходы и практики.

Всё никак на складывалось написать про статью, но тут Никита в своём канале (mefody.dev) написал про нее. Спасибо ему, напомнил 🙂

Jora Making Me Crazy

Еще одна статья, в этот раз не моя, автора не знаю. Наткнулся на нее несколько недель назад, просматривая рефералы на одном из репозиториев. Сначала подумал, что это очередной авто-блог генерируемый AI. Но оказалось, что очень даже человеком написаная статья, но отрефайненная через AI.

Почему я уверен что написана человеком? Во-первых, тема, мягко говоря, не самая хайповая 😉 Во вторых, описывается не "фасад", то есть суммаризация первого, что попадается по теме – а фичи, которые я намеренно не офишировал, но и не прятал и их можно найти, если хотя бы прочитать ридми проектов. В третьих, явно на каком-то опыте написано, и примеры, и скриншоты, и вывод из консоли — не вызывает сомнения что это что-то персональное.

Отдельно порадовало, что автор откопал малоизвестный jora-cli, который я значимо обновил в феврале (и не написал об этом). Так вот, если вам, например, нужно убрать из JSON форматирование (или добавить), или сделать выборку (используя jora, у которого уже неплохая документация), и все это невзирая на размер – то jora-cli ваш друг.

Но автор нашел еще, что jora-cli поддерживает экспериментальный бинарный энкодинг `jsonxl` (который поддерживает и Discovery.js, и проекты на нем), как на вход так и на выход, и можно значительно уменьшить размер JSON файлов (и они еще хорошо gzip'ятся!). У автора разница в примере меньше 2,5 раз, но для .cpuprofile или stats.json размер обычно уменьшается в десятки раз. И разница особо чувствуется для данных в десятки и сотни мегабайт JSON. Попробуйте на ваших данных, интересно какие у вас будут результаты.

В общем приятно читать, когда кто-то делится своим опытом использования штук, которые делаешь. Рекомендую статью, хотя бы пролистать.

A surprisingly simple trick: Converting FormData to multipart/form-data string and back using Response

Пока в отпуске, не очень получается писать — поэтому делюсь еще одной статьей, которую я собрал на основе поста в канале, но забыл об этом написать (написал статью еще в декабре). А именно, про неожиданное открытие возможности конвертации в multipart/form-data строку и обратно с помощью Response. Я так и не смог найти чего-то подобного, зато нашел множество монструозных инструкций, которые я бы не стал повторять.

В общем маленькая практическая статья, про скрытые (побочные) возможности современных API.

Настал тот день, когда я создал все ишью про баги в профилировании V8 связанные со стеком вызова и локациями. Всего 6 багов, которые я находил и изучал с начала мая. Мне также было важно иметь инструменты для выявления и отображения проблем, поэтому я работал и над методами визуализации (в CPUpro). А так же, погружался в матчасть, учился (и все еще учусь) описывать такие "явления" в правильных терминах, и чтобы было максимально полезно как в моменте, так и на перспективу. В общем, большое маленькое достижение.

Основной документ исследования, с деталями и выкладками: V8 profiling issues: Call stack capturing (18 страниц!)

Список багов (про первые два я недавно писал):

- Missing stack frame for Ignition functions at stack top (PC)
- Incorrect PC for Ignition frames at stack top
- Missing stack frame for Sparkplug functions at stack top (PC)
- Missing position tables for Sparkplug in V8 log
- Missing inlined stack for Turbofan (and Maglev) at stack top (PC)
- Missing inlined stacks for Maglev (position table)

Как можно заметить, проблемы у всех 4х компиляторов. Ключевое: для неоптимизирующих (Ignition и Sparkplug) пропадает большая часть их семплов на вершине стека, для оптимизирующих (Turbofan и Maglev) – пропадает инлайн стек (для Turbofan лишь на вершине, у Maglev – всегда). Ну и так, по мелочи.

Каждый баг сам по себе не очень приятный. Но все в совокупности... это просто ведет к бесполезным профилям. Я на своих сборках починил часть багов, часть проблем обхожу флагами – и могу сказать, что получаемые профили уже совсем другого качества. Так что надеюсь получится это все починить, самое сложное сделано – проблемы найдены 😉

А если серьезно, то часть проблем решается просто (я даже приложил патчи), часть посложнее. А чтобы это двигалось быстрее, поставьте +1 на ишью из списка (кнопка +1 в шапке ишью). Не то чтобы это решает всё, но определенно помогает.

И небольшой тизер – это только проблемы про стек вызова. А есть еще один подобного масштаба кластер проблем, и множество разрозненных багов. Так что впереди еще много работы, очень много...

Я экспериментировал с Playground. В нем тоже нельзя вставлять супер большие сообщения. Но есть отдельная секция Prompt messages, куда можно добавить без проблем. Впрочем, результаты оказались посредственными, модели теряются когда нужно сделать большую сложную выборку из большого текста. И к тому же очень медленно работают, когда контекст под завязку (хотя не факт, что проблема в самих моделях). Я думаю, если попросить найти какой-то факт по тексту, то может что-то и выйдет. А вот если нужно вычленить несколько десятков килобайт текста, который идет не подряд — то это уже невыполнимая задача. В итоге я вручную выбрал посты где затрагивалась заданная тема. Вышло 68Kb текста или 16k токенов.

С меньшим размером текста модели стали работать заметно быстрее. Однако результат получался далеко даже от приемлемого. Я просил генерировать на английском, переводя на лету с русского. В какой-то момент подумал, что это будет усложнением для LLM и решил перевести материал один раз на английский и потом работать с ним.

68Kb кажется небольшим объемом. Но это субъективно. Чтобы оценить такой объем - стоит начать переводить. Или хотя бы вдумчиво прочитать. Так вот с задачами перевода и адаптации текста LLM справляют отлично. Я попросил перевести и сохранить авторский стиль. И результат получился весьма качественный, насколько я смог оценить читая по диагонали. Заняло это все около 5 минут или больше, но точно не больше 15 минут. Стоило это меньше доллара. И это действительно поражает (до сих пор).

> Помню, как мой коллега заказывал перевод примерно такого объема лет 7 назад, он тогда отдал не менее 150 долларов (не помню, может и в 2-3 раза больше), ему переведили 2 недели и качество перевода было весьма посредственное, так как переводчик не очень знал профессиональную лексику.

С материалом на английском, модели стали еще шустрее работать и качество ответов повысилось. Осталось получить статью.

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

Подумал — не беда, ChatGPT же теперь умеет ходить в сеть и делать поиск - попробую напрямую из ChatGPT запросить. Тоже не выходит: телеграм закрывается от ботов, хоть через поиск, хоть по прямой ссылке — ChatGPT не может получить содержимое телеграм каналов.

Что ж, пришлось действовать старым "дедовским" способом. Открыл веб-версию канала и пролистал всю ленту, чтобы загрузились все сообщения (там используется подгрузка при скроле). Далее открыл консоль и буквально "на коленке" написал скрипт, который через DOM выбрает все блоки постов, выбрает нужные данные из них, отчищает текст сообщений от лишней разметки и превращает его в markdown. Наконец-то пригодилось знание DOM для чего-то полезного 😏 Код вышел грязным и в лоб – но свою работу делает.

В итоге вышло ~450Kb текста с атрибутами, без изображений и видео. В Word'е в дефолтных настройках (Calibri 12pt) это 166 страниц (58 тысяч слов). Этот текст превращается в ~118 тысяч токенов (OpenAI Tokenizer), что умещается в текущий стандарт для размера окна контекста в 128k токенов и еше немного остается.

Несмотря на размер контекста модели (для GPT-4o — 128k, GPT-4.1 — 1M, GPT-o4-mini — 200k), в интерфейсе ChatGPT нельзя отправлять сообщения более определенной длины. Точных размеров не выяснял, но это где-то около 100Kb (символов, не токенов). То есть скормить текст такого размера как у меня (450Kb) целиком в чат не выйдет, или по крайней мере не одним сообщением.

Хорошо, у нас еще есть возможность прикреплять файлы. Пробуем, но это работает совсем не так как ожидается. Целиком файл не обрабатывется, AI модель так или иначе делает выборки из файла (фрагмент или фрагменты) и работает с выбранным. Для выборок обычно модель пишет Python код. Что попадет в выборку и по какому принципу, тот еще вопрос. Вернее как модель решит. Например, может взять первые несколько килобайт (для чего напишет скрипт), или решит искать по ключевым словам (то есть напишет код, который это делает), при этом поиск строгий и набор слов (количество и состав) — это как повезет. Надежность такого подхода сомнительная. В целом, работа с прикрепленным файлом носит очень приблизительный характер. Может хорошо работать для файлов с данными, типа CSV, так как это лучше поддается детерминированой программной обработке. Но вот для текста (markdown), где большая вариативность — работает так себе. Вероятность успеха (success rate) не нулевая, но чем больше текст тем больше падают шансы.

В общем, для полноценной работы с текстом (например, чтобы не потерялись какие либо факты или детали) весь он должен быть в контекстном окне. Чтобы использовать контексное окно целиком для больших текстов, остается только использовать либо API (в конечном итоге), либо Playground. Плюсы: больше контроля, можно управлять параметрами, например, температурой (насколько рандомизируется результат). Главный минус — стоит отдельных денег, то есть нужно оплачивать входящие/выходящие токены, но цены вполне умеренные.

На самом деле, эта серия статей в некоторой степени последствие экспериментов с LLM. А точнее исследование их ограничений и возможностей. Хочу оговориться, что я не делал масштабных экспериментов — не мой профиль. Я опробовал лишь несколько моделей от OpenAI, так как наиболее нам доступны. И все же есть чем поделиться.

Одна из моих задач не такого уж далекого будущего — это использование AI для анализа профилей производительности. И здесь мы сталкиваемся с большими контекстами. И дело не только в размерах самих профилей, которые могут быть сотни мегабайт — с этим можно справиться, например, обернув тот же CPUpro в MCP, и предоставив возможности для необходимых выборок.

Но я думаю немного дальше, как не только определить проблемное место, но и найти способы это исправить. И вот это еще одно направление, где нужен большой контекст — потому что проблема часто не в том месте, где тратится больше всего времени, она может быть где угодно. И чем больше проект, тем больший контекст необходим. Да, можно выбирать лишь части кода, например, связанные функции с определенной глубиной. Но, думаю, у большинства есть этот опыт при отладке, когда можно "проваливаться" достаточно глубоко внутрь, прежде чем необходимое место будет найдено. Так и любой AI агент будет добирать в свой контект все больше и больше функций (кода) пока, возможно, не захлебнется.

В общем контекст может получаться большим. Отдельная проблема как это все выбирать, но представим, что это уже есть (то есть реализовано). Насколько большим может быть контекст? Влияет ли размер контекста на результат? Будет ли это работать? Для ответа на вопросы можно опираться на публикации, заявления и даже спеки к моделям. Но пока не попробуешь на конкретной задаче в реальных условиях — это все "конь в вакууме".

Так, я решил поэкспериментировать. И даже еще больше упростить задачу для LLM. Сначала я думал взять достаточно большой модуль и пробовать задачи на нем. Но код это сложно, плюс всегда есть зависимости от других модулей, пакетов и API, что может влиять на качество результата. Поэтому я подумал, а что если взять просто текст — работа же с текстом сильная сторона LLM — и сначала проверить на задачах с текстом. Так можно получить т.н. baseline, и если все хорошо, то продолжить двигаться в сторону кода.

В качестве цели я выбрал собрать развернутую статью (или серию статей) про веб-стримы, на основе своих постов в этом канале. Я хотел собрать статью еще как только закончил цикл постов, но время на это не нашлось. А тут получалось совместить приятное с полезным.

И тут может показаться, что задача плёвая — «мы уже сто тыщ милльонов раз видели суммаризацию». Но в данном случае, задача не такая простая. Во-первых, нужно выбрать материал, который перемешан с другой тематикой и стороними мыслями, который к тому же не структурирован как что-то цельное, так как писался в формате блога или летописи. Во-вторых, нужно сгенерировать очень большой текст, со структурой и перекрестными ссылками, чтобы в результате использовались все моменты и нюансы из оригинального материала. В-третьих, у меня есть (надеюсь) своя стилистика, вкус и виденье каким должен быть результат – то есть недостаточно просто создать статью, она должна быть определенного уровня и качества. В-четвертых, это техническая статья и поэтому формулировки должны быть точными, факты – достоверными на момент публикации, примеры и фрагменты кода – логичными и корректными, и т.д.

То есть задача достаточно непростая, кто использовал LLM для генерации больших текстов — тот знает. Но попробовать все таки стоит – интересно же, что может получиться.