Cмысл reasoning как раз в том, что модель генерирует дополнительные промежуточные токены, которые затем используются для генерации итогового ответа. Это не просто «болтовня», а дополнительный вычислительный бюджет, который во многих задачах заметно повышает точность.
Если поставить thinking=false, модель действительно отвечает быстрее и короче, и для задачи вроде «вытащи поля из картинки и верни JSON» это вполне может быть оптимальным режимом. Но это не значит, что reasoning бесполезен в целом.
Я бы рекомендовал посмотреть на бенчмарки одной и той же модели при разных reasoning budgets / thinking levels. На многих моделях, особенно небольших, разница в качестве бывает очень большой. По сути, ты здесь меняешь latency и стоимость на качество ответа.
Векторное хранилище — чёрный ящик. Сотрудник не может посмотреть, что именно агент «запомнил»: эмбеддинги нечитаемы, а восстановить исходный текст по вектору нельзя. Для корпоративного сегмента это блокер: compliance требует, чтобы человек мог в любой момент увидеть, какие данные о нём и о проекте хранятся.
Мне кажется, аргумент против векторных БД из-за прозрачности и compliance здесь немного искусственный. Да, сам embedding человек прочитать не может и восстановить из него исходный текст тоже нельзя. Но ведь никто не обязывает хранить в векторной БД только embedding. Обычно рядом с вектором хранится исходный текст чанка, metadata, scope, source и т. д. Тогда embedding фактически является просто индексом для поиска по этому тексту.
Поверх этого вполне можно сделать обычный UI, где пользователь видит, что именно находится в памяти, может отредактировать или удалить конкретную запись. На изменение текста вешается переиндексация — старый embedding удаляется/обновляется, новый строится из актуального текста. Туда же достаточно естественно добавляются RBAC, audit log, versioning и остальные требования корпоративного контура.
То есть проблемы «пользователь не может посмотреть и исправить то, что агент запомнил» — это скорее свойство конкретной реализации memory layer, а не принципиальное ограничение векторных БД.
При этом сам выбор Markdown/S3 для вашего сценария мне понятен: если память небольшая и вы всё равно целиком инжектите её в контекст, векторный поиск действительно может быть просто лишней сложностью. Но я бы тогда сформулировал аргумент именно так: «для нашего объёма и access pattern vector DB не даёт достаточной пользы, чтобы оправдать дополнительную инфраструктуру», а не как ограничение по прозрачности/compliance.
«Потолки по-прежнему различаются на треть, 236 у Gemma против 178 у лучшего кванта Qwen».
Я тоже тестировал именно эти модели и столкнулся с тем, что tok/s здесь желательно сравнивать вместе с символами/с: у моделей разные токенизаторы и разный средний объём текста в одном токене. В моих тестах TTFT у Qwen часто был сопоставимым или даже ниже, хотя по tok/s он стабильно проигрывал. Поэтому разница в реальной скорости выдачи текста и пользовательской задержке может быть заметно меньше, чем следует из сравнения только токенов в секунду.
Что-то никто в комментах не понимает кажется для чего xray. Сам раньше просто прокидывал порты по ssh. Последнее время такой способ был не стабильный. Было ощущение что ssh разрывает провайдер. Тоже думал через xray гонять, но показалось слишком грамоздко. В итоге сдался и купил белый айпи за 100 рублей.
Мне кажется РКН сам может насоздавать липовых заблокированных доменов, на которых будет ловить такие впн. И этот список может быть динамическим. Пока что вижу спасение в per-app тунелировании.
И опять же. Если исходить из выводов статьи, то сплит по доменам не сработает.
Как будто оправдывать fine tuning, если нужна работать в автономном режиме, не аргумент. ведь раг систему можно скачать на edge устройство. И синхронизировать при доступе в интернет
Cмысл reasoning как раз в том, что модель генерирует дополнительные промежуточные токены, которые затем используются для генерации итогового ответа. Это не просто «болтовня», а дополнительный вычислительный бюджет, который во многих задачах заметно повышает точность.
Если поставить
thinking=false, модель действительно отвечает быстрее и короче, и для задачи вроде «вытащи поля из картинки и верни JSON» это вполне может быть оптимальным режимом. Но это не значит, что reasoning бесполезен в целом.Я бы рекомендовал посмотреть на бенчмарки одной и той же модели при разных reasoning budgets / thinking levels. На многих моделях, особенно небольших, разница в качестве бывает очень большой. По сути, ты здесь меняешь latency и стоимость на качество ответа.
Мне кажется, аргумент против векторных БД из-за прозрачности и compliance здесь немного искусственный. Да, сам embedding человек прочитать не может и восстановить из него исходный текст тоже нельзя. Но ведь никто не обязывает хранить в векторной БД только embedding. Обычно рядом с вектором хранится исходный текст чанка, metadata, scope, source и т. д. Тогда embedding фактически является просто индексом для поиска по этому тексту.
Поверх этого вполне можно сделать обычный UI, где пользователь видит, что именно находится в памяти, может отредактировать или удалить конкретную запись. На изменение текста вешается переиндексация — старый embedding удаляется/обновляется, новый строится из актуального текста. Туда же достаточно естественно добавляются RBAC, audit log, versioning и остальные требования корпоративного контура.
То есть проблемы «пользователь не может посмотреть и исправить то, что агент запомнил» — это скорее свойство конкретной реализации memory layer, а не принципиальное ограничение векторных БД.
При этом сам выбор Markdown/S3 для вашего сценария мне понятен: если память небольшая и вы всё равно целиком инжектите её в контекст, векторный поиск действительно может быть просто лишней сложностью. Но я бы тогда сформулировал аргумент именно так: «для нашего объёма и access pattern vector DB не даёт достаточной пользы, чтобы оправдать дополнительную инфраструктуру», а не как ограничение по прозрачности/compliance.
Микрофонами*
Была похожая мысль, только не со смартфонами, а с дешёвыми микрорайонами, распределенными по периметру. И позиция у них статическая, не нужен gps
Я тоже тестировал именно эти модели и столкнулся с тем, что
tok/sздесь желательно сравнивать вместе ссимволами/с: у моделей разные токенизаторы и разный средний объём текста в одном токене. В моих тестах TTFT у Qwen часто был сопоставимым или даже ниже, хотя поtok/sон стабильно проигрывал. Поэтому разница в реальной скорости выдачи текста и пользовательской задержке может быть заметно меньше, чем следует из сравнения только токенов в секунду.По бизнес модель ничего не написано. Такая модель идеально ложится в физических ассистентов, гуманоидных роботов и даже умных колонок.
Tauri
Что-то никто в комментах не понимает кажется для чего xray. Сам раньше просто прокидывал порты по ssh. Последнее время такой способ был не стабильный. Было ощущение что ssh разрывает провайдер. Тоже думал через xray гонять, но показалось слишком грамоздко. В итоге сдался и купил белый айпи за 100 рублей.
Роутер вообще проблема)) Теперь надо спрашивать, что у гостей установленно на устройствах, перед тем как им пароль от вайфая давать))
Мне кажется РКН сам может насоздавать липовых заблокированных доменов, на которых будет ловить такие впн. И этот список может быть динамическим. Пока что вижу спасение в per-app тунелировании.
И опять же. Если исходить из выводов статьи, то сплит по доменам не сработает.
Интересно как это все будет работать, если использовать сплит туннелирование по приложению
Как будто оправдывать fine tuning, если нужна работать в автономном режиме, не аргумент. ведь раг систему можно скачать на edge устройство. И синхронизировать при доступе в интернет