aary 

Собрал Heritrix 3 через GitLab CI

by aary


Posted on пятница мая 15, 2026 at 01:08AM in ЖЖ


Немало времени на это потратил. И на перенастройку самого Heritrix3. Оказалось, что нельзя пытаться заблокировать скачивание robots.txt, потому что это обязательный ритуал у Heritrix3, он их с каждого сайта качает первыми.

В этот раз HEAD/master (3.14.1+), а не 3.10 как в прошлый. Впрочем, разница незаметна. Теперь контейнеры делаются через Dockerfile + docker-compose.yml

Предыдущая запись была 9 апреля, эта 15 мая. Получается, что больше месяца времени на это потратил.


Попробовал создавать БД при помощи Liquibase 5.0.2

by aary


Posted on четверг апреля 09, 2026 at 05:45PM in ЖЖ


Технический отчёт за сегодня

1. Настройка развёртывания приложения

  • Устранена ошибка сборки, связанная с несуществующей версией родительского POM Spring Boot.
  • Настроен Tomcat Manager API для удалённого деплоя WAR-файла через HTTP-запросы.
  • Решена проблема доступа к Manager API (403), вызванная ограничениями по IP в конфигурации контекста Tomcat.
  • Создан скрипт предварительной инициализации контейнера для копирования стандартной конфигурации Tomcat и веб-приложения Manager.

2. Подключение к базе данных

  • Настроена сетевая связанность между Docker-контейнером Tomcat и сервером PostgreSQL на хосте.
  • Исправлены синтаксические ошибки в конфигурации pg_hba.conf, приводившие к отказу в подключении.
  • Зафиксирована подсеть Docker в compose.yaml для обеспечения стабильного IP-адреса контейнера и корректной аутентификации в БД.

3. Управление схемой базы данных

  • Подключена и настроена миграционная система Liquibase.
  • Созданы файлы миграций для автоматического развёртывания таблиц пользователей и ролей.
  • Реализована проверка актуальности схемы БД при запуске приложения с перенаправлением на инструкции по обновлению в случае несоответствия.
  • Добавлено логирование статуса выполнения миграций.

4. Система аутентификации и авторизации

  • Настроена Spring Security с хранением учётных записей в базе данных PostgreSQL.
  • Реализована публичная страница регистрации новых пользователей.
  • Создана административная панель с возможностью просмотра списка пользователей и блокировки/разблокировки учётных записей.
  • Реализовано автоматическое создание учётной записи администратора при первом запуске либо через веб-форму мастера установки, либо через переменные окружения.

5. Мастер первоначальной настройки

  • Разработан контроллер, выполняющий проверку готовности окружения (наличие БД, версия СУБД, состояние схемы, наличие администратора).
  • Создан набор информационных страниц с пошаговыми инструкциями для устранения типовых проблем (отсутствие подключения к БД, необходимость обновления СУБД, запуск миграций и др.).
  • Обеспечено блокирование доступа к страницам мастера после завершения настройки.

6. Доработка интерфейса и навигации

  • Скорректированы ссылки в шаблонах для корректной работы с контекстом приложения.
  • Устранены ошибки в Thymeleaf-выражениях, вызывавшие исключения при отсутствии активного профиля Spring.
  • Актуализировано содержимое главной страницы в соответствии с предметной областью.

7. Оптимизация и диагностика

  • Выявлена и решена проблема длительного запуска Tomcat, связанная со сканированием TLD в JAR-файлах.
  • Добавлены инструкции по точечному отключению сканирования TLD через контекстный XML-файл.
  • Рассмотрены рекомендации по улучшению аутентификации в PostgreSQL с использованием SSL-сертификатов и по управлению ограничениями доступа для пользователей.

Результаты

  • Приложение успешно развёртывается и работает в целевой среде.
  • Обеспечена возможность самостоятельной настройки окружения администратором без ручного вмешательства в конфигурационные файлы.
  • Реализован базовый функционал управления пользователями и ролями.


Настроил Heritrix 3.10.0 и OpenWayback

by aary


Posted on вторник апреля 07, 2026 at 05:33PM in ЖЖ


Отчёт о настройке системы веб-архивации

1. Цель работы

Настроить полный цикл сбора и последующего воспроизведения веб-контента:

  • Запустить и сконфигурировать краулер для выборочного скачивания сайтов.

  • Обеспечить передачу собранных данных в систему воспроизведения архивных копий.

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

  • Исключить нежелательный переход на посторонние сайты по обычным гиперссылкам.

  • Проверить работоспособность всей цепочки и выявить оптимальные настройки.

2. Используемые компоненты

  • Краулер – программа для сбора веб-страниц и файлов.

  • Система воспроизведения архивов – для просмотра сохранённых копий.

  • Контейнеризация – для изолированного запуска компонентов на выделенном сервере.

  • Рабочая станция – для подготовки конфигураций и анализа логов.

3. Выполненные этапы

3.1. Развёртывание и начальная настройка

  • Краулер и система воспроизведения запущены в отдельных контейнерах на серверной машине.

  • Настроен общий том (директория) для обмена собранными архивными файлами между краулером и системой воспроизведения.

  • Организована сетевая доступность между компонентами.

3.2. Настройка краулера (базовый режим)

  • Подготовлен минимальный рабочий конфигурационный файл, позволяющий краулеру запускаться и обрабатывать указанный начальный адрес.

  • В процессе отладки были устранены ошибки, связанные с аутентификацией веб-интерфейса краулера и правами на запись в рабочие каталоги.

3.3. Организация рекурсивного обхода сайта

  • Изначально краулер скачивал только главную страницу и не переходил по внутренним ссылкам.

  • Путём корректировки правил обхода («scope») удалось настроить бесконечную глубину перехода по ссылкам внутри целевого сайта.

  • Достигнуто стабильное скачивание сотен внутренних страниц (количество обработанных URL выросло с единиц до тысяч).

3.4. Ограничение области сканирования

  • В конфигурацию добавлены правила, запрещающие переход на посторонние домены по обычным гиперссылкам.

  • Это предотвратило «уход» краулера во внешний интернет и позволило сфокусироваться на целевом сайте.

3.5. Разрешение внешних ресурсов (стили, скрипты, картинки)

  • Обнаружено, что при ограничении доменов перестали скачиваться необходимые элементы оформления (CSS, JavaScript, изображения), которые физически расположены на других сайтах.

  • Разработана комбинация правил:

    • Список разрешённых доменов для таких ресурсов задан в отдельном файле.

    • Включена проверка «родительской страницы» – внешний ресурс скачивается только если на него есть ссылка с уже принятой страницы целевого сайта.

  • В результате стили и скрипты стали корректно сохраняться в архив, что обеспечивает правильное отображение страниц при воспроизведении.

3.6. Настройка скачивания файлов (книг, документов)

  • В конфигурацию добавлено правило, принимающее любые ссылки на файлы с типичными расширениями (PDF, EPUB, FB2, DJVU, DOC и др.) независимо от их домена.

  • Это позволило автоматически собирать все книжные и архивные файлы, на которые есть ссылки со страниц целевого сайта.

3.7. Отладка синтаксиса правил

  • В ходе работы выяснились особенности синтаксиса, используемого правилами фильтрации.

  • После нескольких итераций был найден рабочий вариант записи префиксов, обеспечивающий корректное распознавание доменов.

  • Лишние, неиспользуемые правила удалены для упрощения конфигурации.

3.8. Проверка целостности данных

  • Выполнен анализ логов краулера, подтверждающий, что скачиваются как страницы целевого сайта, так и внешние стили, скрипты, а также файлы книг.

  • Через интерфейс системы воспроизведения подтверждена возможность просмотра сохранённых страниц (со стилями) и доступа к скачанным файлам.

4. Достигнутые результаты

  • Стабильная работа краулера: система запускается, обрабатывает тысячи URL, не «падает» и не уходит на посторонние сайты.

  • Полное воспроизведение страниц: архивные копии отображаются с оригинальными стилями и оформлением.

  • Автоматический сбор внешних файлов: все ссылки на книги, документы и архивы, встречающиеся на целевых страницах, сохраняются в архив.

  • Гибкая настройка: правила фильтрации легко дополнять новыми типами файлов или разрешёнными доменами.

  • Прозрачность работы: все действия логируются, что позволяет отслеживать поведение краулера и выявлять возможные проблемы.

5. Замечания и рекомендации

  • Для обеспечения полноты архива периодически следует проверять, не появились ли на сайте ссылки на новые типы ресурсов (например, аудио, видео), и при необходимости расширять список разрешённых расширений.

  • При значительном росте объёма архива рекомендуется рассмотреть использование внешнего индексатора (например, CDX-сервера) для ускорения поиска и масштабирования.

  • В случае изменения структуры внешних ресурсов (смена домена CDN) потребуется обновить список разрешённых доменов.

  • Все конфигурационные файлы и сценарии запуска целесообразно хранить в системе контроля версий для воспроизводимости.

6. Вывод

В результате проделанной работы создана полностью функционирующая система веб-архивации, которая:

  • собирает контент с заданного сайта, включая все необходимые внешние ресурсы и файлы;

  • ограничивает обход только нужными доменами, не допуская бесконечного блуждания по интернету;

  • сохраняет собранные данные в формате, пригодном для последующего просмотра через интерфейс архивной системы.

Настройки могут быть повторно использованы для любых других сайтов с минимальными правками (замена целевого домена и, при необходимости, списка внешних ресурсов).


Установил/настроил Apache Archiva 2.2.10

by aary


Posted on пятница апреля 03, 2026 at 04:04AM in ЖЖ


✅ Сборка из исходников

  • Успешно выполнена полная сборка Apache Archiva 2.2.10 из официального Git-репозитория по релизному тегу
  • Сгенерирован целевой артефакт: archiva-webapp-2.2.10.war
  • Все 68 модулей проекта прошли компиляцию и тестирование зависимостей без критических сбоев
  • Настроено стабильное разрешение артефактов через внутренний Maven-репозиторий

✅ Исправление JavaUtils (совместимость с современными JRE)

  • Выявлена причина падений персистентного слоя: устаревший парсер версий в org.jpox.util.JavaUtils
  • Переписана логика сравнения версий: устранено затенение переменных, добавлена корректная обработка формата major.minor.patch
  • Патч применён к библиотеке JPOX 1.1.9, пересобран и опубликован в локальном репозитории
  • Обеспечена стабильная работа JDO-слоя на актуальных версиях Java (17+)

✅ Настройка mail.jar

  • Устранены конфликты класслоадеров: почтовая библиотека вынесена в общий classpath сервера приложений
  • Настроен JNDI-ресурс javax.mail.Session для корректной работы почтовых уведомлений Archiva
  • Обеспечена совместимость с современными API активации и предотвращён дублирующий класс-лоадинг из WEB-INF

✅ Конфигурация Tomcat 9 и деплой через Manager API

  • Развёрнут и оптимизирован Tomcat 9 с настройкой пулов соединений и политик безопасности
  • Сконфигурированы JNDI-ресурсы для подключения к PostgreSQL и инициализации контекста приложения
  • Освоен удалённый деплой через Tomcat Manager API:
    • Настроен безопасный доступ к управляющему REST-интерфейсу
    • Реализована автоматическая выгрузка, обновление и откат WAR-артефактов без ручного вмешательства
    • Интегрирована проверка статуса развёртывания и логирование операций деплоя
    • Процесс полностью автоматизирован и готов к интеграции с CI/CD-конвейерами

✅ Настройка сборочного и клиентского окружения

  • Подготовлена стандартизированная среда разработки: JDK, Maven, Git, системные зависимости
  • Настроен защищённый канал передачи артефактов между сборочным узлом и сервером приложений
  • Документирован полный цикл поставки: от клонирования кода до рабочего экземпляра в production-подобной среде
  • Обеспечена полная воспроизводимость процесса на любых совместимых хостах

📋 Итоговые артефакты и готовность

Сборка:
  - Исходный код: официальный релизный тег 2.2.10
  - Патч JPOX: применён, собран и зафиксирован в артефакторее
  - WAR-файл: archiva-webapp-2.2.10.war (готов к публикации)

Инфраструктура:
  - Сервер приложений: Tomcat 9 с настроенными JNDI-ресурсами
  - СУБД: PostgreSQL с выделенной схемой и пользователем для Archiva
  - Деплой: автоматизирован через Tomcat Manager REST API

🎯 Готовность к следующему этапу

  1. Работает автоматический деплой актуальной сборки через Manager API
  2. Настроен веб-интерфейс, аутентификации и управления репозиториями
  3. Протестирована интеграция с внешними хранилищами и системами сборки
  4. Настройкы политики хранения, резервного копирования и мониторинга


Поставил TightBlog

by aary


Posted on суббота марта 28, 2026 at 01:40AM in ЖЖ


1. Технические достижения

  • Запуск TightBlog 4.2.0 на Java 25, PostgreSQL с SSL, исправлены проблемы:

    • Десериализация пароля: @JsonProperty перенесены на сеттеры в UserCredentials.java.

    • Схема БД: password_hash в weblogger_user снят NOT NULL (двухэтапное сохранение: INSERT с NULL → UPDATE с хешем). Также исправлены date_updated и publish_time в weblog_entry.

    • Фиды (Atom): исправлен шаблон entries-atom.html:37 (замена updateTime на dateUpdated).

    • Добавлен заголовок Content-Disposition: inline для отображения в браузере.

  • Роутинг работает: /aary/feed перенаправляется на /tb-ui/rendering/feed/aary через RequestMappingFilter.

  • Feedbro (расширение Firefox) успешно читает локальный фид, решая проблему внешней валидации.

2. Понимание архитектуры TightBlog

  • Таблица user_weblog_role была переименована из roller_permission в 2015 году, семантика изменена с «права» на «роль». Это наследие Roller, но TightBlog упростил модель.

  • Миграции БД перешли от Velocity-генерации к прямым SQL-файлам (Flyway). Это снизило универсальность (только PostgreSQL), но повысило прозрачность и управляемость.

  • В TightBlog несколько блогов на пользователя поддерживаются, хотя в UI Roller эта функция могла отсутствовать.

3. Ключевые концепции, выработанные в диалоге

  • Плоские категории vs теги: категории — рубрикация, теги — кросс-тематический поиск. В TightBlog категории не иерархичны.

  • Фиды: Atom 1.0 + JSON Feed + ActivityPub (последние — для гибкости). Обнаружение фидов через <link rel="alternate">.

  • Мультиязычность в фидах возможна через отдельные фиды по языкам или через атрибут xml:lang.

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

  • Приватность и обнаружение: нужен баланс между «кругами доверия» и шлюзами наружу. Организация как единица доверия может сертифицировать ключи, управлять доступом, модерацией.

  • Теги как сообщества: теги становятся точками входа, имеют свои фиды, модерацию, могут быть scoped по организациям.

4. Уроки из истории

  • «Мой Круг» показал, что неявные круги друзей сложны в UX и не обеспечивают рост. Ваша модель «Планет» с явным членством и уставом может быть понятнее.

  • Провалы XMPP, Matrix, RetroShare связаны с тем, что они решали технические задачи, забывая о массовом пользователе: сложный старт, отсутствие обнаружения, привязка к серверу, метаданные открыты.

  • Успешные системы (Email, DNS) работают потому, что владельцы идентичностей заинтересованы поддерживать свои записи.

5. Предложения для будущего движка

  • Прогрессивная децентрализация: начать с централизованного приложения, затем добавить свой домен, федерацию, P2P.

  • Организация как КА (центр сертификации): выдаёт сертификаты участникам, публикует каталог, управляет модерацией.

  • Теги как службы: каждый тег может иметь правила модерации, фид, уровень доступа (публичный/только для участников).

  • Идентичность: did:web:org:user — портативная, с возможностью миграции.

  • Поиск: контекстный, с приоритетом доверенного круга, группировкой по источникам, опциональными шлюзами наружу.


Wisor AI, Комментарии к тексту

by aary


Posted on пятница марта 20, 2026 at 04:08PM in Wisor AI


Глава 1, параграф 2: «я хочу рассказать про нейросеть ... статистический движок.»

Автор не изложил модель — он перечислил названия классов («Нейрон», «Синапс», «Пакет» и т.д.) и их атрибуты, но не дал ни одного строгого определения. Нет ответов на ключевые вопросы. Вместо конкретики — декларативные утверждения («может», «обладает», «позволяет») и ссылки на неопределённые сущности («сигнатура», «вектор», «контекст»). Это не модель, а набор метафор и интенций.


2026-03-20, PeeKay, Wisor - AI Vision Tool - блог разработки. Комментарий 106
    https://gamedev.ru/projects/forum/?id=292356&page=8&m=6166220#m106

Статистический движок как модель мышления: описание архитектуры Wisor

Глава 1. Введение — описание контекста и целей проекта, введение в тему нейросети и статистического движка
Параграф 1. Необходимость регулярно публиковать контент на множестве площадок
Я зарегистрировал кучу соцсетей и краудфандингов, и по такому поводу мне необходимо регулярно сцеживать свои мысли в тексты что бы поддерживать контентом все площадки.
Параграф 2. Рассказ о нейросети (статистическом движке) как основной теме
Сегодня я хочу рассказать про нейросеть. Вернее даже статистический движок.
Параграф 3. Абстрактная модель работы мозга, наделённая саморефлексией и личным опытом
Я разрабатывал это изначально в качестве абстрактной модели того как по моему мнению функционирует человеческий мозг с точки зрения работы над информацией. Все абстракции подразумевают оптимизированные формулы обработки информации нейронами головного мозга. Эта модель подразумевает способность мыслить, она не просто может, она фактически наделена саморефлексией и личным опытом, у неё есть развитая коммуникация с другими узлами и история взаимодействия с ними, и она непрерывно связывает разнообразные контексты и умеет брать произвольные контексты, то есть например она может построить ассоциативный мост между любыми словами которые ей переданы. Модель экспериментальная по смыслу и по духу, и сейчас лежит в разобранном состоянии и ждёт когда я к ней вернусь.
Глава 2. Нейрон — базовый класс нейрона, его структура, создание, персональный синапс и три базовых действия
Параграф 1. Указание на наличие нескольких базовых классов
Он состоит из нескольких базовых классов.
Параграф 2. Определение нейрона, перечисление его внутренних элементов: ссылки на фрагменты, нейроны, синапсы, пакеты, внутренняя обученность
Класс Нейрон. Нейрон это базовая нода. Нейрон содержит в себе ссылки на фрагменты, на другие нейроны, на синапсы, на пакеты, и каждый нейрон обладает собственной обученностью за счёт собственного внутреннего контента.
Параграф 3. Создание нейрона при открытии веб-страницы и формирование локальной карты обученности
Нейрон создаётся когда пользователь открывает вебстраницу. Весь её контент отправляется в виде текста на вход нейросети и она создаёт локальную карту обученности.
Параграф 4. Наличие персонального синапса для отправки и получения пакетов
У каждого нейрона есть свой персональный синапс, на который он может отправлять пакеты и из которого он получает пакеты.
Параграф 5. Три базовых действия нейрона: приём пакетов из синапса, обработка через связанные нейроны, формирование отрицательного вектора
Нейрон в своей базовой конфигурации делает всего три вещи - принимает пакеты из синапса в зависимости от того насколько пакет по ключевым словам пересекается с собственной семантической картой нейрона (его "сообщением", или точнее семантическим пересечением между сигнатурой пакета и сигнатурой самого нейрона). Он может обработать пакет, т.е если пакет принят нейроном то он может обратиться к своей базе связанных с ним нейронов, и запросить оттуда обработку пакета, каждый нейрон-адресат обрабатывает пакет и возвращает нейрону json с коллекцией ответных текстов. В свою очередь каждый нейрон-адресат может запросить в свою локальную базу связанности с другими нейронами, подгрузить оттуда данные и ответить на входящий пакет. Если ответная реакция на пакет отрицательная, то его содержимое индексируется в отрицательный вектор, то есть вектор определяющий то, чем нейрон не является. Этот вектор обладает сравнимой длиной с вектором принадлежности, и накапливает обученность на основе фальсифицированных утверждений (т.е утверждений априори неверных). После того как пакет обработан к нему добавляются в вектор все нейроответы и содержимое конкретных фрагментов как либо релевантных запросу.
Глава 3. Синапс — транспортная система, активация нейрона, функция срабатывания, обмен с другими синапсами
Параграф 1. Описание синапса как транспортной системы, процесс передачи пакетов и обогащения
Синапс - это транспортная система для пакетов, пакет сначала кладётся на синапс адресата, после чего синапс получает команду активировать нейрон, нейрон вбирает в себя все пакеты синапса и реагирует на каждый согласно своему протоколу, после чего над каждым пакетом совершает либо операцию передачи далее, либо операцию передачи обратно, когда нейрон возвращает обработанные пакеты в синапс то он запускает у него функцию срабатывания, которая заставляет уже синапс передать пакеты на внутреннюю карту других синапсов, которые находятся в разных компьютерных системах. Происходит акт передачи пакетов, но сначала синапс забирает из связанных с ним синапсов их пакеты релевантные его сигнатуре.
Глава 4. Пакет — контейнер данных, адресация, шифрование, флаги движения, время жизни
Параграф 1. Структура пакета: адрес предыдущего узла, шифрованная строка, публичный хэш, флаги transit/returning/static, время жизни
Пакет - это контейнер данных, он содержит адрес предыдущего по цепочке узла, шифрованную строчку которую можно открыть только закрытым ключом адресата, и публичный хэш по которому он таргетится в системе. Пакет движется по сети и обогащается, у него есть флаг transit, returning, static <- есть "время жизни", которое убывает по мере накопления ответов, как только время жизни иссякает пакет помечается как returning до тех пор пока не достигнет своего источника запроса и не вернёт ему данные, там он помечается в базе как static и помещается в новый нейрон, который связывается с теми нейронами, которые участвовали в первичном обмене данными.
Глава 5. Базовые элементы — слово, фрагмент, последовательность как основные строительные блоки
Параграф 1. Слово Векторная структура слова, совместный рейтинг контекста, формирование нейрокарты
Слово - это контейнер-вектор, состоит из собственного ID, и вектора word1.rating[word2.id] = context persistance. проще говоря всегда когда слова находятся в одном контексте, у них увеличивается совместный рейтинг, таким образом система обучается и у каждого слова есть длиннющая цепочка связей с другими словами. Благодаря тому что у каждого нейрона своя обученность, то суммарный контекст из активных нейронов образует уникальную нейрокарту под каждый уникальный входящий запрос.
Параграф 2. Фрагмент Типы фрагментов, карта обученности относительно нейрона
Фрагмент - это какой то кусочек текста взятый в качестве токена - предложение, base64 shard, текст в скобках, высказывание, абзац, страница, глава - всё это разновидности фрагментов, каждый из которых обладает собственной картой обученности относительно контейнера-нейрона к которому фрагмент принадлежит. Эта карта позволяет связывать фрагменты из разных нейронов по принципу сходства и близости сигнатур. Фрагменты являются базовой единицей информации передаваемой в пакете. Фрагментом может служить html код, эссеншл, ссылка на вебстраницу, данные о файле, произвольный текст любого объёма.
Параграф 3. Последовательность Пул единиц контента, векторный анализ и предиктивная функция, механизм внимания и генерации
Последовательность - это особый объект, суть которого в том что он разбивает последовательность идущих друг за другом слов в качестве отдельных векторов, и высчитывает между ними тренды, состоит из пула взятых единиц контента - нейронов, фрагментов, слов, синапсов и любых объектов, и в той последовательности в которой они даны он проводит векторный анализ и предиктивную функцию для каждого поля вектора, формируя на выходе новый вектор, относительно которого ищутся фрагменты, нейроны, слова, синапсы или пакеты, и они уже возвращаются в качестве ответа. Фактически это механизм компьютерного внимания и генерации.
Глава 6. Сетевая архитектура и эволюция — гиперсвязанный граф знаний, p2p протоколы, эволюция нейронов
Параграф 1. Формирование сетевой архитектуры и непрерывное обучение на всех типах контента
На базе этих абстракций образуется сетевая архитектура - гиперсвязанных граф знаний, образованный из контента который потребляют пользователи. Он непрерывно обучается на всех вебстраницах, на всех текстах, на всех книгах, на всей музыке, на всех файлах, всё что вы ему даёте он пытается разбирать и обучаться на этом.
Параграф 2. Сетевые протоколы для p2p транзита данных
Так же к системе прилагается ряд сетевых протоколов, которые обеспечивают p2p транзит данных между множествами узлов.
Параграф 3. Логические операции нейронов, контрольный вектор, эволюция и нейрокарты взаимодействия
Нейроны могут выполнять базовые логические операции, могут менять своё состояние, уведомляя систему об активности, у них есть специальный контрольный вектор который как ключ задаёт определённый характер экспрессий, сам по себе один нейрон весит от 1 до 20МБ, и каждый нейрон является полностью самостоятельной абстракцией. Он эволюционирует по мере запросов к нему и обучается в зависимости от обратной связи получаемой от других нейронов на базе тех пакетов что он туда присылает. Для каждого нейрона в своей связанности есть нейрокарта взаимодействия с ним - тоже положительный и отрицательный вектор - положительный за счёт того какие данные были отправлены и приняты с высоким одобрением, а какие пакеты были отвергнуты.
Глава 7. Прикладной уровень и статус проекта — языковая модель, предиктивная система Wisor, открытость и лёгкость ядра
Параграф 1. Языковая модель на основе word2vec и локальной LLM
И уже поверх этого ставится Языковая модель которая преобразует сначала мои вектора в word2vec, а потом обучает на них локальную ЛЛМ.
Параграф 2. Предиктивная модель Wisor, обучение на последовательностях контекстов
Этот алгоритм лежит в основе предиктивной модели всего комплекса модулей Wisor. Он буквально обучен на той информации которая составляла последовательности контекстов переходящих состояний его внутреннего пула обработки. Каждый раз когда он подключает новые нейроны в активности, он индексирует это и собирает снапшоты своего собственного контекста для секвенсора.
Параграф 3. Планы по документации, открытый исходный код, малый вес ядра
Однажды я более подробно изложу этот концепт в документации. Этот проект когда будет готов будет опенсорсным и базовое ядро будет весить 15-20 мегабайт. Запустится даже на умном градуснике.
Параграф 4. Благодарность читателям
Благодарю за то что читаете.


Место для публикации текстов

by aary


Posted on четверг марта 19, 2026 at 01:20PM in ЖЖ


Здесь я буду писать свои мысли. Пока, наверное, на тему создания "схемы технологических работ". Можно подписаться (если есть чем читать подписки).