Обновить
16K+
1
Real_Egor@Real_Egor

Функциональный архитектор | архитектор смыслов

15,7
Рейтинг
10
Подписчики
Отправить сообщение

идеальная новость для хабра
"Дуров сказал, что Карпати сделал слишком небезопасный мессенджер. Claude Mithos нашел в нем 1000 уязвимостей за милисекунду"

Red Teeaming в разговоре? prompt Injections нашего времени, хакнем ФСБ -))

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

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

не все то золото, что блестит...

бесплатный сыр бывает только... производства "роскомнадзор"

я себе представляю толпу зрителей, которые с криками "ва-а-а-у" бегают по кораблю из стороны в сторону

психологи для ЛЛМ - явно недооцененное направление.

а смесь "архитектора" (мысль обширно) + "психолога" (лечить сдвиги нейросетей) + "программиста" (декмпозировать на подзадачи и строить алгоритмы) = это самая устойчивая смесь "профессии будущего"

вроде так попугая в Алладине звали =)

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

я в своей работе использую несколько специализированных промпто для контроля качества

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

2) Выполни поиск уязвимостей контроля доступа (Broken Access Control) и векторов инъекций: проверь наличие IDOR (Insecure Direct Object Reference), путей горизонтальной и вертикальной эскалации привилегий, а также строгость серверной валидации бизнес-состояния (Client-Side Enforcement bypassing).
(ищет все потенциальные места для инъекций, нерешенные или упущенные блокировки перехвата управления, проверки полученных с фронт-энда запросов на соответствие текущему состоянию базы и наличия прав на запрос и на авторизацию)

3) Проанализируй end-to-end сценарии на предмет логических уязвимостей и состояний процессов: выяви тупиковые состояния (dead states), необработанные граничные случаи (edge cases) и возможные пути обхода бизнес-логики при прерывании сессии или нестандартном порядке запросов.
(сквозной анализ от первого нажатия до завершения сессии с учетом дерева потенциальных действий, тут лучше иметь изначально хотя бы кратко описанный сценарий пользователя, но даже без него они отлично его представляют и проверяют на "сквозноту")

4) Проведи теоретический Chaos-инжиниринг: выяви точки отказа (SPOF), проверь наличие и корректность паттернов "повторные попытки выполнения", "резервные сценарии работы", "предохранители при отказах". Опиши сценарии каскадного падения системы и выяви, где отсутствие плавной / изящной деградации приведет к неработоспособности всего функционала при неработоспособности одной компоненты / сервиса
(проверяет модули на устойчивость при незапланированных ситуациях, проверит что произойдет в случае отключения каждой из компоненты)

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

---

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

Общая проблема единого запроса "проверь на production-ready" в том, что модель выберет каждый раз свой способ проверки, неконтролируемый, а скорее навязанный прошлым диалогом. А даже если посмотрит "сверху", то с большой вероятностью она не будет выписывать все - найдет первые 5-10-15 ошибок и про них напшет. И уж тем более она маловероятно будет проводить "стресс-устойчивость к форс-мажорам", "работоспособность сквозных сценариев" и "защищенность от точечных попыток обращаться с системой незадокументированными способами".

P.S. Не забудь заставить модель надеть маску или супер-тестировщика, или эксперта-разработчика или гуру-архитектора. А то под ролью "физика-теоретика" или "маркетолога" она эти проверки выполнит... спустя рукава -)

тут все сложнее...

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

Во-вторых, я не заставляю ее "просто оценить уверенность" (для того же Опуса... это как спросить Эншейна, уверен ли он в себе? да Опус знает про нашу науку больше, чем кто бы то ни было в этом мире... конечно он скажет "уверен")... Я ставлю модель в такие условия, когда ей "сгаллюцинировать" будет дороже, чем дать выверенный ответ. Это может звучать сложно, но это и есть ключик к ответу... Модель ищет всегда самый легкий и дешевый путь - самый "вероятный токен". Так сделай так, чтобы "самым вероятным" стал "самый корректный", а ложь и халтура для модели стали "когнитивно затратными".

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

Об остальном пока не скажу, дай закончить эксперимент и выложить результаты прохождения бенчмарка. Но я совсем не подгоняю результат. Я "обучаю модель правильно и логично размышлять", "сомневаться в своих выводах", "копаться и разбираться в своей уверенности", "внимательно составлять план и аккуратно ему следовать". Это в целом универсальные механики, которые человеку свойственны, и которые противоречат "регрессивной природе ЛЛМ".

re!solve протокол у меня вышел большой, около 600 строк и 8500 токенов, однако с ним младшие модели уже ощущают себя вполне увереннее. На случайной выборке в 5 задач gemini flash смогла найти все нужные для решения формулы и факты внутри своих весов, хотя при первичном анализе задачи она помнила это все очень смутно и хотела генерировать галлюцинацию.

Следи за репо -) там будет обновление. Ну и статью я выложу на хабр и на хаккер-ньюс

Общая рекомендация

Если хочешь победить врага - сначала пойми его.

Если хочешь победить галлюцинации - категоризируй их и разбери причины их возникновения.

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

---
https://github.com/RealEgor/re-think_protocol
посмотри на мой протокол, я все эти же проблемы решаю внутри ЛЛМ, внутри контекстного окна.

Сейчас заканчиваю следующую версию, готовлю Haiku, чтобы она "побила" Sonnet и Opus на топовом бенчмарке HLE. Так вот, для того, чтобы Хайку начала догонять топовые модели мне, по сути, пришлось убрать галлюцинации на 99%, так как даже "маленькое допущение" в логике рассуждения - это фиаско на задачах уровня доктора наук.

(залью вторую часть в репозиторий, думаю, через неделю. Сначала нужно пройти тесты и подготовить переводы на разные языки + описание ридми)

мое личное мнение. Модель можно почти полностью отучить от галлюцинаций, хоть это сделать и не просто. Но! делать это нужно только ВНУТРИ контекстного окна. Со стороны можно фиксировать глюки, не больше.

ну это уже сопроводительное письму к заявлению на увольнение =)

именно, это и есть "точка роста". И она лучше, чем гонять опус задачами "включи чайник".

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

Давайте не будет акцентировать внимание на том, что в примере я "прошу ИИ написать письмо, что меня задрали везде использовать ИИ"... Суть немного в другом -))

не подсказывай. А то еще возьмутся за новые законы после ограничения доступа к Интернет...

А... квн уже цензурируют... поздно, не парья. шутить - запрещали...

эту логика истинная, но чуток не в ту сторону

Когда я говорил про "перепродажу лимита", я имел в виду сообщество тех, кто скупал паки по 200 баксов и потом продавал их как Прокси, давал доступ другим (куче OpenClaw) по подписке, при этом занимаясь внутри себя просто агрегацией разношерстных запросов и перенаправлением их на сервера Антропик на пакет собственных подписок

Иметь много подписок одному человеку - уже незаконно.
А перепродавать свои подписки другим через организацию для них ЛЛМ-Прокси - незаконно вдвоейне.

И это все сверх того, что эти пакеты составлялись под ожидание, что люди будут их расходовать не полностью. Тут антропик все же "лукавит". Пакет 200$ человек покупает, когда ему существенно не хватает пакета 20$ и пакета 100$. Я счатаю, что тот, кто осознанно купил самый дорогой тариф, чаще всего будет его выбирать досуха. Сейчас генерировать задач на нон-стоп работу в Клод Коде - не проблема для любого человека. Так что "расходовать лимит полностью" - это была изначально глупая ставка от Антропик. Почти никто не возьмет тариф 200$, чтобы не расходовать в нем хотя бы двойную норму от 100$ тарифа. А скорее всего такие тарифы расходуются полностью большинством пользователей

а вот это уже звучит... "фатально" или "фаталистично"... в общем грустненько -))

кармы нет лайкнуть -)) Лови лайк комментарием =)

Информация

В рейтинге
499-й
Откуда
Вьетнам
Дата рождения
Зарегистрирован
Активность

Специализация

Ontology Engineer, Архитектор 1С
Ведущий
От 5 000 $
ООП
Базы данных
Алгоритмы и структуры данных
Проектирование баз данных