Заметки на инженерных полях. Был в 2023-м году на конференции "Стачка" и делал там доклад про то, какие инструменты есть и должны быть у архитектора. С тех пор значительно продвинулся в понимании этого вопроса, и на основании недавно прочитанного для себя заметочка:

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

- Как распознать, что архитектурное решение отражает проблему, как субъективное восприятие заинтересованной стороной некоторого объективно существующего противоречия между желаемым и действительным/прогнозируемым действительным?
- Как распознать, что решение - оно вообще принято в работу и корректно понято?
- Как распознать, что решение правильно разработано?
- Как распознать, что решение правильно оценено на реализуемость?
- Как распознать, что реализация решения идёт по плану?
- Как распознать, что есть отклонения?
- Как распознать, что решение выполнено в достаточной мере, чтобы устранить исходную проблему, стимул для принятия решения?
- Как распознать, что реализованное решение действительно устранило исходную проблему/стимул?
- Как спланировать действия в будущем, на возникающие аналогичные проблемы/стимулы?

Заметки на полях. Сегодня имел беседу про то, что такое управление конфигурацией. Как всегда. Две поляны между собой перекидываются какахами, кто более прав, а кто Лев...

1. Управление конфигурацией продукта (мутная тема достаточно, и крутится вокруг маркетинговых понятий в основном. Что-то типа "фича", "сторя","бизнес-ценность"... В русском понятийном пространстве это вообще заклинания, так-то).

2. Управление конфигурацией системы. А это про тяжёлые методологические абстракции высокого уровня вложенности.

Вы уже догадались, кто и чем может управлять? Правильно! Кто что в руках держит, тот и управляет. Если программист щупает код - то для него вся эта история про "бизнес-ценность" - это про подписанный акт приёмки. Точка. Если акт подписали, морду не разбили, руки не отрубили - бизнес ценность есть! Доказывать, что то, что я делаю сейчас соответствует ожиданиям "бизнеса"? Так код напишу, он сам себя и докажет! Это ж математика! Если работает и акт подписан - значит всё ок, ничего никому доказывать не надо! (Л - Логика ушла поспать на определении транзитивности отношений. Это второй курс. Дискретная математика. Разделы логика предикатов. Если что.)

А на уровне "Продуктовых аналитиков" есть что угодно, затем трактуемое как угодно. Зачем формализовывать потребности? Достаточно же написать "должна быть безопасная фича". И "квалифицированная, мотивированная команда экспертов".... У нас же все кто в ИТ высококвалифицированные, мотивированные команды профессионалов, да?)
В итоге имеем "аналитиков", которые сидят за плечами у "программистов" и говорят:

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

И когда Василич после показа софта с кнопкой подписывает акт, а потом спрашивает: - Куда бабки дели, ироды!? - то зовут сначала аналитика, который зовёт программиста, который говорит: - Василич, ну чо ты начинаешь, акт же подписали! И вроде все довольны, но что-то говной воняет...

Поэтому пока впечатление такое:

Искусственный интеллект не сможет победить естественный. То, что не существует, не сможет победить то, что стремится исчезнуть)

#идейное #управление_конфигурацией

Заметки на инженерных полях. После длительного перерыва пора открывать всякое. Тут в т.ч. мысли и лабораторный журнал.

Сегодня наконец-то попробовал написать приложение при помощи агента в Windsurf. Писал простенький RAG-сервис для локального контекста, чтобы можно было подкидывать себе в контекст всякое хранящееся в Markdown-ах. Хочу попробовать разработку требований организовать на этой теме.

Написал:

1. Функционал
2. Тесты
3. Доку
4. Руководства по кодированию.
5. Описание типовых процессов разработки и команд управления проектом
6. make-файлы

Впечатления:

1. Правильно заданный контекст в самом начале - решает очень много.
2. Энтропия действительно накапливается.
3. Продакшен решение получить можно. Но очень сложно.

На всё про всё - 3 тыщи рублей и токенов ещё осталось.

Ну и да, нужно очень хорошо понимать, что разработчик хочет сделать.

Заметки на полях. Образовательное.

Сегодня со ScrumTrek провёл мастер-класс по автоматизации при помощи LLM-ок некоторых простых действий в процессе разработки софта.

Даже доволен результатом по большей части.

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

1. Промпты можно компилировать в к-промпты. Компактные промпты. Это вообще огромный буст к качеству. И более того, скорее всего часть промптов нужно хранить эмбеддингами.

2. Можно говорить о новой специальности: инженер-конструктор контекста БЯМ. Со своей спецификой

3. Работа с генеративными моделями на данный момент - мета-навык. Даже пачка мета-навыков. Что незаурядной подготовки, образованности и дисциплины.

4. Есть гипотеза, что как продукт может потребоваться библиотека к-промптов в формате RAG-сервиса.

#аишечка #архитектура #образование

Заметки на полях. Обратил внимание, что:

1. Роль дневниковых форм рефлексии возрастает чуть ли не по экспоненте. Особенно с учётом всяких агентов.

Кажется, что наставничество принимает новые формы, и в этом есть возможность создать дополнительную ценность.

2. Лично у меня повысилась значимость способности БЫСТРО переключаться между контекстами.

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

#аишечка #образование #трудоспособность

Заметки на полях. Инженерное ИИшное. Сейчас активно перерабатываю своё рабочее пространство. Какие вещи сразу бросаются в глаза:

1. Один из ключевых современных продуктов, которые сразу хочется делать - это MCP-серверы для интеграции с различными средами. Промпты это конечно интересно, но наборы тулов в MCP - это инфраструктура. Она - основа всего.

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

3. Отслеживание качества контекста, его замусоренность и релевантность контекста - это топ метрика для контроля производительности. Осталось понять, как её считать. И высказывание Attention is all you need - это не только, и не столько сказано в отношении моделей. Это в принципе новый принцип жизни. Поэтому заведу себе рубрику про контроль внимания. На что оно направлено, какими свойствами обладает и всякое такое. Человечество наверняка накопало достаточно много.

#аишечка #внимание #инженерия

Заметки на полях. Про внимание. Внезапно (sic!) оказывается, что для продуктивного достижения целей необходимо продуктивно прикладывать внимание к её достижению ) А теперь немного набросаю, что таковому мешает. Сначала банальщина, потом небольшой вывод.

1. Состояние потока - это такое состояние, когда внимание полностью захвачено решаемой задачей.
2. Самая дорогая операция - переключение между задачами в разных контекстах.
3. Незавершённые задачи жрут внимание. Буквально. Техдолг жрёт внимание команды.
4. Мессенджеры и прочая электронная коммуникация жрёт внимание. И переключает контексты.
5. Люди в окружении либо требуют переключения контекста внимания, либо поддерживают решаемую здесь и сейчас задачу.

Экономика внимания - это не то, что за чьё-то внимание будут платить деньги. Это буквально "ведение хозяйственной деятельности в области внимания". Вовлечение в свой контур внимания - это экономический акт в таком понятийном пространстве. А уже дальше, из этого всего следуют прочие штуки, типа зарабатывания денег, авторитета и прочего. Бросить взгляд на рекламный щит, номер автомобиля, чью-то сексуальную фигуру - это акты хозяйственной деятельности.

А вот отрефлексировав своё распределение внимания можно понять кто ему хозяин и кто им управляет.

#внимание

Заметки на полях. АИшное. В данный момент как некоторые мои коллеги отмечают, существует кризис инженерной культуры. Например известное DDD в англоязычной интерпретации для русскоязычных девопсов звучит как:
- DAVAI DAVAI DEPLOY (ссылка не на оригинал, но тож пойдёт).

С приходом штук типа Claude code, Windsurf, OpenClaw и подобных, на этом фоне достаточно оперативно, можно считать, что появилась "специальность" Машинист(ка) LLM. Сергей Баранов сформулировал это так:

Почему «Машинист LLM» — метко
Аналогия с машинистом или оператором ПТУ-шного толка на самом деле очень точная по нескольким причинам:
• Машинист управляет мощной машиной, но не проектирует её — он знает кнопки, рычаги и протоколы. Ровно то же самое делает промпт-инженер с LLM[skillfactory]
• Оператор — ещё честнее: в официальных реестрах профессий в России уже есть “оператор ЭВМ”, и “Оператор LLM” органично встаёт в этот ряд[sberbusiness]
• Низкий порог входа (3–9 месяцев обучения)  как раз соответствует ПТУ-шному формату, а не полноценному инженерному образованию

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

- Чем круче джип, тем дальше идти за трактором.

* Сервис twitter.com (ныне x.com - заблокирован на территории РФ по требованию генпрокуратуры как неисполняющий требования законодательства РФ)

#аишечка #инженерия #образование

Заметки на полях. Аишечное.
Приехал тут ко мне на днях Halo Strix-мини ПК. Я накатил не него бету убунты 26.04 и начал эксперименты по запуску домашнего сервера моделей.
Конфиг показывает 128 ГБ GPU RAM (Да, это не совсем честные GPU RAM, и на самые быстрые, но работает).

1. Модели запускаются =) Уже хорошо. Производительность на средних квантованных (Q6,Q8) моделях показывает порядка 10-20 токенов в секунду.
2. Потребление в 300 Ватт в час при активной нагрузке - это вполне годно.
3. Шумит приемлемо, примерно как фен в ванной когда там волосы сушат за дверью, если рядом стоять. Но спать под него нельзя конечно.
4. Работает через вайфай. Буквально висит на одной розетке, и доступен дома как сервис.

Какие работы на нём планирую выстроить:

1. Агентный фреймворк для решения всякой повседневщины.
2. Частично автоматизировать свои рабочие процессы.

Какие первичные выводы:

1. Если планируем учиться использовать ИИшку - такой инструмент дома обязателен.
2. Компетенций для установки сейчас достаточно почти у всех. Внешняя поддержка от Perplexity-Google - вполне решает вопрос "Я не умею". Но голову конечно надо прикладывать.
3. Нужно понимать как будет окупать себя эта штука. Какие конкретно проблемы она будет помогать решать.

#инженерия #аишечка

Ещё немного заметок на полях про организацию рабочего пространства.

1. Создание собственного рабочего пространства занимает теперь часы, а не дни изучения документации на инструменты. Если вы знаете как они работают - это ускоряет вас ещё в пару раз.
2. Рабочее место любого специалиста в ближайшие три-пять лет - это что-то вроде собираемого под заказ обвеса нескольких конкретных моделей. Например вы - агроном/слесарь/водопроводчик/водитель... У вас есть конкретная работа. Вот уже сейчас выделяя 2-3 часа в день на модернизацию своего рабочего окружения можно через год уделать на порядок всех, кто этим НЕ будет заниматься. Потому что цикл принятия решений у вас будет быстрее точнее на порядки чем у тех, к ого этого не будет. Так что на это, если хотим просто выжить, придётся выделить время. (Иначе нас всех убьют нахуй-)
3. Есть практическая задача: конкретным предметникам давать в руки рабочие инструменты на базе ИИшек.
4. Локальный инференс - понятен, работа в оффлайне и чебурнете - это наше всё на ближайшую жизнь. Придётся выстраивать это дело, как ни уклоняйся.
4. Первое, что нужно фиксировать и на что обращать внимание - это агенты помогающие личной эффективности. Которые помогут выйти из состояния пожара.
5. Всему этому благоденствию жутко мешает состояние вечного "пожара" и гонки за "мне тут срочно надо". А это война за контроль внимания между кусками нашего мозга.

Движение по агентному фреймворку:

1. Стало понятно, что набор спек "напиши мне MCP сервер для ..." - это то, что будут просить завтра.
2. Автоматизация рабочих процессов пошла. Хорошими промптами и переключением между моделями получилось выстроить чась пайплайна разработки презентаций для бауманки.
3. OpenClaw - это не выход. Стоит посмотреть на такие среды разработки как Codeium, Codex, Claude Code и всё это встроить в MS VS Code. Несколько агентных среды над одним репозиторием - это вполне рабочая тема.
4. Написал MCP-сервер для локальной генерации эскизов слайдов. Буду думаь как это довести до ума, чтоб оно само рисовалось по большей части.

#аишечка #инженерия #внимание

Заметки на полях. ИИшное.

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

1. Вайбкодить тонну MCP-сервисов которые будут подтягивать данные, генерировать типовые артефакты. Поскольку готовых решений практически нет. Или они стоят невменозных денег. Или надо вступать в клуб весёлых и находчивых, чтобы получить к ним доступ.
2. Разобрать и отревьюить тонну промптов, которые будут последовательно выполняться.
3. Регулярно обновлять знания о том, как выполняется разработка в данной среде.

При этом чтобы среда "более-менее" работала понадобится:

1. Операционный каркас. Набор промптов описывающих ролевую деятельность.
2. Соглашения о правилах документирования проекта
3. Набор типовых вызовов skills/workflows
4. Набор настроек среды разработки
5. Настроенная инфраструктура CiCd. Сразу.

За это время сделал себе домашний генератор кастомных картинок на stable-diffusion. Генератор работает по api и будет встроен в MCP-сервер для создания слайдов для презентаций.

На что обращать внимание:

1. Проект всегда будет деградировать со временем. Это неизбежно. Необходимо делать пайплайны очистки устаревшего кода. Агенты плохо понимают и удаляют легаси и депрекейты.
2. Размер пакета задач - критически важен. Можно подключить и нужно подключать внешнюю систему планирования для контроля задач и хранения описаний. На ОЧЕНЬ маленьких проектах работают MD-шки. Так что трекеры задач похоже преобразуются, но не умрут). 1-2 задачи за пакет - это максимум. Более того, dev-qa-archreview-ops-uat по одной таске на разработку - это 5 диалогов в среде разработки.

Пока всё достаточно тривиально.
#инженерия #аишечка

Заметки на полях. Инженерно-образовательное.

В ближайшее время буду пилить небольшой кластер АЛЬТ Виртуализации на 750+ ядер и 8 ТБ оперативы. Посмотрим как сможет завестись и что будет с сетями (что особо интересно). Площадка - МГТУ им. Баумана. (Да, я в курсе, что это Proxmox в базе).

- Пока на площадке собрал железо, подвели питание и выполнил основную коммутацию оптики и меди.
- Техпроект у меня готов, и Базальт достаточно дружелюбно отнёсся к просьбе проконсультировать по технической части, поскольку есть контракты и контакты. Обещают 3 месяца регулярно отвечать на вопросы в рамках "тех.пресейла".
- А ещё разработчики Базальта оказывается делают вебинары по средам на тему поддержки своего продукта и, говорят, что там можно позадавать вопросов. Вебинары вроде бы даже открытые, или по договорённости. Схожу к ним на следующей неделе, поспрошаю.

Ну и заодно проверим как эта штука интегрируется во всякое современное SSO, как там с Terraform-провайдерами и их функциями, что с пулами ресурсов, QoS-ом сетей и подобной мультитенантностью. Что там можно, что не стоит делать и вот вот это всё.

Для сравнения рядом стоит подобный кластер BASIS от РТК. Будет занятно сравнить эти два продукта в нашем случае.

Периодически буду накидывать тут всякого по теме)

#инженерия #цод #proxmox #альтвиртуализация

Заметки на полях. Инженерное, ИИ-шное.

Что сделано за последние пару дней:

1. Протестировал локальные модели LLM (Qwen3.5 27B в квантах от Unsloth Q6,Q8 KXL) на задачах генерации образовательных материалов.
2. Устроил рабочую среду с VS Code + Continue для разработки образовательных материалов у себя дома на Minisforum MS-S1 MAX (Ubuntu 26.04 с ядром 7.0.0-10) и интегрировал её в свой рабочий проект.

Какие первичные выводы:

1. На машинку где запускаем модели надо поднимать движок контейнеризации. Однозначно. Без него можно упахаться разбирать что и как в каком образе запущено. Ну и винды там точно не должно быть. 100%.
2. Точно стоит перед моделями делать некоторый API-gateway для распеделения запросов и оптимизации вызовов самих моделей. lite-llm вполне тянет на такую историю.
3. От оllama я пока решил отказаться, потому, что уменя из коробки оно вообще не полетело.
4. Однозначно сразу надо поднимать домашний RAG. Потому как без подключения RAG вся эта история глубоко бесполезна.
5. Топовые dense модели идут прям тяжело, 6-10 токенов в секунду. Может быть поиграю ещё с параметрами производительности или моделями, но скорость качество конечно для них - так себе. Возможно будет для некоторых задач оправдан переход на sparce-модели.
6. В агентных системах совершенно точно надо разделять задачи OODA/PDCA циклов как отдельные контексты.

Что по результатам:

1. Задания на практические работы эта пишутся практически сами, пока я себе завариваю чай. Причём неплохо так. С учётом того, что у меня подключён gitlab как источник данных и документации по рабочей программе - вообще топово. Если ускорить раза в 4 генерацию будет вообще огонь. Но для этого надо конечно другой сетап железа.
2. Ревью лекцию и ошибок выполняет вполне хорошо, с учётом того, что умеет шарить по коду учебного проекта. Хорошо держит контекст

Что дальше:

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

Ещё немного заметок:

1. Пока народ люто рекомендует что-то вроде R7000x2, или 4090х2. Я тоже смотрю в подобную сторону, но количество денег на этот эксперимент необходимое конечно удручает.
2. Внедрять агентов в свою работу на своей организации прям пора. Если что-то можно описать текстом - то этот текст стоит не писать самостоятельно.

Заметки на полях. Инженерно-образовательное.

Что сделано за пару дней:

1. Поднял пачку тулов для своего пайплайна, чтобы агент мог хорошо редактировать учебные материы в репе, коммитить, пушить и вот это всё.
2. Проверил и подобрал промпты для Qwen3.5 35B Q8 для редактирования заданий на практические работы.
3. Попробовал поднять docling для парсера документов в контекст.

Наблюдения:

1. Одна из самых больших проблем LLM-ок - вызовы тулов. Чат-шаблоны ломаются у Qwen-а в его родном способе запуска прям частенько.
2. Скорость генерации на моём Minisforum-е - 17-20 токенов в секунду на текущей обвязке. Загружаются активно 2 физических ядра, 4 потока. Похоже сильно упираюсь в скорость памяти.
3. В принципе для типовой задачи достаточно 130к контекста в 8-м кванте. Можно попробовать до 100к задушить его и
4. Заготовки которые раньше казались излишними (типа тасктрекера для разработки материалов по программе, ведение базы в Confluence и т.п.) оказались просто спасительными в момент, когда нужна хорошая генерация на конфиденциальных данных.

Что по результатам:

1. Редактирование шаблонных документов - просто спасение. Если изначально есть шаблоны документов, описание + понимание того, что и как там должно быть написано - работает достаточно хорошо.
2. Поиск и обогащение контекста стандартыми RAG-ами (без разницы, векторными или нет) уже достаточно хорошо, чтобы решать большинство типовых задач.
3. Встройка docling как MCP-сервера - весьма нетривиальное решение, поскольку эта ... штука, работает только с локальными файлами. Да, можно её ставить как stdio MCP, но это игрушка для технарей. Если хотим более-менее промышленно применимое и масштабируемое решение конечно надо что-то более зрелое.

Что дальше:

1. Нужно думать над мультиагентным пайплайном. Поскольку в рамках одной более менее реальной задачи совершенно точно должен быть оркестратор + разные агенты, с разным набором тулов.
2. Буду думать над GRAPH RAG по моим данным. Всё таки 300 мегабайт учебных материалов - это много. И векторный поиск с хорошим семантическим движком должны будут поднять на слабой модели точность генерации достаточно сильно.
3. Попробую решить ещё несколько классов задач.
4. Пора переходить к автоматическому "тасканию" тасок по доске канбана моей.

#аишечка #инженерия #образование

Заметки на полях. Инженерно ИИшное. Забавное.

Я тут попробовал прикинуться моделью для модели. Указал в запросе, что я ИИ, который имитирует человека.

Точность рассуждений повысилась примерно на 20-30%%

Количество расходуемых токенов снизилось раза в 3.
Лишний текст в ответах исчез как факт.