БУсинки. Нужно ваше мнение. Занят агентик модом. Суть сейчас - есть несколько агентов, которые собираются на основе вашего пресета, сначала они отрабатывают, давая рекомендации основной модели. Потом отрабатывает основная модель. Потом отрабатывает пост-модель (в теории), которая подчищает всякие клише/забаненные слова и так далее. Пока это все "условный совет директоров", который отрабатывает историю и дает советы, которые основная ЛЛМ может проигнорировать. Но оно, в целом, работает. И даже если один из директоров "ебанулся нахуй", мы получаем нормальный ответ и довольно быстро. Есть мысль сделать их не одновременными, а последовательными. Каждый агент будет выдавать кусок текста и каждый последующий будет модифицировать его. Т.е. первый агент накидает, условного слопа. Второй посмотрит - так, это слоп, надо переписать вот тут. Третий посмотрит - слишком коротко, на еще вот так. И т.д. Проблема? Слишком долгий ответ и слабые ЛЛМ могут не потянуть. И не надо мне советовать "Посмотри Маринару/Проликса". Там боль.

отдыхаю пока от глазури, родил вот такую вот штучку:

https://t.me/itshydall/123

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

рп с худалом больше не локальный мем


это шутка кто будет писать туда гадости тому запрещу писать, только по делу пишите

я передумал, рп с худалом вырезано 😔

из других новостей: бета скоро™, с полностью встроенным JAR внутрь

Короче. Сейчас будет реально сложный вопрос.
Зачем вам HTML и трекеры в RP?
Самый очевидный ответ: это ярко, наглядно и даёт быструю эмоцию. Произошло действие, изменилась шкала отношений или появился «шанс зачатия» — и кажется, что игра действительно отреагировала: «Ничего себе, технологии».
Возможно, многим этого уже достаточно. Большинство людей приходит в RP не анализировать расход контекста и сценарную архитектуру, а получать эмоции. Я, возможно, смотрю на это иначе: когда первоначальный восторг от LLM проходит, начинаешь больше замечать качество текста, глубину арок и реиграбельность.
Сразу уточню: не все трекеры бесполезны. Компактная сводка с местом, временем, одеждой, состоянием персонажей, активными конфликтами и ближайшими арками помогает модели удерживать важные факты, не раздувая контекст пересказом всей истории. Улики, ресурсы, выборы и последствия тоже имеют понятную функцию: они меняют ход игры.
Но было бы неверно утверждать, что декоративные трекеры вообще не влияют на RP. Влияют. Если модель в каждом сообщении видит «ревность: 82%» или «беременность: 12 недель», она начинает чаще возвращаться к этой теме и строить вокруг неё сцены и конфликты.
Только дело здесь не в красоте HTML. И веса модели, строго говоря, не меняются. Просто одна переменная постоянно находится в актуальном контексте и перетягивает на себя внимание.
Поэтому сравнивать нужно не игру с трекером и игру совсем без него, а три варианта: красивый HTML-блок; та же информация одной строкой в краткой сводке; отсутствие этой информации в актуальном контексте.
Если HTML-блок и обычная строка дают примерно одинаковый результат, значит, работает не интерфейс, а постоянное напоминание. В таком случае трекер — не отдельная игровая механика, а визуально оформленный костыль для управления вниманием LLM. Иногда полезный, но всё же костыль.
Более того, этот эффект может не углублять историю, а сужать её. Когда перед моделью постоянно висит одна шкала, она снова и снова строит сцены вокруг беременности, ревности или возбуждения, отодвигая другие конфликты. Движение вроде бы есть, но оно возникает из-за навязчиво подсвеченной переменной, а не благодаря глубине сценария.
Есть и техническая цена. Если HTML генерирует та же модель, что и основной ответ, она может путать значения, ломать разметку и тратить часть вывода на оформление. Если модель выдаёт только маркеры, которые затем подставляются в готовый шаблон через регекс замены, результат стабильнее, но быстро становится предсказуемым. В обоих случаях стоит спросить, оправдывает ли эффект потраченный контекст и возможное снижение качества основного текста.
Проблема может начинаться ещё раньше — на уровне карточек. На том же JAI много сценариев строится вокруг нескольких знакомых архетипов: мафиозный босс, властный партнёр, опасный незнакомец. Сами тропы нормальные, но за яркой завязкой нередко нет конфликтующих целей, скрытых линий, развилок и долгосрочных арок. Поэтому через сотню сообщений разные сессии начинают повторять друг друга, а очередной трекер лишь ненадолго возвращает ощущение новизны.
Да, заложить несколько полноценных арок, переплести их, прописать условия входа и последствия решений намного сложнее, чем добавить прогресс-бар. Зато такая структура позволяет истории не исчерпываться после одной завязки, а новому запуску — вести игрока к другим конфликтам.
Поэтому мне интересны не ответы в духе «мне так атмосфернее». С визуальными предпочтениями спорить бессмысленно. Интересны конкретные наблюдения:
Пробовали ли вы заменять HTML-трекер одной строкой с теми же данными? Изменилось ли поведение модели?
Создаёт ли показатель предусмотренные автором развилки и последствия или просто заставляет модель чаще возвращаться к одной теме?
Не начинает ли эта тема вытеснять остальные арки?
Оправдывает ли результат место, которое блок занимает в контексте и ответе?
Если убрать оформление, но оставить данные, потеряет ли RP что-нибудь, кроме визуального эффекта?
Где для вас проходит граница между полезной сводкой, полноценной механикой и красивым костылём для модели?

у меня есть кое что интереснее

если вдруг задаетесь вопросом - а что там с Glaze в App Store, то посмотрите на то, сколько дней уже не выходит апдейт Tavo с плагинами

кто не понял, то App Store нам вряд-ли светит...

хихихи

решил сделать интерфейс для случайного выбора карточки, наверное ещё к провайдерам прикручу

Так. Бусинки. Свежий пресет на студию директ. Вроде уже рабочая схема. Плюс сделал реконсил Леджера, чтобы была отдельная проверка раз в н ходов и по кнопке.

Пока там худалл пытается родить бету флаттера, я хочу пояснить один момент. Вдруг кто-то ещё не до конца понял, что я вообще делал
Режим студии. Изначальная идея была в том, чтобы обвязать основную модель несколькими помощниками, которые подумают за нее, сколько надо слов, какой стиль, какая сцена, разделят обязанности, оставив основной модели исключительно написать текст, не захламляя его хтмл, ксс, скриптами и прочей мишурой, в виде блоков беременности. Итого студия имеет три фазы(ну, изначально так было задумано): преген, финальный агент и пост-клинер вызов. Идея здравая. Но есть подводные.
Первая итерация. Сначала я реально сделал шесть префазных агентов, которые разными запросами сочиняли для основной модели нужные параметры. Я знал, что студия по определению будет перерасходом токенов. Я готов был мириться с х2-2.5, но вышло в реальности х7-10. Поэтому полез смотреть Маринару и Проликса.
Вторая итерация. Выяснилось, что Маринара не гоняет 6 агентов. Она просит в одном вызове модель подумать над 6-7 задачами и описать их. Условно, то же самое: прочти текст, скажи, сколько слов надо в ответе, какой стиль, как продолжить и т.д. На выходе получилось заебись. Но только для средних моделей. В ходе тестов выяснилось, что сильным моделям преген фаза только мешает. Поэтому было принято решение сделать три режима студии: Легаси(шесть-семь преген контроллеров), Ассистед(два преген контроллера) и Директ(вообще без преген фазы). Тем самым, в директ режиме, мы отвязываем необходимость основной модели генерировать хтмл и прочую чушь, но оставляем весь пайплайн рассуждений на ней (ей так будет лучше). Но возник другой вопрос, а что действительно нужно сильной модели?
Третья итерация. Память. Вообще, я долго долбился с реализацией памяти. По сути, аналога наших меморибуков нет нигде, а они есть слишком прочный фундамент, покрывающий процентов 80-90 памяти. К тому моменту они уже умели скармливать модели только нужные куски информации из истории, плюс я добавил вызов нужных сообщений через эмбеддинги. И вроде звучит круто. Но встаёт вопрос: если мы уйдем от персонажа на тысячу сообщений, как модель вспомнит состояние отношений на момент ухода? Потому-что в карточке, допустим, у нас прописано, что персонаж холоден ко всем вокруг. И карточка у нас на постоянном инжекте. Т.е. через тысячу сообщений может случиться так, что ллм не сможет понять в каком состоянии наши отношения и вывалиться в холодность. Что делать с этим? Так и появился Studio Ledger.
Текущая итерация. Леджер. По сути это короткие записи состояний, которые инжектятся по ключам, короткими строками, которые ллм принимает, как основной контекст (да, я знаю, что есть card rewritter, но я пока ещё думаю над реализацией). Тем самым, получается, что в леджере хранится последнее состояние именного нпс. Если вдруг через тысячу сообщений, что мы не общались с нпс, ллм не сможет вывести из меморибуков и сырых сообщений состояние отношений - Леджер в этом поможет. Да, это ещё один вызов ллм. Но он не дорогой. И работает. Там есть нюанс того, что он способен заставить модель галлюцинировать, поэтому был реализован ещё и реконсиллер, который чистит Леджер от плохой информации, а также мерджит нужные записи, если Леджер не справился. Пока на тестах показывает себя неплохо. Но есть одно но.
Леджер всё ещё попадает в запрос одновременно с карточкой персонажа. И если там будет противоречивая инфа, все равно есть вероятность, что модель выберет карточку овер Леджера. Поэтому нужен в будущем card rewritter. Но с ним есть нюансы, над которыми я буду думать в ближайшем будущем.
Суммарно, если мы берём Легаси и вообще все фазы, мы получаем примерно 6 последовательных вызовов, из которых реально тяжёлых по токенам 1-2 вызова. В виду того, что я постоянно менял пресет под это дело, мои чаты в среднем не выходили за рамки 100 сообщений. Был один забег на тысячу сообщений, память показала себя хорошо, но пресет тогда был в дерьме.

Если что, сейчас в запрос финальному агенту попадает 40 сообщений, либо 60к контекста истории чата (не спрашивайте почему столько, и почему захардкожено. Но это есть причины, которые пока что останутся таковыми).
Короче. Зачем я вообще это пишу? Да как то мало инфы здесь в последнее время. Хочу чтобы вы знали, что мы реально работаем (Лично у меня нет слов 'у меня депрессия'. Есть только слова 'Я обещал. Значит сделаю')

У нас появился свой чатик со всем по Глазури - поддержка, багрепорты, предложения функций, обновления, общение, всё в одном месте

ждём, любим, целуем

https://t.me/glazeappcommunity

Glaze (beta 0.7.0)

СКАЧАТЬ С GITHUB

СТАТЬЯ С ОПИСАНИЕМ РЕЛИЗА

если вам лень читать статью, то TL;DR - новая архитектура, новые функции (порт JAR в глазурь, агенты, extBlocks, правки интерфейса), новые баги, версия на Айфон теперь не уступает остальным версиям

наш новый чат

пресет для студии

Что там по 0.7.0 и что дальше

1) в течении пары часов фикс чата для iOS и ПК появится на стабильной ветке вместе с 0.7.0a
2) вместе с этим появится несколько менее значительных багфиксов и правок QoL
3) параллельно с этим полируется интерфейс пресетов, студии и других экранов, вводятся остальные правки QoL и багфиксы
4) в ближайшем времени появится сайт, где будут публиковаться прессрелизы, будет удобное скачивание вместо GitHub и общая информация о Glaze

люблю целую оставайтесь на связи

упд: фикс завтра