Поставил Q4_K_M. Если половину в RAM Offload угнать, то как-то работает на 16 GB VRAM с контекстом 16384. За счёт размышлений модели это всё ещё медленнее. Пока не уверен, найдётся ли у меня ниша для применения этой модели.

Тоже сижу на Qwen 2.5 (14B), потому что шустро и весьма эффективно. Можно и 32B, но 16 GB VRAM уже поджимают. Какого-то огромного прироста качества в кодинге в сравнении с обычным Qwen 2.5 с переходом на R1 Distill-Qwen 14B не обнаружил. Моделька часто перепрыгивает на другие языки (китайский, испанский, какие-то ещё неизвестные мне), путается в собственных длинных рассуждениях даже при temp=0. Попробую потом 32B, может быть, будет стабильнее и полезнее, или попробую формировать запросы только на английском. А то, блин, я уже начал запоминать значение некоторых иероглифов :D

Это я вижу. А проблема-то в чём?

 Решают одну проблему, но генерят новые

А именно?

Это просто переложение https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_and_Do_It_Well . Необязательно каждый модуль является частью чего-то большего: в горизонтальных структурах, вроде микросервисов, у нас большинство сервисов имеет равный ранг, ни один не входит в другой, и, тем не менее, каждый имеет ограниченную зону ответственности, которую должен обслуживать хорошо. Естественно, зона ответственности описывается на естественном языке в терминах целевой области знания, формально определять её было бы странно.
Условно, даже в монолитной архитектуре модуль работы с БД не должен хорошо уметь форматировать дату или записывать логи, для этого есть другие модули, которые он может использовать через ограниченный интерфейс.

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

Всегда воспринимал речи Uncle Bob как некую сказку, жвачку для ума, не более. У каждого есть какое-то своё понимание хорошей архитектуры, и представление Боба -- не истина в последней инстанции. Ради интереса попросил Claude AI накидать архитектурные принципы, которыми я руководствуюсь в своём коде, на основе краткой беседы с ним:

## 1. Фундаментальные принципы

### 1.1. Принцип Управляемой Сложности
- Система должна быть достаточно простой для понимания отдельным разработчиком
- Сложность должна соответствовать решаемой задаче, любое усложнение системы должно иметь явное обоснование
- При выборе между двумя эффективными решениями предпочтение отдается более простому

### 1.2. Принцип Модульности
- Система разделяется на четко определенные, слабо связанные модули
- Каждый модуль имеет единую ответственность
- Взаимодействие между модулями происходит через четко определенные интерфейсы
- Внутренняя реализация модуля может меняться без влияния на другие части системы

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

## 2. Практические принципы реализации

### 2.1. Организация кода
- Структура проекта должна отражать предметную область, связанные компоненты располагаются рядом
- Код организуется вокруг бизнес-концепций, а не технических деталей реализации
- Используется последовательная система именования

### 2.2. Управление зависимостями
- Зависимости должны быть явными и минимальными. Циклические зависимости не поощряются
- Модули верхнего уровня не должны зависеть от деталей реализации
- Внешние зависимости изолируются через адаптеры, либо их использование минимизируется

### 2.3. Работа с данными
- Структуры данных должны быть простыми и понятными
- Сложные структуры данных вводятся только при явной необходимости
- Потоки данных в системе должны быть прозрачными и отслеживаемыми
- Доменные объекты, обогащенные бизнес-логикой структуры данных, специфичные для конкретного домена, хранятся вместе с бизнес-логикой

## 3. Принципы эволюции системы

### 3.1. Управление изменениями
- Система должна быть готова к изменениям требований
- Изменения локализуются в минимальном количестве модулей
- Новая функциональность добавляется через расширение, а не модификацию

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

### 3.3. Документация и обмен знаниями
- Неочевидные архитектурные решения всегда документируются вместе с обоснованием их полезности
- Поддерживается актуальная документация по API и интеграциям
- Знания о системе распределяются между членами команды

## 4. Принципы качества

### 4.1. Тестируемость
- Архитектура должна упрощать написание тестов
- Модули проектируются с учетом возможности их изолированного тестирования
- Критические пути в системе имеют максимальное покрытие тестами

### 4.2. Самотестирование кода
- Ключевые инварианты системы проверяются через assertions
- Проверки инвариантов включают:
  - Входные параметры функций и методов
  - Выходные значения критически важных операций
  - Состояние объектов после важных изменений
  - Корректность форматов данных
- Assertions используются для раннего обнаружения проблем:
  - Нарушений бизнес-правил
  - Некорректных состояний системы
  - Нарушений контрактов между компонентами
- Самотестирование не заменяет модульные тесты, а дополняет их
- В production-окружении assertions могут быть отключены для оптимизации производительности

### 4.3. Производительность
- Производительность учитывается на этапе проектирования
- Оптимизации вводятся на основе измерений, а не предположений
- Система масштабируется в критических направлениях
- Производительность не должна ухудшать читаемость кода без веской причины

### 4.4. Безопасность
- Безопасность встраивается в архитектуру изначально
- Все внешние входы в систему проходят валидацию
- Чувствительные данные изолируются и защищаются
- Система устойчива к типовым атакам и уязвимостям

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

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

Много Вы видели в обучающем наборе "Я не знаю"? Кто вообще в интернете говорит "я не знаю"? В любой статье, научной или публицистической в любом популярном издании все всё знают. На форумах все всё знают лучше других.
Да и, помимо этого, у нас за незнание, скорее всего, отвечает отдельная структура, с помощью которой мы знаем, что мы чего-то не знаем. У LLM такой структуры нет, она оперирует нормализованными вероятностями, у неё нет данных об абсолютной вероятности события в реальном мире. Цепочка размышлений и "цензор" в o3, выбирающий лучшую цепочку, частично должны нивелировать эту проблему за счёт того, что ответ оценивает отдельный модуль, который можно обучить быть более придирчивым к источникам знаний, но вряд ли решит её полностью.

 каменщик, возводивший Аушвиц причастен к геноциду или нет?

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

Мера ответственности солдата существенно выше, потому как он имеет и оружие, и непосредственно может нанести ущерб. Мера ответственности командования и идеологов ещё выше, потому что они построили такую систему, в которой появился Аушвиц.

Так что каменщик каменщику рознь. Поэтому по итогам Второй мировой это решал не суд Линча, а трибуналы, которые принимали во внимание совокупность факторов.

Если я усну и проснусь через сто лет и меня спросят, что сейчас происходит в России, я отвечу: "В РФ планируют запретить".

Я уже ответил: сложность меньше тем, что вы контролируете каждое ветвление, а не ловите всевозможные ошибки из блока.

Про GC лучше даже не заикаться в контексте исключений. Исключения -- это дорого, там буквально для throw создаётся целый объект исключения, и производительность там будет проседать значительно, если использовать это под высокой нагрузкой. Куда сильнее, чем создание какого-то там массива на два элемента.

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

Если это оно, то даже не планируют. Draft proposal, вместо которого рассматривают другие альтернативы. Так что сугубо разминка для ума.

Во-первых, у вас в версии с ?= три разных обработчика ошибок, а не один, и try-catch версия была бы сильно длиннее. Во-вторых, снижение вложенности полезно тем, что вы как программист при отладке можете просматривать меньший объём кода: вместо одного большого блоба, где "что-то пошло не так" у вас явная последовательность действий, в которой разваливается конкретное ветвление. Если же, наоборот, мы упростим обработчики до return false, то будет очень компактно, хотя и менее информативно.

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

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

Это составляет меньшую несущественную часть моих расходов.

Покупал GPU, не заметил, что RTX 4080 для меня дешевле, чем для швейцарца. С авто тоже как-то в Европе и США можно получше купить за те же деньги. Если определение "богатства" -- это не сдохнуть с голоду, то ок, допускаю.

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

Мне тут видится нарушение довольно базовых физических законов.

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