Вступление

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

Для обычного пользователя всё выглядит достаточно просто:

открыл сайт или программу → написал запрос → получил ответ.

Из-за этого постепенно возникло представление, что ИИ — это и есть большая языковая модель, с которой человек разговаривает через окно чата. Но это не совсем так. Современная корпоративная ИИ-система и отдельно взятая LLM — далеко не одно и то же.

Между файлом модели и тем, что пользователь видит в крупных сетевых ИИ-сервисах, находится огромный программный слой:

· инфраструктура;

· память;

· инструменты;

· базы данных;

· поиск;

· маршрутизация запросов;

· системы безопасности;

· средства проверки;

· дополнительные модели;

· управляющая логика.

Поэтому сравнивать скачанную на компьютер LLM с крупной сетевой ИИ-системой по одному окну чата некорректно. Они могут выглядеть одинаково, но архитектурно это совершенно разные вещи. И именно с этого различия стоит начинать разговор о современных ИИ-системах и о том, почему в проекте Neira мы пошли другим путём.

Нейросеть и LLM — не одно и то же

Для начала стоит разделить несколько понятий, которые сегодня часто смешивают.

Нейросеть

Нейронная сеть — это математическая вычислительная модель, способная находить закономерности в данных.

Нейросети могут использоваться для совершенно разных задач:

· распознавания изображений;

· определения объектов;

· классификации данных;

· анализа сигналов;

· прогнозирования;

· обработки речи;

· генерации текста;

· управления различными системами.

То есть понятие «нейросеть» значительно шире понятия LLM.

LLM

Large Language Model — большая языковая модель.

Её основная область работы — последовательности токенов.

Если сильно упростить, модель получает входящую последовательность и вычисляет вероятности дальнейшего продолжения.

Именно из этого механизма возникает способность:

· вести диалог;

· писать тексты;

· отвечать на вопросы;

· создавать программный код;

· анализировать документы;

· переводить;

· формировать рассуждения.

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

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

Что пользователь видит в современной ИИ-системе

Пользователь обычно видит только верхний слой.

Например:

· окно диалога;

· историю сообщений;

· загрузку файлов;

· генерацию изображения;

· поиск;

· работу с кодом.

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

Запрос пользователя может пройти примерно такой путь:

запрос → анализ контекста → определение задачи → выбор инструмента → получение дополнительных данных → обращение к модели → проверка → формирование ответа

В некоторых случаях используются сразу несколько моделей.

Одна может работать с текстом.

Другая — с изображением.

Третья — выполнять специализированный анализ.

Отдельные программные модули могут:

· искать информацию;

· читать файлы;

· выполнять код;

· хранить данные;

· проверять ограничения;

· контролировать доступ.

Пользователь этого практически не видит, он видит конечный ответ. Отсюда возникает одна из главных иллюзий современной ИИ-индустрии:

будто вся система и есть одна нейросеть.

На практике гораздо правильнее представить её так:

модель + память + инструменты + данные + управляющая логика + инфраструктура

Именно архитектура вокруг модели определяет очень значительную часть возможностей конечного продукта.

Что представляет собой корпоративная сетевая ИИ-система

Крупная корпоративная ИИ-система — это уже не просто LLM, размещённая на сервере. Это программно-вычислительный комплекс.

В нём могут существовать:

· одна или несколько LLM;

· модели компьютерного зрения;

· речевые модели;

· серверы хранения;

· базы данных;

· системы RAG;

· поисковые механизмы;

· средства выполнения кода;

· системы безопасности;

· API;

· очереди задач;

· оркестраторы;

· системы памяти;

· маршрутизаторы;

· контроль доступа;

· журналы;

· инфраструктура масштабирования.

Например, человек просит:

«Проанализируй этот файл и проверь приведённые в нём данные».

Сама LLM физически не обязана уметь открывать файл. Программная система сначала получает его, определяет тип, извлекает содержимое, при необходимости передаёт его другим инструментам, подготавливает данные и лишь затем отправляет необходимые части модели.

То же самое происходит при работе с интернетом. LLM не обязательно самостоятельно «ходит в интернет». Это делает отдельный инструмент. Он получает данные, после чего система передаёт их модели. То есть модель является участником процесса, а не обязательно всей системой.

Почему сетевой ИИ часто кажется намного мощнее локальной модели

Когда человек впервые скачивает мощную Open-Source LLM, у него закономерно возникает ожидание:

«Сейчас у меня будет примерно то же самое, только локально».

А затем он получает обычное окно диалога, модель отвечает, пишет тексты, может создавать код. Но многие возможности сетевого ИИ отсутствуют.

И возникает впечатление: локальная модель слабее.

Иногда она действительно меньше или сильнее квантована. Но очень часто проблема вообще не только в модели. Разница заключается в количестве систем, находящихся вокруг неё.

Корпоративный ИИ может иметь:

· долговременную память;

· персональный контекст;

· доступ к файлам;

· поиск;

· выполнение кода;

· инструменты;

· базы знаний;

· системы проверки;

· облачные вычисления;

· дополнительные модели.

А локально пользователь зачастую запускает:

LLM + простую программу общения с ней.

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

Что требуется для запуска локальной LLM

Файл весов модели нельзя просто открыть двойным щелчком и начать с ним разговаривать. Модель необходимо где-то исполнять, для этого требуется программная среда.

Это может быть:

· специализированный runtime;

· inference-сервер;

· десктопная программа;

· локальный веб-интерфейс;

· собственная разработанная система.

Минимальная локальная конфигурация выглядит примерно так:

файл модели → программа исполнения → интерфейс пользователя

Уже внутри программы задаются различные параметры:

· используемый CPU;

· используемый GPU;

· распределение слоёв;

· объём контекста;

· параметры генерации;

· системные инструкции;

· формат сообщений;

· использование оперативной и видеопамяти.

После этого человек получает работающую LLM. Но это ещё не полноценная ИИ-система.

Это работающая модель.

Как модель начинает взаимодействовать с компьютером

Сама LLM не знает содержимое вашего диска.

Она не знает:

· какие программы установлены;

· где находится проект;

· какие процессы запущены;

· что записано в системных журналах;

· какие документы лежат в папке;

· что изменилось в программе после предыдущего запуска.

Если требуется такая работа, необходимо создать дополнительную программную среду.

Например, пользователь говорит:

«Посмотри исходный код программы и найди ошибку».

Сначала другая часть системы должна:

1. определить местонахождение программы;

2. прочитать разрешённые файлы;

3. определить структуру проекта;

4. получить код;

5. подготовить данные;

6. передать необходимые части модели.

Если затем LLM предложила изменение, требуется обратный путь:

1. получить результат модели;

2. определить, что именно она предлагает изменить;

3. проверить допустимость действия;

4. внести изменение;

5. проверить синтаксис;

6. запустить тест;

7. получить результат;

8. определить дальнейшее действие.

И всё это уже не LLM.

Это обвязка вокруг LLM.

Дополнительные модули

Чем шире задача, тем больше требуется дополнительных механизмов.

К локальной модели можно подключить:

· память;

· RAG;

· работу с файлами;

· интернет;

· терминал;

· базы данных;

· выполнение программ;

· Git;

· API;

· анализ изображений;

· инструменты мониторинга;

· системы автоматизации.

Но каждый такой инструмент требует механизма взаимодействия.

Нужно определить:

· что ему передавать;

· в каком формате;

· что разрешено;

· где находится результат;

· как обработать ошибку;

· что считать успешным выполнением.

Поэтому серьёзная локальная ИИ-система очень быстро превращается из проекта «скачаем модель» в обычную инженерную разработку. Нужно программировать.

Почему не существует одной универсальной «обвязки»

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

Одному человеку нужен ИИ для документов.

Другому:

· для программирования;

· для бухгалтерии;

· для анализа производства;

· для автоматизации дома;

· для научной работы;

· для кибербезопасности.

И требования к системе будут совершенно разными. Например, помощнику для написания статей не нужен низкоуровневый доступ к операционной системе. А инженерному ИИ такой доступ может быть необходим.

Но вместе с ним появляются:

· права;

· ограничения;

· безопасность;

· контроль выполнения;

· восстановление после ошибки.

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

Система вокруг неё — уже нет.

Локальная LLM и железо

Есть ещё одно большое отличие. Корпоративная система может использовать огромную серверную инфраструктуру. Локальная система ограничена ресурсами одной рабочей станции.

Основные параметры:

· производительность GPU;

· объём VRAM;

· оперативная память;

· CPU;

· скорость системной памяти;

· скорость накопителей.

Большая модель требует много памяти. Именно поэтому локальные пользователи часто сталкиваются с квантованными версиями LLM.

Что такое квантование

Вес модели — это большое количество числовых параметров. Для их хранения требуется память. Чем выше точность представления этих чисел, тем больше объём весов. Квантование позволяет представить веса в более компактной форме.

Условно:

более высокая точность → больше памяти

более низкая точность → меньше памяти

Благодаря квантованию крупную модель можно разместить на оборудовании, на котором исходный вариант просто не помещается.

Это даёт очень серьёзные преимущества:

· меньший размер;

· меньше потребление памяти;

· возможность локального запуска;

· в некоторых режимах — более высокая скорость.

Но важно понимать:

квантованная версия и исходная версия модели вычислительно не идентичны.

При уменьшении точности часть информации о параметрах представляется менее точно.

Насколько это влияет на модель, зависит от:

· архитектуры;

· метода квантования;

· уровня квантования;

· конкретной задачи.

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

Особенно в задачах:

· сложного программирования;

· длинного анализа;

· точного соблюдения инструкций;

· работы с большим количеством зависимостей;

· нестандартного логического разбора.

Поэтому когда говорят: «У меня локально работает та же самая модель», необходимо смотреть, какая именно версия используется. Название модели может совпадать. Фактическое представление её весов — нет.

Три разных понятия под одним словом «ИИ»

В итоге полезно разделить три уровня.

LLM

Языковая модель.

Генеративный механизм.

Локальная система на базе LLM

Это уже:

модель + runtime + интерфейс + инструменты + память + программная логика

Крупная корпоративная ИИ-система

Это:

модели + инфраструктура + инструменты + память + данные + серверы + специализированные сервисы + управляющие системы

Внешне все три могут иметь одинаковое окно чата, но архитектурно между ними огромная разница.

Почему мы начали Neira с другой точки

При создании Neira мы изначально не рассматривали LLM как центр системы. Причина достаточно проста. Генеративная модель является вероятностным механизмом.

Она чрезвычайно полезна там, где требуется:

· работать с естественным языком;

· искать нестандартные варианты;

· интерпретировать неоднозначную задачу;

· предлагать решения;

· формировать текст;

· помогать в анализе.

Но инженерная система не может все свои действия строить только на вероятностной генерации.

Если программа должна:

· изменить системный файл;

· переписать часть проекта;

· выполнить команду;

· изменить конфигурацию сервера;

· создать архитектуру приложения,

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

Поэтому в Neira используется другой подход.

Neira — инженерный гибрид логик

Neira построена как гибрид нескольких типов логики.

Линейная логика

Используется там, где последовательность действий известна.

Например:

получить данные → проверить → выполнить операцию → проверить результат

Здесь генеративность не нужна.

Древовидная логика

Используется там, где дальнейший маршрут определяется результатом предыдущего действия.

Например:

если результат A — идём по одной ветке;

если результат B — по другой;

если данных недостаточно — запускается дополнительная проверка.

Так система может строить сложные маршруты работы.

Генеративная логика

LLM используется там, где задача не может быть полностью описана заранее.

Например:

· предложить возможное решение;

· разобрать нестандартную ошибку;

· сформировать варианты архитектуры;

· понять свободно сформулированное ТЗ;

· объяснить пользователю происходящее.

То есть в Neira соединяются:

линейная логика + древовидная логика + генеративная логика

Именно поэтому LLM является важной частью системы, но не её управляющим центром.

Слова как язык управления

Одна из основных функций LLM внутри Neira — создать удобный канал между человеком и машинной логикой. Человек не должен писать внутренние команды системы. Он говорит обычным языком.

Например:

«Проверь программу, найди причину ошибки и исправь её, не затрагивая остальную архитектуру».

Для человека это понятное техническое задание. Для системы его необходимо превратить в структурированную последовательность действий.

Получается цепочка:

слова → интерпретация → внутреннее представление → команды → модули

В обратную сторону:

модули → результаты → структурированные данные → объяснение → слова

Таким образом язык становится интерфейсом управления.

Но принципиально важно:

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

Core — ядро управления

В центре Neira находится Core.

Именно ядро определяет:

· состояние системы;

· допустимость действия;

· порядок выполнения;

· выбор модулей;

· передачу данных;

· контроль результата;

· необходимость повторной проверки.

LLM может предложить действие. Но предложение и исполнение — не одно и то же.

Core должен определить:

· разрешено ли действие;

· соответствует ли оно задаче;

· существуют ли необходимые условия;

· какой модуль должен его выполнять;

· что считать успешным результатом.

Поэтому архитектурно получается: не LLM управляет Neira

а: Neira управляет использованием LLM.

Это принципиальное отличие.

LLM как генеративный аналитический модуль

В Neira модель используется там, где её сильные стороны действительно полезны.

Например:

· поиск нестандартного решения;

· анализ неизвестного сценария;

· генерация вариантов;

· перевод языка человека;

· формирование объяснений;

· работа с новым техническим заданием.

Но затем результат генерации может быть передан другим механизмам.

То есть: генерация → анализ → проверка → решение → действие

а не: генерация → действие

Для инженерной системы эта разница критична.

Анализ без опоры только на генерацию

Ещё одна задача Neira — уйти от ситуации, когда сама генеративная модель является одновременно:

· источником предположения;

· судьёй;

· проверяющим;

· автором окончательного вывода.

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

При анализе могут учитываться:

· источник;

· происхождение информации;

· временная последовательность;

· наличие независимых подтверждений;

· противоречия;

· связи между фактами;

· качество доказательств;

· альтернативные версии;

· подтверждение или опровержение каждого элемента.

Для различных признаков могут использоваться разные веса. Система может сравнивать несколько вариантов и определять, насколько каждый из них подтверждается имеющейся информацией. Это уже другая постановка задачи.

Не: «Какой текст выглядит наиболее правдоподобным?»

а: «Что именно подтверждает этот вывод и что ему противоречит?»

Отсюда появляется возможность оценки достоверности.

Не бинарное: правда / неправда

а:

· предположение;

· слабое подтверждение;

· существенное подтверждение;

· противоречивые данные;

· высокая степень подтверждения;

· недостаточно данных.

LLM в этой конструкции может помогать находить версии и объяснять результат. Но вес доказательств должна определять не сама генерация.

Neira как инженерная вычислительная среда

Поэтому Neira постепенно перестаёт быть похожей на привычный чат с нейросетью. Архитектурно она гораздо ближе к специализированной вычислительной среде или своеобразной операционной системе инженерного ИИ.

Внутри находятся:

· Core;

· логика состояний;

· модули;

· системы анализа;

· генеративный компонент;

· инструменты;

· контроллеры;

· механизмы выполнения;

· проверка;

· журналы;

· управление связями.

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

Основная цель проекта Neira

Изначально Neira создавалась не как универсальный чат и не как ещё одна красивая оболочка вокруг LLM.

Основная цель проекта была инженерной:

создать мощную систему разработки программного обеспечения.

Не систему, которая умеет написать кусок кода. А систему, способную работать со всем программным проектом.

То есть:

· принять техническое задание;

· понять требуемый результат;

· разложить задачу;

· спроектировать архитектуру;

· построить связи;

· создать модули;

· написать программный код;

· анализировать его;

· проверять зависимости;

· тестировать;

· обнаруживать ошибки;

· исправлять конкретные проблемные участки;

· повторно проверять результат;

· продолжать разработку.

Главная задача выглядит так:

ТЗ → архитектура → реализация → анализ → тестирование → проверка → готовая программа

Почему это принципиально отличается от генерации программы одним запросом

Современная LLM способна написать очень большой объём кода. Но большое количество сгенерированного текста ещё не означает создание качественной большой программы.

Чем крупнее проект, тем больше появляется:

· зависимостей;

· связей;

· состояний;

· интерфейсов;

· конфликтов;

· архитектурных ограничений.

Поэтому Neira должна работать пошагово.

Например:

Архитектура — ↓ проверка — первый модуль — ↓ анализ — тест — ↓ проверка связей — следующий модуль — ↓ интеграционный тест — и далее.

Если появляется ошибка, нет необходимости полностью пересоздавать проект.

Система должна определить:

· где возникло отклонение;

· с каким изменением оно связано;

· какие модули затронуты;

· что необходимо исправить.

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

Локальная работа была условием проекта с самого начала

При этом перед Neira изначально стояло ещё одно ограничение. Такая система не должна обязательно жить в серверном центре. Она должна работать на локальном компьютере. Да, этот компьютер нельзя назвать дешёвым бытовым ПК.

Для крупных моделей и тяжёлого анализа необходимы:

· мощный процессор;

· большой объём RAM;

· производительная GPU;

· большой объём VRAM;

· быстрые накопители.

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

Почему локальная архитектура важна

Локальная инженерная система даёт несколько принципиальных возможностей. Исходный код может оставаться непосредственно на рабочей машине. Не требуется постоянно отправлять проект внешнему сервису. Не требуется постоянная аренда вычислительных ресурсов.

Можно работать с:

· локальными файлами;

· локальным сервером;

· тестовыми средами;

· конфигурациями;

· большими проектами.

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

При необходимости он может использоваться для:

· масштабирования;

· очень тяжёлых вычислений;

· распределения нагрузки;

· коллективной работы.

Но сама архитектура не должна разрушаться без него. Именно поэтому перед проектом стояла достаточно сложная задача:

создать тяжёлую инженерную ИИ-систему, способную жить на одной локальной рабочей станции.

Не перенести серверную систему домой, а построить другую архитектуру

Здесь есть важное различие. Цель не заключалась в том, чтобы взять существующий корпоративный серверный ИИ и каким-то образом ужать его до домашнего компьютера. Это всё равно оставило бы архитектуру, рассчитанную на большие вычислительные ресурсы.

Задача была другой:

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

Поэтому вычисления необходимо распределять между специализированными механизмами.

Если задача может быть решена:

· алгоритмом;

· линейной логикой;

· деревом условий;

· специализированным модулем,

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

Вторая цель Neira — выйти за пределы современной архитектуры ИИ

Есть и ещё одна причина, по которой появился проект Neira. Современные ИИ-системы достигли впечатляющего уровня. Модели становятся больше, контекст растёт, инфраструктура становится мощнее, увеличивается количество агентов и инструментов.

Но сам общий принцип во многом остаётся прежним:

генеративная модель + всё более сложная система вокруг неё.

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

Для проекта Neira это стало одной из отправных точек. Если существующая ветвь развития когда-нибудь приблизится к своему практическому пределу, следующий шаг необязательно должен заключаться в создании ещё большей LLM. Возможно, необходимо изменить саму архитектуру ИИ. Neira рассматривается именно как попытка такого нового старта.

Не более крупная модель, а более сложная система

Основной вопрос тогда меняется.

Вместо: «Как создать ещё более большую модель?»

ставится другой:

«Как создать более развитую вычислительную систему, в которой генеративная модель является только одним из типов мышления?»

То есть развитие происходит не только по линии:

7B → 30B → 70B → сотни миллиардов параметров

а по линии:

логика → структура → память → специализация → доказательство → контроль → генерация → взаимодействие компонентов

В такой архитектуре мощность всей системы определяется уже не только размером LLM. Она определяется качеством взаимодействия различных механизмов.

Следующий этап — аппаратная архитектура

Но если менять программную архитектуру ИИ, в какой-то момент возникает ещё один вопрос. Современные процессоры и GPU создавались не специально для такой гибридной системы. Они прекрасно выполняют огромное количество матричных операций, необходимых нейросетям. Но Neira использует не только генеративную модель.

Внутри одновременно могут работать:

· линейные алгоритмы;

· древовидная логика;

· базы;

· системы весов;

· механизмы сравнения;

· анализ доказательств;

· генеративные модели;

· управляющее ядро;

· специализированные модули.

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

Процессор для ИИ-системы, а не только для нейросети

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

Необходимо эффективно работать одновременно с:

· генеративными вычислениями;

· последовательными операциями;

· ветвлением;

· памятью;

· большими графами связей;

· системой весов;

· специализированными модулями.

Поэтому одна из долгосрочных целей Neira — сначала смоделировать такую архитектуру программно, определить реальные вычислительные потоки, понять узкие места, а затем использовать полученные данные при разработке нового типа процессора для подобных ИИ-систем.

То есть направление развития выглядит так:

программная архитектура → моделирование → анализ вычислительных процессов → специализированная аппаратная архитектура

Не сначала придумать процессор, а затем искать ему применение. А сначала построить работающую систему и посмотреть, какой процессор ей действительно нужен.

От модели к системе

Именно здесь находится главное различие подходов. Современный массовый путь во многом начинается с модели:

есть LLM → строим вокруг неё систему

Neira начиналась с другого вопроса:

какая система необходима для решения поставленной инженерной задачи и какое место внутри неё должна занимать LLM?

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

Итог

LLM — чрезвычайно мощная технология. Но LLM и ИИ-система — не одно и то же.

Модель может:

· генерировать;

· интерпретировать;

· предлагать;

· общаться.

А полноценная система должна ещё:

· управлять;

· помнить;

· проверять;

· выполнять;

· контролировать;

· сравнивать;

· анализировать последствия.

И чем сложнее становится задача, тем важнее уже не только качество самой модели, а архитектура вокруг неё. В Neira мы сделали следующий шаг. Мы не стали строить систему вокруг LLM как единственного центра.

Мы построили гибридную архитектуру, где:

Core управляет

модули выполняют

логика определяет маршрут

система анализа проверяет данные

LLM работает с генеративной частью и естественным языком

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

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

Поэтому Neira для нас — не попытка сделать ещё одну LLM. Это попытка начать следующую архитектурную ветвь развития ИИ.

Не более крупную модель.

Более сложную систему.