Виктор Прогает в Сербии

У Yii3 снова поднялся вопрос шедулера: мол, будет ли такой пакет? У Yii2 такой был, у Лары и Симфы такие есть. На что @samdark ответил: мол, не делайте голову и пользуйтесь кроном (мой вольный перевод с английского 😁).

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

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

Главный вопрос.
Кто на своих проектах такое хочет попробовать?

Вам интересны LLM?

У меня уже есть некоторый опыт в работе с ними:
▫️ Использование в алгоритмах. Написал проект в HR Tech, где резюме анализируются с высокой точностью с помощью LLM. Так же создал базу знаний (RAG) по проекту на работе.
▫️Coding Harness. Упоролся в кост эффективность, и теперь каждый день работаю с двумя-тремя проектами/задачами параллельно на подписке за $20. Лимит иногда подходит к 70-80 процентам, но только 5-часовой. Вроде бы экономия 180 долларов в месяц - не сильно много, но кто знает, какая это будет сумма, когда токены не будут так активно субсидироваться?
▫️LLM и бесконечный многопользовательский чат. Исследую возможности долгосрочной памяти у LLM. Нейросеть пишет проект такой памяти сама для себя под моим надзором. Ближайший аналог - Zep.
▫️Совсем недавнее. Сделал себе секретаря: он имеет доступ к моему Обсидиану и ведёт списки задач и покупок. Общение в ТГ: новое сообщение - новый диалог, ответ на старое сообщение - продолжение диалога. Человеческий интерфейс задач - заметки в Obsidian. Ещё отлаживаю нюансы, но уже пользуюсь 👍

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

И главный вопрос.
А какие вызовы в использовании LLM видите перед собой вы?

По уже сложившемуся распределению видно, что я жестоко ошибался ☺️ Каюсь, и впредь буду делиться всеми интересными мероприятиями.

Быстрый файловый обмен WSL ↔️ Windows

Вчера Леонид @nex_otaku принес благую весть: он сделал файловый обмен между этими системами быстрым. Замечено ускорение где-то в 7 раз. Секунды вместо пары минут!

Идея проста и сложна одновременно: ин-мемори диск с двойной синхронизацией, с двумя драйверами дисков (windows и linux).

📍 Нужны бета-тестеры новой системы. Кто хочет вписаться или задать вопросы - сделать это можно тут в комментариях (Леонид тоже их читает) или прямо в личку @next_otaku.

Немного нелепого вам в ленту

📝 Возрождение блога

В процессе переезда я не заметил, что у меня сервер стоит неоплаченный. А к тому моменту как заметил - OVH его окончательно грохнул без возможности восстановления. Так что около полугода мой блог был недоступен.

И вот, у меня наконец дошли руки, чтобы его возродить! Адрес прежний: https://viktorprogger.name. Только хостится он теперь бесплатно на CloudFlare.
А т.к. в РФ CloudFlare частенько блокируют, я сделал ему зеркало: https://viktorprogger.github.io/ Наслаждайтесь 😋

Не постил я туда уже очень давно. Но сейчас уже есть пара идей для постов, которые ни сюда, ни на Линкедин так просто не влезут. Надеюсь скоро оформить их в блог 😘 А анонсы будут по-прежнему появляться здесь под тегом #article

Попользовался, рассказываю.

Во-первых, что приятно, в чате не появилось имён. Мы все ещё общаемся на "ты".

Во-вторых, на маленьких и средних задачах я разницы не вижу ни в стиле общения, ни в реакциях на постановку задачи. Вероятно, они просто адекватные у меня 😄

А вот на задаче уровня "сделай хорошо" разница есть. Я решил сделать навайбкодить себе бота для домашних дел. Описал желаемый результат и примерные алгоритмы и инструменты для реализации. И вот тут LLM меня удивила:
- Дала советы по улучшению алгоритма и безопасности.
- Почти во всех сценариях предложила сделать детерминированные алгоритмы вместо подключения LLM после проверки данных: оказалось, что нужные мне данные можно выцеплять напрямую из, например, имейлов и присланных в них PDF.
- И позже взяла на себя всю рутину по предварительной подготовке, которую могла: зашла на Гугл Диск, определила в документах переменные данные, заменила их на {{шаблоны}}, а недостающие данные самостоятельно нашла на почте. Хотя я не просил. И не говорил в черном виде, что они там есть.

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

Стоит дополнить, что я сейчас говорю о модели luna от OpenAI с уровнем размышлений xHigh. И я удивлен тем, насколько она в этом сценарии стала проактивнее (в хорошем смысле) и "разумнее". Осталось только проверить, насколько качественно она напишет код для этого проекта 😊

P. S. Есть у меня ощущение, что не всегда включается "режим партнёра". Подумаю ещё над тем, чтобы жёстче зафиксировать это требование.

Самоидентификация у агента
И прочие вести с piполей

▫️В последнее время я пользуюсь подпиской Codex вместо Claude, и заметил одну особенность у моделей OpenAI: они выполняют инструкции, какая бы дичь там ни была написана. А я как-то привык к Клоду, который меня поправляет в случае чего.

И вот сегодня я добавил в AGENTS.md пару новых инструкций:
- прописал свое имя и имя агента (спросил, какое ему нравится)
- прописал, что мы с ним взаимодействуем как партнёры и всегда говорим друг другу, если наши выводы или действия имеют слабые места.

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

▫️Ещё один вывод: субагенты - мастхев. У меня на пару дней отвалилось расширение с субагентами (по моей же глупости), и стоимость выполнения задач выросла где-то в 3-5 раз 😱 Я за пару дней половину недельного лимита потратил.

▫️Из прикольного опыта именно с pi - это возможность быстро накодить себе экстеншен под любую задачу. Пока мой фаворит - это уведомления в ТГ о длинных задачах. Когда агент уходит на подумать, мне совсем не интересно сидеть и пялить в экран, я занимаюсь чем-то ещё в этот момент. У меня стоит звуковое уведомление для конца сессии разработки, но оно не всегда помогает. Особенно когда я ставлю действительно длинную задачу и ухожу, скажем, мыть посуду. И тут уведомление в ТГ оказалось очень удобным.
По дефолту я определил длинную задачу как 5+ минут, но по факту думаю снизить порог с 2 минут до одной 😂

#ai

Смотря сколько details, смотря какой fabric

Нужна исполнимая политика перехода к `corroborated`. Предлагаю не считать «вероятность» по произвольным весам: хранить отдельные supporting/refuting evidence, их независимые source groups и freshness; предикатная политика задаёт минимум независимых групп, минимальный score и срок. `corroborated` достигается только при выполнении всех условий. Достаточен ли такой policy-based подход?

Я наконец понял откуда взялось мнение, что текст с англицизмами - это нейрослоп. Модельки OpenAI вставляют их по несколько раз за предложение, причем абсолютно неоправданно. Это сильно усложняет понимание написанного 🙈

#ai

pi.dev extensions

Я намедни снова переключился на PI, только в этот раз уже не за токены отдельные, а на подписке OpenAI за $20. Поскольку Антропики прикрывают лавочку с удвоенными лимитами, я решил попробовать воспользоваться более расширяемым харнесом, чем клодкод, но не считая каждый цент.

Пока полет нормальный, активно используют модельки terra (для архитектуры) и luna (для небольших задач вроде исследования и написания кода). Веду паралелльно несколько проектов, лимитов на первый взгляд хватает даже лучше, чем удвоенных у клодкода. А вот описанную в тот раз модель с планированием я понемногу перерабатываю: она оказалась неоправданно долгой и дорогой. Втупую подготовить план выходит примерно так же по качеству, только намного быстрее. О результах обязательно расскажу, но процесс этот небыстрый.

Ну а в этот раз из полезного поделиться я хочу установленными у себя расширениями:

btw - аналог клодовского /btw: позволяет задать отвлеченные вопросы, пока идет основной цикл работы агента. Обычно - с тем же контекстом. Например, в каком состоянии решение вопроса, где как что используется и т.п.

codex-limit - показывает лимиты подписки кодекса

mcp-adapter - позволяет подключать mcp сервера. Они у меня используются еще, но думаю уходить в сторону консольных утилит, которые pi мне сам и накодит.

questions - позволяет задавать вопросы как в клодкоде: они показываются по одному с вариантами ответов и возможностью ввести ответ самостоятельно. Очень и очень удобно.

subagents-lite - возможность запуска субагентов. Когда есть атомарные задачи, очень экономит токены.

web-access - позволяет выполнять поиск в интернете и смотреть сайты, pdf, youtube и пр.

рассматриваю несколько вариантов для управления с телефона

Поделитесь: о каком сценарии использования я еще не подумал, как можно было бы классно расширить свои возможности при использовании pi?

#ai

Новый проект

Мой эйчарный проект уже несколько месяцев в заморозке, я сам уже 3 месяца в Сербии, а значит - надо начать что-то новое 😁 Ну, знаете: шило в заднице поворочать.

Поэтому я написал своему сербскому бухгалтеру вопрос: а есть ли в его работе какая-то нудная неприятная часть, которая отнимает время? Прямо он отвечать не стал, а пригасил к себе в офис. Но это известная сербская тема: они крайне не любят решать какие бы то ни было вопросы в переписке: только лично, или на крайний случай во время звонка 😄 А вот уже на встрече он сказал, что вот есть такой флоу у его сотрудниц каждый раз, когда надо отправить ИП на упрощенке (паушалам) квитанции для уплаты налогов и отчислений (уплатницы):
1. Они скачивают с е-порези (портал налоговой службы) решение налоговой по этому ИП в виде PDF
2. Распечатывают документ
3. От руки заполняют недостающие поля
4. Фотографируют
5. Фотографию отправляют соответствующему ИП
🤯

Вдобавок к этому на уплатнице остается старый, распечатанный из PDF, QR-код (вроде СБП), в котором нет внесенных ручкой на бумаге изменений 🤯

А еще они КПО (книгу доходов) ведут в эксельках, по файлику на каждого паушала. А у них таких ребят десятки. И проблема тут не в поиске файла, а в том, что за каждым из них надо следить: не вылезет ли он по годовым доходам за лимиты налогового режима и постановки на учет НДС?

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

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

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

Бухгалтер после кратенькой презентации сразу попросил сделать ярлык на сайт на рабочем столе для всех своих сотрудниц. И мне даже удалось поприсутствовать при первом использовании сайта одной из них. Из этих двух минут я сделал 2 вывода:

1. Я вообще не умею в UX. Она не поняла что где делать, пока ей раза три не ткнули пальцем. Понятное дело, что это бухгалтер за 50, но все же. У молодого главбуха тоже были вопросы по интерфейсу.
2. Даже стандартизованные документы с гос портала могут отличаться по оформлению. Первые же загруженные для непосредственной работы не смогли быть распознаны 😁 Как оказалось, когда я пришел домой, в шапке этих конкретных PDF была двухколоночная верстка, и мои регулярки сломались 😂 Благо, переписать их было легко. Но надеюсь, что таких сюрпризов больше не будет.

Ну а пока я жду двух вещей и ничего толком больше не делаю с этим сервисом:
1. Отзывов от живых людей. Пока нет понимания, насколько это вообще юзабельно, нет смысла двигаться дальше. Идей для допиливания тьма, но их надо сначала приоретизировать именно под задачи клиента. Хотя парочка идей в моей голове всё-таки имеют топовый приоритет, но фишки это весьма сложные.
2. Банковскую карту, которой можно будет оплатить сервер в Европе 😁 Мою нынешнюю почти нигде не принимают, т.к. банк иностранцам не подключает 3D-Secure 😂 Так что сервис крутится на дешёвом сервере в РФ, куда пинг может идти до секунды. Это пока там интернет не отрубают.

#founderdiary #сербия

Субквадратичное внимание
Недавно вышла статья ребят из SubQ: они придумали и реализовали механизм субквадратичного внимания. Рассказать о нем вменяемо не вдаваясь в технические детали крайне сложно, поэтому ограничусь самыми общими словами: вместо того, чтобы перемножать матрицы параметров для вычисления внимания по каждому токену из истории, оно выбирает только те токены, которые напрямую относятся к текущему запросу. Ещё и ограничивает их по количеству. Благодаря этому алгоритму сложность вычисления векторов внимания падает с квадратичной O(n²) до почти линейной O(n). Что даёт огромный буст к производительности на большом контексте, а стало быть - делает LLM дешевле.
Для сравнения: на контексте в 128к токенов бенчмарка RULER LLM от SubQ показала 97% точности против 94% у Opus 4.6. И по стоимости это вышло $2600 за апишку Антропиков против $8 за инференс на своем железе у LLM SubQ.
Понятное дело, что сравнивать цену АПИ с ценой инференса на своем железе некорректно, но и разница тут не в 2 и даже не в 10 раз.
А еще SubQ уже запустили свою апишку к LLM с аж 12 миллионами токенов контекста! И обещают приличную точность даже на таком объеме. 12, Карл!

Что дальше? Диффузионные модели?
Есть еще такие замечательные вещи как диффузионные LLM. Они создают текст так же, как картинку: сначала появляется шум заданного размера, а затем он за несколько шагов уточняется (это называется денойзинг: из шума появляются корректные очертания). Это не особо популярная технология, потому что ее не выгодно гонять в облаке: у обычных трансформеров (GPT) GPU нагружен постоянно сразу кучей пользователей. Видеокарта отдает токен и сразу же считает другой токен. Возможно, уже другого пользователя. Ноль простоя железа, ноль задержки для пользователей при стриминге. В случае с денойзингом сгенерированный видеокартой ответ не имеет смысла до тех пор, пока не пройденые ВСЕ его шаги (скажем, 20 шагов). Плюс к этому независимо от длины полного ответа, даже если он состоит из одного токена, видеокарта обрабатывает холст полного размера, скажем 256х256 токенов. В итоге получаются лишние вычисления, а пользователи стоят в очереди и ждут, пока API ответит всем остальным вместо того, чтобы увидеть 1 следующий токен своего ответа.
Но чем диффузионки хороши?
А тем, что полный ответ вычисляется значительно быстрее и дешевле, чем в случае с архитектурой GPT, потому что количество обсчетов матриц внимания равно количеству шагов денойзинга. При ответе в 1000 токенов эта архитектура оказывается в 4-5 раз быстрее GPT. Для инференса на своей видеокарте это прекрасно. А еще, как я упомянул раньше, они при генерации ответа видят его весь целиком, благодаря чему снижается шанс словить галюцинацию очередного токена.
Но почему я сейчас о них вспомнил? Все просто: дифузионные модели тоже расчитывают матрицы внимания. Большая разница состоит в том, сколько раз это происходит: если шагов денойзинга у нас 20, то и расчеты произведутся 20 раз. И точка. Но сложность самих расчетов все еще зависит от длины контекста, где и прячется все та же O(n²). И если эти расчеты заменить на алгоритмы субквадратичного внимания с его линейной сложностью, то мы получим как буст к скорости работы с длинным прыдыдущим контекстом, так и повышенную точность на гигантских контекстах.

Когда же ждать диффузионные большие языковые модели с субквадратичным вниманием??
Ответ простой и сложный одновременно: когда у разработчиков появится свободное время, а у компаний - потребность в пиаре. Две огромные проблемы - это то, что диффузионки не нужны облачным провайдерам LLM, и что стоимость их обучения просто космическая. Поэтому одиночки-энтузиасты ничего не смогут сделать, как бы ни хотели. Будем ждать очередной акт невиданной щедрости, например от Google вроде обновленной DiffusionGemma. Если они захотят, конечно.

#ai

Вероятное будущее дешевых SOTA LLM

Люди в интернетах паникуют из-за начинающегося подорожания LLM. Оно и понятно: тот же Anthropic в подписке за $20 позволяет генерировать токенов себестоимостью примерно $2000. Так не может продолжаться долго. Но есть все же свет в конце тоннеля, и я очень надеюсь на то, что он все-таки придет.

Проблема O(n²) и как ее сейчас решают

Как работет трансформер (GPT) не писал только ленивый, так что я на этом вопросе останавливаться не буду. Кто не читал - из последнего могу порекомендовать посты Николая Тузова, мне нравится его слог.

Проблема же высокой сложности состоит в том, что GPT генерируют токены по одному с учетом всех предыдущих. Т.е. банально потому что токены генерируются с учетом контекста. Технически и упрощенно это происходит так:
1. ​Пришел промпт. Модель один раз "прочитала" его и сохранила свойства каждого его токена в быструю видеопамять (это и называется KV-cache).
2. ​Генерируем первый новый токен. Модель вычисляет его связь с предыдущими токенами из кеша, перемножая каждый токен из кеша, т.е. каждый следующий со всеми предыдущими.
3. ​Для следующего токена ей нужно просчитать связи уже со всеми прошлыми токенами плюс с тем, что мы только что создали.

​На каждом новом шаге количество этих операций сравнения растет, потому что история за спиной становится все длиннее и длиннее.

Именно из-за необходимости сопоставлять каждый токен с каждым и возникает квадратичная сложность O(n^2). При контексте в 1 000 токенов матрица внутренних связей внутри механизма внимания разрастается до 1 000 000 элементов, которые нужно обработать.

Это базовая база и основная основа. Этот процесс, изначально построенный на механизме внимания (Attention), сегодня сильно оптимизировали. Самые топовые механизмы распределения внимания — это Grouped-Query Attention (GQA) и Native Sparse Attention (NSA). Первый уменьшает объем KV-кеша в видеопамяти до 8 раз благодаря группировке векторов соседних токенов, а NSA позволяет "скипать неважные" токены в истории при вычислении следующего шага (не без потери точности, конечно). Есть и другие механизмы, которые используют пореже.

Проблема медленной памяти

И всё-таки перемножение матриц - это крайне лёгкая задача для видеокарт. Особенно - для тех, что созданы специально для инференса. Вычисления следующего токена упираются отнюдь не в вычислительные мощности, а в скорость шины памяти, передающей данные из VRAM в кеш процессора видеокарты. Она не то чтобы маленькая, но давайте посмотрим на примерах:
- У топовой NVIDIA Blackwell B200 скорость шины видеопамяти составляет колоссальные 8 ТБ/с. Или, точнее, 8000 ГБ/с, что тоже чуть больше, чем дофига. Но на практике это значит, что моделька размером 70B формата FP16 и весом около 140ГБ за 1 секунду прогонит свои веса через процессор около 57 раз. Или, другими словами, скорость генерации составляет 57 токенов в секунду.
- NVIDIA RTX 5090, топовая игровая видеокарта, разгоняется примерно до 1.8 ТБ/с. Более чем достаточно для игр в 4К, но вот скорость ответа от LLM приличного размера оставляет желать лучшего. Ещё и 140 ГБ видеопамяти никто туда не ставит.

Больше не будет драк за GET vs POST запросы 😁

В IETF стандартизировали (точнее, "придали статус предложенного стандарта") глаголу запроса QUERY. Резон простой: GET существует для запроса данных, но для больших фильтров мы де-факто используем POST, который задумывался исключительно для модификации состояния данных на сервере. Ибо не влазят они в GET-параметры.
Вот и придумали умные дяди с тётями альтернативу в виде QUERY: логически в ответ такой запрос сервер должен возвращать данные без их модификации в БД, но клиент отправляет параметры не в URL, как при GET, а в теле, как при POST. Так сказать, совместили лучшее из двух миров. Только неизвестно когда полноценная поддержка приедет во все браузеры и прокси-сервера.
Источник.

Мое мнение - лучше поздно, чем никогда. А ваше?

Pi и DeepSeek-V4-Flash

Попробовал-потестил (правда, еще без своей памяти). В принципе, все работает как и ожидалось, никаких неожиданных плюсов или минусов не появилось.

Кроме одного, пожалуй: это цена.
Каждый составленный план проходит 2 круга составление-ревью, со второго захода на ревью он получает аппрув. Я разрешил 3 на всякий случай, но еще ни разу не понадобилось.
Так вот: на составление плана уходит очень мало токено/денег. Что-то в районе 5-7 центов. На ревью - вообще копейки. Но умножаем это на 2, и получаем уже больше 10 центов только на составление плана. А следом идет еще и его реализация. Которая неизбежно багованная, но моделька сама ищет и исправляет баги, а это - еще большее количество циклов и раздувание контекста, как бы я ни пытался порубить это добро на субагентов.

Тут надо оговориться еще, что составление плана я от модельки требую на каждый чих, который сложнее прямого ответа на вопрос или редактирования одной строчки. Сильно повышает качество результата ее работы. В среднем мое обычное использование LLM для разработки через Pi выходит от $1.5-2 баксов в день. Обычное - это то, как я использую $20 подписку Клода. Будет подписка за 200 - "обычное" станет совсем другим, конечно 😁

Невозможность запустить суб-суб-агентов.
Я не нашел решение, которое позволялов бы запустить субагента из субагента. А жаль: это было бы очень удобно. Как описывал выше, например: чтобы архитектор не сам лазял по коду, а запустил исследователя и пользовался его результатами в своих рассуждениях. Но вроде как это сделано из соображений безопасности: мол, количество потребляемых токенов может вырасти экспоненциально.

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

Другими словами, она прекрасно подходит для любой рутины, а вот архитектурные задачи по коду я ей все-таки не дам: остаюсь на подписке Клода. Может позже перееду на Кодекс, т.к. его подписку можно использовать в т.ч. внутри Pi, в отличие от Клодовской.

Резюме.
Отказываться ни от инструмента, ни от модельки дипсика я не планирую. Просто буду использовать в других сценариях, а для кода у меня остаются старшие модельки.

#ai

Нужно ваше мнение

Я тут пописываю один проект, долговременную память для LLM. Ну как пописываю... Это 100% вайбкод 😄 LLM пишет память для LLM.

И у меня возникла проблема: я мало что о ней рассказывал кому-то кроме... Да, кроме LLM 🤣 Мне бы очень хотелось узнать мнение живых людей и крутых технарей о своей задумке. Технически она еще не готова, да и, как я уже говорил, навайбкожена. Поэтому сейчас выкладываю только верхнеуровневую концепцию. И тем не менее, получился тот еще лонгрид 😁 Хорошо, что самую скучную часть (описание уже имеющихся подходов к памяти) можно легко скипнуть, если в целом есть представление о них.

Каков ваш вердикт?
- бесполезное💩
- снова эти иишки 😅
- пили, потом посмотрим 🙈
- похоже на крутую инновацию 🔥

https://telegra.ph/Pamyat-LLM-moj-podhod-06-08

#ai