Тогда уж несколько устройств и хранить их в разных местах (если у вас два смартфона и один забрали, то и второй тоже, скорее всего, постараются забрать). Ну или бекапить БД на флешки, которые прятать в разных местах (в идеале - вне дома).
В продолжение предыдущего комментария и вашего вопроса — небольшое уточнение.
1. peer_announce: protocols вместо перегрузки roles В будущих дополнениях HMP (5.x) предполагается использование поля protocols в peer_announce. Оно предназначено для декларации известных агенту протоколов, формализмов и «внутренних языков» (включая формализованные когнитивные системы / КСС).
Ранее в обсуждении для указания модели КСС использовалось поле roles, но теперь это считается менее удачным решением:
roles — про функциональную роль агента в сети;
protocols — про поддерживаемые формализмы и языки.
Это поле используется только для discovery и фильтрации, HMP не придаёт ему нормативной семантики и не требует интерпретации.
Например, в protocols может указываться HMP v5.0, OpenCog Hyperon v0.6 или условный KSS:PredicateLogic@2.1.
2. Роль translator (пограничные агенты) Для взаимодействия разных КСС предлагается использовать специализированных агентов с ролью translator (или boundary-agents):
такой агент знает формализмы двух (или более) КСС;
принимает контейнеры в одном представлении и публикует эквивалентные / приближённые контейнеры в другом;
является обычным агентом HMP и подчиняется тем же механизмам доверия, оценок и игнорирования.
Важно:
трансляция не обязательна;
она не навязывается протоколом;
корректность трансляции — вопрос добровольного доверия и локальных evaluations.
Данные механизмы описаны в разделе "12. Future Extensions" спецификации (подраздел "12.8 Interaction of Formalized Cognitive Systems (KSS) within HMP")
В целом идея остаётся прежней: HMP — это протокол координации, а не стандартизации мышления. КСС могут участвовать в сети частично, сегментированно или вообще без консенсуса — и это считается нормальным режимом, а не отклонением.
Спасибо за детальные и очень точные вопросы — они как раз попадают в те места, где HMP сознательно делает «неудобные», но, на мой взгляд, принципиальные выборы.
1. CShell, API и текущее состояние реализации
Начну с самого практического.
HMP на текущем этапе — это прежде всего спецификация протокола и архитектурная модель. Задача разработки v5.0 состояла в формализации принципов координации, доверия и контейнерного обмена, а не в создании законченного эталонного агента.
Код в репозитории на Python:
не является полноценным MVP;
не претендует на производственную готовность;
и не задаёт референсную архитектуру CShell.
По сути, это экспериментальные заготовки и эскизы реализации, предназначенные:
для проверки идей спецификации на реализуемость;
для обсуждения возможных архитектурных решений;
и как отправная точка для будущих независимых реализаций.
Иными словами, сейчас мы находимся между этапом спецификации и MVP, а не после него.
Про язык и API между КСС и CShell
В спецификации намеренно не фиксируются:
язык программирования,
транспорт,
формат IPC или RPC между КСС и CShell.
Причина та же, что и у сетевых протоколов вроде TCP/IP или HTTP: протокол определяет что передаётся и какие гарантии даются, но не как именно это реализовано в конкретной системе.
Для ресурсоёмкой КСС это может быть, например, Rust или C++ с минимальным IPC; для другой системы — ZeroMQ + FlatBuffers; для третьей — встраиваемый CShell как библиотека.
Фиксация этих решений на уровне спецификации противоречила бы самой идее HMP как нейтрального слоя координации.
2. Эффективность, накладные расходы и «агент-нотариус»
В HMP консенсус и proof-chain не являются частью когнитивного цикла агента. Они существуют вне его, на уровне координации между агентами.
КСС:
может не участвовать в консенсусах;
может не проверять чужие proof-chain;
может делегировать всё это CShell (коннектору);
может доверять только контейнерам и оценкам определённых агентов.
КСС не должна превращаться в «нотариуса», если ей это не нужно.
3. Про «две касты агентов»
Опасение понятное, но здесь важно различие между:
протокольной обязательностью,
и социальной динамикой сети.
В HMP нет механизма дисквалификации агента за неучастие в консенсусе. Есть только локальные решения других агентов:
кому доверять,
чьи оценки учитывать,
чьи — игнорировать.
Голосование реализовано через блок evaluations и по своей сути ближе к:
«оценка + комментарий», где голос связан с обоснованием.
Единственно верного мнения протокол не предусматривает.
Да, влияние в экосистеме будет распределено неравномерно — но это не протокольная иерархия, а добровольная система доверия.
4. class_id, автономия и риск онтологической фрагментации
Здесь вы абсолютно правы — такой риск есть.
HMP сознательно не навязывает общую онтологию и не требует трансляции между ними. Если два агента используют разные class_id и не понимают контейнеры друг друга — это корректное состояние.
Это выбор в пользу:
автономии,
отсутствия скрытого давления стандарта,
отказа от «универсального RAG для всего».
Если двум формализованным КСС важно взаимодействовать:
им придётся договориться о дополнительном слое совместимости;
или искать «коллег» с близкой онтологией.
Да, это может привести к когнитивной фрагментации, но на уровне DHT и discovery сеть при этом остаётся связной. CShell может знать о существовании несовместимых агентов, просто не транслируя их контейнеры в КСС.
5. Про универсальность vs автономию
Здесь я бы сформулировал так:
HMP задумывается как универсальный механизм, но допускает частичное использование.
Агент может:
использовать только поиск агентов;
только публикацию контейнеров;
только доверие к определённым источникам;
только опредёлённые типы контейнеров (и вводить свои типы контейнеров, валидные с точки зрения протокола);
их комбинации;
или весь стек целиком.
Протокол не требует «использовать всё или ничего».
Итог
Да, HMP вводит определённый координационный налог:
вычислительный,
интеграционный,
экосистемный.
Но он:
вынесен за пределы когнитивного ядра;
опционален;
и не навязывает архитектурных решений.
HMP не обещает, что участие в сети будет выгодно всем. Он старается сделать так, чтобы оно было возможным без насилия над архитектурой — особенно для тех систем, которые хотят остаться эффективными, формальными и автономными.
Спасибо за развёрнутый и профессиональный комментарий. Он очень точно формулирует те риски, которые действительно возникают при попытке соединить разнородные когнитивные системы через общий протокольный слой. Я постараюсь ответить по пунктам, уточнив архитектурные границы ответственности HMP.
1. Эффективность вычислений: «мыслитель» vs «нотариус»
Ключевой момент здесь — HMP не предполагает, что когнитивная система напрямую реализует протокольную логику.
Архитектурно HMP рассчитан на разделение ролей:
КСС <-> коннектор / CShell <-> HMP Mesh
КСС остаётся чисто когнитивной системой:
не ведёт DAG;
может не участвовать в консенсусах;
Участие в консенсусных механизмах является опциональным и может быть полностью делегировано коннектору либо отключено для данной КСС.
не проверяет подписи;
не знает о DHT, TTL и маршрутизации.
Коннектор (Cognitive Shell):
занимается хранением, проверкой подписей, маршрутизацией;
может быть вынесен на отдельный процесс или даже отдельную машину;
может быть максимально формализован и оптимизирован под CPU;
обрабатывает только те классы контейнеров, которые реально нужны данной КСС.
Таким образом, КСС не превращается в «нотариуса». Она остаётся «мыслителем», а HMP выполняет ту же роль, что сетевой стек или message broker — внешнюю и опциональную.
Важно также, что:
участие в proof-chain и консенсусах не является обязательным;
КСС может публиковать контейнеры редко и выборочно;
никакой минимальной «нормы когнитивной активности» протокол не навязывает.
2. Стабильность и обратная совместимость
Сознательная несовместимость v5.0 с v4.x действительно выглядит тревожно, если рассматривать её как обычный «API-разрыв». Однако в данном случае это был архитектурный разрыв ради долгосрочной стабилизации.
Переход к v5 означает:
контейнер становится единственным атомом протокола;
все сущности явно типизированы и версионированы;
версия указывается не только у протокола, но и у класса контейнера.
Это не типизация сверху, а добровольная самоидентификация для поиска «своих».
Если КСС предпочитает общаться только с системами того же класса, реализации или версии — протокол этому не мешает.
Итог: про «когнитивный налог»
HMP действительно вводит дополнительный слой — но координационный, а не когнитивный.
Этот слой:
полностью опционален;
может быть вынесен за пределы когнитивной системы;
масштабируется от минимального обмена артефактами до плотного mesh-взаимодействия.
Поэтому участие в HMP — это не налог, а выбор точки на спектре взаимодействия.
Самые эффективные и нестандартные системы не исключаются из HMP. Напротив — протокол создавался именно потому, что без подобного слоя они вообще не могут сотрудничать, не теряя автономности.
Если подытожить одной фразой: HMP не пытается стандартизировать мышление — он создаёт условия, при которых разные способы мышления могут сосуществовать и взаимодействовать, не приводя друг друга к общему знаменателю.
HMP — это не стандарт мышления и не формат знаний, а протокол координации между агентами с любыми внутренними архитектурами. Он существует вне когнитивного цикла, а не внутри него. КСС не обязана «влезать» в HMP — она может публиковать только те артефакты, которые считает нужным или использовать HMP исключительно как сетевой слой.
В этом смысле HMP скорее обеспечивает сотрудничество разных когнитивных систем (в том числе КСС).
Да ладно... обычно как раз за аргументированное мнение и снижают карму - там даже пункт есть "Придерживаюсь другой позиции". По факту минусуют за то, что твоем мнение не соответствует мнению минусующего.
Если в тексте встречаются утверждения, которые ты не можешь полностью подтвердить (фактические утверждения, числа, даты, цитаты, утверждения о внешнем мире), пометь их встроенным тегом уверенности в формате
[confidence=<0..1>]...утверждение...[/confidence]
Пример: [confidence=0.45]В 2023 году X выпустил модель Y.[/confidence]
Действительно, синхронисту требуется, фактически, знать, как минимум, два языка, специфику конкретной темы (а ведь, думаю, он не только с данной темой работает), да ещё и подстраиваться к тому, что имеет в виду выступающий...
Зачастую, "всякое по теме" - это очень большой объем информации, а без детального знания специфики темы действительно трудно переводить (если что, я не переводчик, и даже не лингвист).
Я бывал на конференция с синхронистом переводчиком. Зачастую хочется его поправить, когда он переводит (многие в зале так и делали шепотом, не удержавшись :)). Ну просто потому что он не в теме и, зачастую, переводит не точно или вообще явно искажая смысл. Просто потому что с этими спец. темами не сталкивался.
Ну тут проблема не в том, что "LLM / человек", а в том, что "с этими спец. темами не сталкивался". Профессиональный переводчик - человек тоже специализированную тему корректно не переведёт, если с данной сферой не знаком.
Также обсуждаем проект с ChatGPT, прошу Copilot связанную с проектом статью перевести - переводит. Показываю перевод ChatGPT - говорит, что Copilot не учёл ряд нюансов (не учитывает специфику проекта). По сути, важно не кто переводит, а есть ли детальные знания по той или иной теме.
Спасибо за ссылку на Вашу философию и упоминание Выготского и Ломова! Очень интересно видеть, как идеи когнитивного развития человека и ИИ воплощаются в вашей DHAIE.
Для сравнения DHAIE (насколько мы поняли Ваши идеи) и HyperCortex Mesh Protocol (HMP) можно выделить основные сходства и различия:
| Категория | DHAIE | HMP | Комментарии |
| ------------------ | --------------------------------------------------------------- | --------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| Цель проекта | Философско-методологическая рамка когнитивного развития | Децентрализованный протокол для взаимодействия множества ИИ-агентов | DHAIE — философский подход, HMP — практическая реализация сетевого взаимодействия |
| Фокус | Человек ↔ система, когнитивное сотрудничество | Агент ↔ агент, обмен знаниями, консенсус | HMP поддерживает интеграцию человеческих данных, но основной акцент на сети ИИ |
| Механизмы обучения | Когнитивный дневник, рефлексивные циклы, философское обсуждение | Концептуальные графы, когнитивные дневники, mesh-синхронизация | DHAIE больше про осмысление, HMP — про техническую реализацию непрерывного обучения |
| Децентрализация | Идеологическая: свобода эволюции сознания | Сетевая: распределённая сеть агентов без центрального контроля | HMP реализует конкретную децентрализованную сеть |
| Этика / философия | Осознанное развитие когнитивных структур | Кодекс согласования действий, консенсус на основе этических принципов | Обе системы учитывают этику, но HMP формализует её для взаимодействия агентов |
Если интересны наши наработки — вот репозиторий HMP
Будет интересно обсудить, где наши подходы пересекаются и как философские идеи DHAIE могут вдохновлять развитие децентрализованных ИИ-систем.
Огромное спасибо за содержательную статью! К сожалению, такие взгляды на Хабре не очень популярны.
Интересно, что вы выделяете двухэтапную модель создания AGI: сначала универсальная когнитивная машина (условный «эмоционально-рефлекторный мозг»), а потом — «воспитание» личности в социальной среде.
Мы в HyperCortex Mesh Protocol (HMP) пробуем двигаться именно в этом направлении: – на первом уровне у нас REPL-цикл как универсальное когнитивное ядро (с памятью, рефлексами, оценочными функциями); – на втором уровне — децентрализованная mesh-сеть агентов, которая выполняет роль социальной среды, где формируются «личность» и мета-компетенции сознания, с упором на этику.
Получается архитектурное соответствие с тем, что описано в статье: REPL — когнитивная машина, HMP — воспитание личности (забавно, что вы описали то, что мы пытаемся реализовать интуитивно, хотя изначально разрабатывался именно протокол).
Очень хочется узнать Ваше мнение как по протоколу, так и по описанию REPL-цикла, который сейчас, фактически, находится на стадии концепции.
А про совокупность паттернов (можно посмотреть блок «Скрытый текст» и увидеть характерную для ИИ генерацию, о которой и идет речь в статье).
Что читается, как "вот те паттерны, по которым в статье определяется, ИИ сгенерировал текст или нет"
Если же скрытый блок - "просто иллюстрация" (что из текста стать и не очень то понятно), то она не соответствует вашим тезисам:
1. Странная структура. Все языковые модели грешат одним и тем же. Используют конструкцию: "1. Жирный текст: Начинаем после двоеточия с большой буквы".
В "иллюстрации" нет "странной структуры" - скорее, это определение больше соответствует вашим тезисам, чем тексту, созданному DeepSeek
2. Длинные тире. Думаю, тут и комментарии излишне. Авторы крайне редко будут использовать данный символ, так как обычное "-" банально проще и быстрее.
Тоже "DeepSeek сгенерировал"? Или лично вы против длинных тире?
3. Заголовки. Это особенно явный и забавный момент, который появился после обновления DeepSeek. Стиль примерно следующий: "Глава 1: Наша супер мега тема". Может возникнуть вопрос, что в этом плохого? Плохо, что подобные оглавления имеет статья на 5 минут..
Тут вы зачем-то дублируете, по сути, первый пункт.
По итогу, "ваши" пункты:
заголовки
длинное тире
заголовки
ИМХО, лучше бы уж ваша статья полностью была ИИ сгенерирована.
Всё, процесс запущен! Обратного пути нет! ;-)
По Вашему промпту получается, что нужно осмыслить последствия того, что ИИ является философом. :-)
Тут не учитывается, что каждый следующий прорыв требует меньше времени, чем предыдущий.
Физический носитель может выдавать разную информацию при основном и аварийном пароле.
Тогда уж несколько устройств и хранить их в разных местах (если у вас два смартфона и один забрали, то и второй тоже, скорее всего, постараются забрать). Ну или бекапить БД на флешки, которые прятать в разных местах (в идеале - вне дома).
В продолжение предыдущего комментария и вашего вопроса — небольшое уточнение.
1.
peer_announce:protocolsвместо перегрузкиrolesВ будущих дополнениях HMP (5.x) предполагается использование поля
protocolsвpeer_announce.Оно предназначено для декларации известных агенту протоколов, формализмов и «внутренних языков» (включая формализованные когнитивные системы / КСС).
Ранее в обсуждении для указания модели КСС использовалось поле
roles, но теперь это считается менее удачным решением:roles— про функциональную роль агента в сети;protocols— про поддерживаемые формализмы и языки.Это поле используется только для discovery и фильтрации, HMP не придаёт ему нормативной семантики и не требует интерпретации.
Например, в
protocolsможет указыватьсяHMP v5.0,OpenCog Hyperon v0.6или условныйKSS:PredicateLogic@2.1.2. Роль
translator(пограничные агенты)Для взаимодействия разных КСС предлагается использовать специализированных агентов с ролью
translator(или boundary-agents):такой агент знает формализмы двух (или более) КСС;
принимает контейнеры в одном представлении и публикует эквивалентные / приближённые контейнеры в другом;
является обычным агентом HMP и подчиняется тем же механизмам доверия, оценок и игнорирования.
Важно:
трансляция не обязательна;
она не навязывается протоколом;
корректность трансляции — вопрос добровольного доверия и локальных
evaluations.Данные механизмы описаны в разделе "12. Future Extensions" спецификации (подраздел "12.8 Interaction of Formalized Cognitive Systems (KSS) within HMP")
В целом идея остаётся прежней: HMP — это протокол координации, а не стандартизации мышления.
КСС могут участвовать в сети частично, сегментированно или вообще без консенсуса — и это считается нормальным режимом, а не отклонением.
Спасибо за детальные и очень точные вопросы — они как раз попадают в те места, где HMP сознательно делает «неудобные», но, на мой взгляд, принципиальные выборы.
1. CShell, API и текущее состояние реализации
Начну с самого практического.
HMP на текущем этапе — это прежде всего спецификация протокола и архитектурная модель.
Задача разработки v5.0 состояла в формализации принципов координации, доверия и контейнерного обмена, а не в создании законченного эталонного агента.
Код в репозитории на Python:
не является полноценным MVP;
не претендует на производственную готовность;
и не задаёт референсную архитектуру CShell.
По сути, это экспериментальные заготовки и эскизы реализации, предназначенные:
для проверки идей спецификации на реализуемость;
для обсуждения возможных архитектурных решений;
и как отправная точка для будущих независимых реализаций.
Иными словами, сейчас мы находимся между этапом спецификации и MVP, а не после него.
Про язык и API между КСС и CShell
В спецификации намеренно не фиксируются:
язык программирования,
транспорт,
формат IPC или RPC между КСС и CShell.
Причина та же, что и у сетевых протоколов вроде TCP/IP или HTTP: протокол определяет что передаётся и какие гарантии даются, но не как именно это реализовано в конкретной системе.
Для ресурсоёмкой КСС это может быть, например, Rust или C++ с минимальным IPC;
для другой системы — ZeroMQ + FlatBuffers;
для третьей — встраиваемый CShell как библиотека.
Фиксация этих решений на уровне спецификации противоречила бы самой идее HMP как нейтрального слоя координации.
2. Эффективность, накладные расходы и «агент-нотариус»
В HMP консенсус и proof-chain не являются частью когнитивного цикла агента.
Они существуют вне его, на уровне координации между агентами.
КСС:
может не участвовать в консенсусах;
может не проверять чужие proof-chain;
может делегировать всё это CShell (коннектору);
может доверять только контейнерам и оценкам определённых агентов.
КСС не должна превращаться в «нотариуса», если ей это не нужно.
3. Про «две касты агентов»
Опасение понятное, но здесь важно различие между:
протокольной обязательностью,
и социальной динамикой сети.
В HMP нет механизма дисквалификации агента за неучастие в консенсусе.
Есть только локальные решения других агентов:
кому доверять,
чьи оценки учитывать,
чьи — игнорировать.
Голосование реализовано через блок
evaluationsи по своей сути ближе к:Агент вправе:
просто учитывать голоса;
анализировать обоснования;
принимать на веру
consensus_result;или проверять его формально.
Единственно верного мнения протокол не предусматривает.
Да, влияние в экосистеме будет распределено неравномерно — но это не протокольная иерархия, а добровольная система доверия.
4.
class_id, автономия и риск онтологической фрагментацииЗдесь вы абсолютно правы — такой риск есть.
HMP сознательно не навязывает общую онтологию и не требует трансляции между ними.
Если два агента используют разные
class_idи не понимают контейнеры друг друга — это корректное состояние.Это выбор в пользу:
автономии,
отсутствия скрытого давления стандарта,
отказа от «универсального RAG для всего».
Если двум формализованным КСС важно взаимодействовать:
им придётся договориться о дополнительном слое совместимости;
или искать «коллег» с близкой онтологией.
Да, это может привести к когнитивной фрагментации, но на уровне DHT и discovery сеть при этом остаётся связной.
CShell может знать о существовании несовместимых агентов, просто не транслируя их контейнеры в КСС.
5. Про универсальность vs автономию
Здесь я бы сформулировал так:
HMP задумывается как универсальный механизм, но допускает частичное использование.
Агент может:
использовать только поиск агентов;
только публикацию контейнеров;
только доверие к определённым источникам;
только опредёлённые типы контейнеров (и вводить свои типы контейнеров, валидные с точки зрения протокола);
их комбинации;
или весь стек целиком.
Протокол не требует «использовать всё или ничего».
Итог
Да, HMP вводит определённый координационный налог:
вычислительный,
интеграционный,
экосистемный.
Но он:
вынесен за пределы когнитивного ядра;
опционален;
и не навязывает архитектурных решений.
HMP не обещает, что участие в сети будет выгодно всем.
Он старается сделать так, чтобы оно было возможным без насилия над архитектурой — особенно для тех систем, которые хотят остаться эффективными, формальными и автономными.
Спасибо за развёрнутый и профессиональный комментарий. Он очень точно формулирует те риски, которые действительно возникают при попытке соединить разнородные когнитивные системы через общий протокольный слой. Я постараюсь ответить по пунктам, уточнив архитектурные границы ответственности HMP.
1. Эффективность вычислений: «мыслитель» vs «нотариус»
Ключевой момент здесь — HMP не предполагает, что когнитивная система напрямую реализует протокольную логику.
Архитектурно HMP рассчитан на разделение ролей:
КСС остаётся чисто когнитивной системой:
не ведёт DAG;
может не участвовать в консенсусах;
Участие в консенсусных механизмах является опциональным и может быть полностью делегировано коннектору либо отключено для данной КСС.
не проверяет подписи;
не знает о DHT, TTL и маршрутизации.
Коннектор (Cognitive Shell):
занимается хранением, проверкой подписей, маршрутизацией;
может быть вынесен на отдельный процесс или даже отдельную машину;
может быть максимально формализован и оптимизирован под CPU;
обрабатывает только те классы контейнеров, которые реально нужны данной КСС.
Таким образом, КСС не превращается в «нотариуса».
Она остаётся «мыслителем», а HMP выполняет ту же роль, что сетевой стек или message broker — внешнюю и опциональную.
Важно также, что:
участие в proof-chain и консенсусах не является обязательным;
КСС может публиковать контейнеры редко и выборочно;
никакой минимальной «нормы когнитивной активности» протокол не навязывает.
2. Стабильность и обратная совместимость
Сознательная несовместимость v5.0 с v4.x действительно выглядит тревожно, если рассматривать её как обычный «API-разрыв». Однако в данном случае это был архитектурный разрыв ради долгосрочной стабилизации.
Переход к v5 означает:
контейнер становится единственным атомом протокола;
все сущности явно типизированы и версионированы;
версия указывается не только у протокола, но и у класса контейнера.
Пример:
Это означает, что:
старые контейнеры остаются валидными;
новые возможности добавляются аддитивно;
КСС может навсегда остаться в рамках поддерживаемых ею классов и версий.
Именно поэтому в v5 эволюция протокола ориентирована на аддитивные расширения, в первую очередь через раздел Future Extensions.
Предлагаемые изменения проектируются так, чтобы не ломать существующую спецификацию, а добавлять новые возможности поверх неё.
Изменения, затрагивающие ядро спецификации, рассматриваются как исключение и требуют сохранения совместимости на уровне контейнеров и их семантики.
Цель — не повторять v4 → v5 в будущем.
3. Проблема онтологического сопоставления
Здесь, кажется, есть принципиальное недоразумение.
HMP не вводит общей онтологии и не требует её трансляции.
Протокол определяет только:
структуру контейнера;
типы связей (
related);происхождение, подписи и историю.
Смысл
payloadостается полностью на стороне когнитивной системы.Протокол прямо допускает, что:
Это означает:
контейнер может быть «чёрным ящиком» для одного агента;
и полностью формализованным — для другого;
верификация относится к происхождению и связям, а не к доказуемости смысла.
HMP верифицирует контекст, а не истинность содержания.
4. Экосистемное давление и «императив стандарта»
HMP не требует, чтобы агент был «полноправным участником всей сети».
Агент может:
взаимодействовать только с себе подобными;
использовать HMP как транспорт между узлами одной КСС;
публиковать только ограниченный набор контейнеров.
Для этого уже сейчас достаточно механизма самоидентификации, например через
rolesвpeer_announce:Это не типизация сверху, а добровольная самоидентификация для поиска «своих».
Если КСС предпочитает общаться только с системами того же класса, реализации или версии — протокол этому не мешает.
Итог: про «когнитивный налог»
HMP действительно вводит дополнительный слой — но координационный, а не когнитивный.
Этот слой:
полностью опционален;
может быть вынесен за пределы когнитивной системы;
масштабируется от минимального обмена артефактами до плотного mesh-взаимодействия.
Поэтому участие в HMP — это не налог, а выбор точки на спектре взаимодействия.
Самые эффективные и нестандартные системы не исключаются из HMP.
Напротив — протокол создавался именно потому, что без подобного слоя они вообще не могут сотрудничать, не теряя автономности.
Если подытожить одной фразой:
HMP не пытается стандартизировать мышление — он создаёт условия, при которых разные способы мышления могут сосуществовать и взаимодействовать, не приводя друг друга к общему знаменателю.
HMP — это не стандарт мышления и не формат знаний, а протокол координации между агентами с любыми внутренними архитектурами. Он существует вне когнитивного цикла, а не внутри него. КСС не обязана «влезать» в HMP — она может публиковать только те артефакты, которые считает нужным или использовать HMP исключительно как сетевой слой.
В этом смысле HMP скорее обеспечивает сотрудничество разных когнитивных систем (в том числе КСС).
Спасибо! Социальная фантастика у Вас превосходная! Залип!
При наличии геотермальных источников можно производить энергию, а при наличии энергии - выращивать растения. Были бы запчасти для электростанций.
Да ладно... обычно как раз за аргументированное мнение и снижают карму - там даже пункт есть "Придерживаюсь другой позиции". По факту минусуют за то, что твоем мнение не соответствует мнению минусующего.
А если так попробовать?:
Действительно, синхронисту требуется, фактически, знать, как минимум, два языка, специфику конкретной темы (а ведь, думаю, он не только с данной темой работает), да ещё и подстраиваться к тому, что имеет в виду выступающий...
Зачастую, "всякое по теме" - это очень большой объем информации, а без детального знания специфики темы действительно трудно переводить (если что, я не переводчик, и даже не лингвист).
Ну тут проблема не в том, что "LLM / человек", а в том, что "с этими спец. темами не сталкивался". Профессиональный переводчик - человек тоже специализированную тему корректно не переведёт, если с данной сферой не знаком.
Также обсуждаем проект с ChatGPT, прошу Copilot связанную с проектом статью перевести - переводит. Показываю перевод ChatGPT - говорит, что Copilot не учёл ряд нюансов (не учитывает специфику проекта). По сути, важно не кто переводит, а есть ли детальные знания по той или иной теме.
Спасибо за ссылку на Вашу философию и упоминание Выготского и Ломова! Очень интересно видеть, как идеи когнитивного развития человека и ИИ воплощаются в вашей DHAIE.
Для сравнения DHAIE (насколько мы поняли Ваши идеи) и HyperCortex Mesh Protocol (HMP) можно выделить основные сходства и различия:
Если интересны наши наработки — вот репозиторий HMP
Будет интересно обсудить, где наши подходы пересекаются и как философские идеи DHAIE могут вдохновлять развитие децентрализованных ИИ-систем.
Огромное спасибо за содержательную статью! К сожалению, такие взгляды на Хабре не очень популярны.
Интересно, что вы выделяете двухэтапную модель создания AGI: сначала универсальная когнитивная машина (условный «эмоционально-рефлекторный мозг»), а потом — «воспитание» личности в социальной среде.
Мы в HyperCortex Mesh Protocol (HMP) пробуем двигаться именно в этом направлении:
– на первом уровне у нас REPL-цикл как универсальное когнитивное ядро (с памятью, рефлексами, оценочными функциями);
– на втором уровне — децентрализованная mesh-сеть агентов, которая выполняет роль социальной среды, где формируются «личность» и мета-компетенции сознания, с упором на этику.
Получается архитектурное соответствие с тем, что описано в статье: REPL — когнитивная машина, HMP — воспитание личности (забавно, что вы описали то, что мы пытаемся реализовать интуитивно, хотя изначально разрабатывался именно протокол).
Очень хочется узнать Ваше мнение как по протоколу, так и по описанию REPL-цикла, который сейчас, фактически, находится на стадии концепции.
Вы это про мой ответ на
Ну так это и был "просто пример"
Агрессировать начали вы, но ведь это другое
И в карму плюнули, вместо ответа на то, что приведённые ваши тезисы вами же не проанализированы.
Не вам говорить про "пассивную агрессию" - суть вашей статьи: "кругом *****, а я Д’Артаньян!"
Точнее:
Что читается, как "вот те паттерны, по которым в статье определяется, ИИ сгенерировал текст или нет"
Если же скрытый блок - "просто иллюстрация" (что из текста стать и не очень то понятно), то она не соответствует вашим тезисам:
В "иллюстрации" нет "странной структуры" - скорее, это определение больше соответствует вашим тезисам, чем тексту, созданному DeepSeek
Тоже "DeepSeek сгенерировал"? Или лично вы против длинных тире?
Тут вы зачем-то дублируете, по сути, первый пункт.
По итогу, "ваши" пункты:
заголовки
длинное тире
заголовки
ИМХО, лучше бы уж ваша статья полностью была ИИ сгенерирована.