The post has been translated automatically. Original language: Russian
When companies start using large language models, one of the first solutions is usually to connect corporate documentation.
It seems that the logic is simple.
The more documents the LLM receives, the more complete its response will be.
You need to upload the technical descriptions.
Regulations.
Initial requirements.
The history of decisions.
Project notes.
Correspondence.
Instructions.
After that, the model will supposedly be able to answer any questions about the system.
In practice, a large amount of information often worsens the result.
The model receives several versions of the same solution.
Mixes the internal parts of different components.
Transfers the limitations of one subsystem to another.
Uses an outdated document instead of an existing one.
And he draws conclusions based on information that should not have been included in the response at all.
The problem is not only the search quality.
The problem lies in the knowledge architecture.
Long before the advent of LLM, David Parnas, one of the founders of the modern theory of modular design, spoke about this.
His ideas are usually associated with software modules and information hiding.
But today, the same principle is becoming critically important for corporate knowledge bases and AI systems.
The main idea of Parnassus
The common notion of modularity looks simple.
A large program needs to be divided into small parts.
Each part performs a specific function.
This makes the code easier to develop and maintain.
But Parnas proposed a deeper criterion of separation.
A module should be formed not just around a processing stage or a set of functions.
It should hide a certain architectural solution.
Each module is responsible for its own area of expertise.
The internal details may vary.
But the rest of the system should not depend on these details directly.
They must interact with the module through a stable contract.
Thus, modularity is not just about code separation.
This is the separation of responsibility and knowledge.
Why is the usual functional separation not enough
Let's imagine a program divided into several successive stages.
One component receives the data.
The other one handles it.
The third saves.
Formally, the system is divided into modules.
But if all the components know the internal data format, storage features, and implementation details of each other, there is no real modularity.
Any change begins to spread throughout the system.
The format is changing — you have to change several components.
The storage method is changing — dependencies are broken.
The internal rule is changing — many sections of the code are being updated.
Parnas suggested hiding decisions that might change.
The rest of the system should not know the internal structure, but the interaction contract.
This reduces the area of influence of each change.
The same problem exists in the documentation
Corporate knowledge is often as poorly organized as a non-modular program.
The description of one component is found in dozens of documents.
The architecture limitation is mentioned in the terms of reference, meeting protocol, instructions, and task comments.
The interface of one module is explained through the internal device of the other.
The reasons for the decision are mixed with the details of the implementation.
The draft ideas are located next to the approved rules.
As a result, it is impossible to determine:
- who is responsible for specific knowledge;
- where is its current wording?;
- what other solutions depend on it?;
- what information is internal;
- which contract should remain stable;
- which articles need to be reviewed after the change.
Such an archive can contain a huge amount of information.
But it has no architecture.
Why is this especially dangerous for LLM
A person who has been working on a project for a long time is often able to mentally separate the important from the secondary.
He knows which document is outdated.
Remembers which option was discussed but not accepted.
Understands that a certain restriction applies to only one component.
LLM does not have such an implicit context.
For her, each fragment found represents a potential source of an answer.
If there are no clear boundaries of responsibility in the documents, the model begins to independently assemble the architecture from the available text.
She can combine facts that should never have been used together.
Can explain the public contract through the time details of the implementation.
It can transfer a rule from one system level to another.
It can make a local decision for the entire platform.
The more convincing the model is, the harder it is to spot the error.
We came across this during the development of Sekura.
During the development of the Sekura platform, several related systems are being developed simultaneously:
- the Memora8 processor;
- operating system Reganta OS;
- Sekura JS language;
- Firmware Kernel;
- system modules;
- thread execution model;
- compiler and development tools.
These components are interconnected.
But communication does not mean that they all need to know each other's internal structure.
For example, the Sekura JS module must understand the execution contract, the available data exchange mechanisms, and the shutdown rules.
But it doesn't need to know all the details of the scheduling implementation inside the kernel.
The Firmware Kernel must provide certain system capabilities.
But the rest of the components should not depend on random internal decisions of its current implementation.
Memora8 sets the hardware limits.
However, not every processor detail should automatically become part of the application module contract.
If these boundaries are not fixed, the architecture quickly turns into a set of implicit dependencies.
Changing one component starts requiring a review of the entire platform.
The code can be divided, but the knowledge can be left connected incorrectly.
You can create separate repositories.
Split the system into directories.
Define software interfaces.
But at the same time, to preserve knowledge in the form of one common array of documents.
Then the formal modularity of the code does not solve the problem.
The developer still doesn't understand.:
- which article defines the contract;
- where does the component's responsibility end?;
- what information is internal;
- which dependencies are considered acceptable;
- which change affects the neighboring modules.
The AI tool finds itself in an even more difficult position.
He sees a lot of text, but he doesn't see the architectural boundaries.
Therefore, modularity should exist not only in the code.
It must exist in the knowledge base.
Noda solves this problem.
In Noda, canonical articles should not form an archive, but an architecture of knowledge.
Each article is responsible for a specific area.
She fixes:
- the subject of knowledge;
- the owner of the solution;
- scope of applicability;
- the established contract;
- internal details, if they are really important;
- links to other articles;
- acceptable dependencies;
- limitations;
- terms of revision.
This allows us to transfer the Parnassus principle from software architecture to knowledge architecture.
The article becomes an information module.
She should be responsible for a specific decision and not spread her responsibility across the entire database.
Canonical article as a module of knowledge
A good canonical article can be compared to a good one a designed software module.
She has an area of responsibility.
It hides unnecessary details.
Provides a clear contract.
Defines connections to neighboring regions.
Allows for internal development without destroying the entire knowledge system.
For example, an article about the Sekura system module contract should not turn into a full description of the Firmware Kernel, Memora8, and the entire Reganta OS.
It should explain exactly what the author of the system module should know.:
- how the module is launched;
- what system features are available to him;
- how it interacts with threads;
- how it frees up a computing resource;
- what actions are allowed;
- what guarantees does the execution environment provide?
The internal structure of the mechanisms can be described in other canonical articles.
Clear connections are created between them.
This way, knowledge remains connected, but not mixed.
Not all context is equally useful.
Modern LLMs support large context windows.
From this, it is sometimes concluded that the entire project documentation can be transferred to the model.
But the technical ability to put data in context does not mean that it is the right architectural decision.
The extra context creates risks:
- important knowledge is lost among the secondary;
- The internal details are starting to compete with the contract;
- outdated information affects the output;
- the probability of false connections increases;
- it is more difficult to determine the source of the response;
- the model receives information outside of its task.
In the architecture of Parnas, a component should receive only the knowledge that is necessary to fulfill its responsibility.
The same rule should apply to AI.
LLM does not need the whole project.
She needs a sufficient canonical context for a specific question or action.
Minimal sufficient knowledge
If an AI tool writes a Sekura JS module, it needs:
- module contract;
- available system interfaces;
- rules for working with streams;
- limitations of the execution environment;
- requirements for completion and release of resources;
- related language rules.
It is not necessary to transfer the entire processor design history to him.
If the tool analyzes the Memora8 engine, it needs the canons of ISA, pipeline, memory, and related hardware limitations.
It does not require the entire Reganta OS user layer.
If the LLM is preparing changes to the Firmware Kernel, it should receive the appropriate system contract and related canons.
But not a random archive of all project discussions.
Thus, the correct context is determined by the responsibility of the task.
Hiding information does not mean hiding meaning.
Sometimes the principle of Parnassus is taken too literally.
As if the component should hide absolutely everything from the rest.
But the goal is not to make the system opaque.
The goal is to separate stable knowledge from mutable implementation.
Other components must understand:
- what the module provides;
- what obligations does he fulfill;
- what are the limitations?;
- what can be considered guaranteed;
- what actions are acceptable.
But they should not depend on details that can change without changing the contract.
For Noda, this means that the canonical article must be clear.
She doesn't hide the meaning.
It hides unnecessary connectedness.
What happens when the architecture changes
Suppose the internal implementation of the Sekura system mechanism is changing.
If the contract remains the same, the articles of the external components should not be rewritten.
The canon responsible for the internal solution is being updated.
The linked articles continue to refer to the former contract.
If the contract itself changes, Noda should show the area of influence.:
- which articles depend on it;
- which modules use this commitment;
- which system components need to be checked;
- which AI instructions may become obsolete;
- which implementations should be reviewed.
In a regular archive, you have to search for such a dependency manually.
In the knowledge architecture, it must be explicit.
Boundaries protect conceptual integrity
At first glance, the division of knowledge can lead to fragmentation.
Each article exists separately.
Each component is responsible only for itself.
But properly defined boundaries, on the contrary, maintain integrity.
They allow you to understand exactly where the decision is being made.
Several competing sources of truth are excluded.
Reduce the number of accidental dependencies.
They allow you to change one part of the system without destroying the rest.
Conceptual integrity does not require that a single document contains the entire architecture.
It requires all parts to be subject to an agreed system of contracts and responsibilities.
The Parnassus Cycle for Noda and Sekura
During the development of Sekura, this approach can be presented as a separate engineering cycle.
Architectural solution → Definition of the area of responsibility → Canonical article in Noda → Contract with other components → Implementation → Dependency Checking → Change internal knowledge or revise the contract
The main question here is:
To whom should this knowledge belong?
If the same decision is described in several places, responsibility is blurred.
If an article defines several independent areas at the same time, its boundaries are too wide.
If you have to rewrite half of the database to change an internal detail, information concealment is violated.
If the LLM requires the entire archive to perform a local task, the knowledge architecture is not defined.
What questions should be asked when creating a canon?
Before approving an article, it is useful to check:
What decision does she fix?
Which component of Sekura does it belong to?
Who is the owner of this knowledge?
What is an external contract in the article?
What applies to the internal implementation?
What details can change without affecting neighboring components?
Which articles have the right to depend on this knowledge?
Which dependencies are undesirable?
What should an LLM know to apply this canon?
What information would be superfluous for this task?
Such questions turn documentation into an architectural system.
Noda as a system of information modules
In this approach, Noda becomes more than just a place to store approved articles.
It forms a modular domain model.
Each article represents a separate piece of responsibility.
Connections show contracts and dependencies.
The status determines which knowledge is valid.
Authorship secures the owner.
History preserves the development of the solution.
LLM receives only the set of canons that corresponds to the task being performed.
This is how the Parnassus principle begins to work on several levels at once.:
- in the Memora8 architecture;
- in the Reganta OS device;
- in Sekura JS contracts;
- in the separation of system and firmware modules;
- in the organization of canonical knowledge;
- in shaping the context for AI.
From software modules to AI tools
Today, LLM is increasingly not just answering questions.
She changes the code.
Creates modules.
Analyzes the architecture.
Prepares tests.
Updates the documentation.
It offers system solutions.
Such a tool becomes a participant in the architecture itself.
And for him, the principle of minimum responsibility is especially important.
AI must understand:
- what task does it perform?;
- what canons relate to this task?;
- which components are allowed to be modified;
- which contracts should not be violated;
- which internal details should not affect the decision;
- at which point it is necessary to stop.
If you give an AI unlimited access to all knowledge and the entire project, it will start making decisions beyond its responsibility.
Therefore, the boundaries of knowledge simultaneously become the boundaries of action.
Instead of output
David Parnas has shown that a complex system does not become manageable when it is simply broken down into small parts.
It becomes manageable when each part has a specific solution, and the internal details are hidden behind a stable contract.
In the LLM era, this principle becomes even more important.
It is not enough to create a canonical knowledge base.
We need to properly divide it into areas of responsibility.
An LLM should not receive all the documentation just because it is technically possible.
She should receive a minimum sufficient set of current knowledge for a specific task.
When developing Sekura, we see this principle in two forms at once.
Software modules should have clear contracts and responsibilities.
Canonical Noda articles should have the same boundaries.
Then the code and knowledge begin to obey the same architecture.
The component knows only what is necessary for its operation.
The article is responsible only for its own decision.
LLM gets only the relevant canonical context.
And the change of one detail ceases to spread uncontrollably throughout the system.
That is why the next stage of corporate AI development is not related to an increase in the volume of context.
It is related to the architecture of knowledge.
Not to give the model everything the company knows, but to give it the right knowledge within the right boundaries for the right task.
Когда компании начинают использовать большие языковые модели, одним из первых решений обычно становится подключение корпоративной документации.
Кажется, что логика проста.
Чем больше документов получит LLM, тем полнее будет ее ответ.
Нужно загрузить технические описания.
Регламенты.
Исходные требования.
Историю решений.
Проектные заметки.
Переписку.
Инструкции.
После этого модель якобы сможет отвечать на любые вопросы о системе.
На практике большое количество информации нередко ухудшает результат.
Модель получает несколько версий одного решения.
Смешивает внутренние детали разных компонентов.
Переносит ограничения одной подсистемы на другую.
Использует устаревший документ вместо действующего.
И делает выводы на основании информации, которая вообще не должна была участвовать в ответе.
Проблема заключается не только в качестве поиска.
Проблема заключается в архитектуре знаний.
Задолго до появления LLM об этом говорил Дэвид Парнас — один из основателей современной теории модульного проектирования.
Его идеи обычно связывают с программными модулями и сокрытием информации.
Но сегодня тот же принцип становится критически важным для корпоративных баз знаний и AI-систем.
Главная идея Парнаса
Распространенное представление о модульности выглядит просто.
Большую программу нужно разделить на небольшие части.
Каждая часть выполняет определенную функцию.
Так код становится удобнее разрабатывать и поддерживать.
Но Парнас предлагал более глубокий критерий разделения.
Модуль должен формироваться не просто вокруг этапа обработки или набора функций.
Он должен скрывать определенное архитектурное решение.
Каждый модуль отвечает за собственную область знания.
Внутренние детали могут меняться.
Но остальные части системы не должны зависеть от этих деталей напрямую.
Они должны взаимодействовать с модулем через устойчивый контракт.
Таким образом модульность — это не только разделение кода.
Это разделение ответственности и знания.
Почему обычное функциональное разделение недостаточно
Представим программу, разбитую на несколько последовательных этапов.
Один компонент получает данные.
Другой обрабатывает.
Третий сохраняет.
Формально система разделена на модули.
Но если все компоненты знают внутренний формат данных, особенности хранения и детали реализации друг друга, настоящей модульности нет.
Любое изменение начинает распространяться по всей системе.
Меняется формат — приходится менять несколько компонентов.
Меняется способ хранения — нарушаются зависимости.
Меняется внутреннее правило — обновляется множество участков кода.
Парнас предлагал скрывать решения, которые могут измениться.
Остальная система должна знать не внутреннее устройство, а контракт взаимодействия.
Это уменьшает область влияния каждого изменения.
Та же проблема существует в документации
Корпоративные знания часто организованы так же плохо, как немодульная программа.
Описание одного компонента встречается в десятках документов.
Ограничение архитектуры упоминается в техническом задании, протоколе встречи, инструкции и комментарии к задаче.
Интерфейс одного модуля объясняется через внутреннее устройство другого.
Причины решения смешиваются с подробностями реализации.
Черновые идеи находятся рядом с утвержденными правилами.
В результате невозможно определить:
- кто отвечает за конкретное знание;
- где находится его действующая формулировка;
- какие другие решения от него зависят;
- какие сведения являются внутренними;
- какой контракт должен оставаться стабильным;
- какие статьи нужно пересмотреть после изменения.
Такой архив может содержать огромное количество информации.
Но он не обладает архитектурой.
Почему это особенно опасно для LLM
Человек, давно работающий над проектом, часто способен мысленно отделить важное от второстепенного.
Он знает, какой документ устарел.
Помнит, какой вариант обсуждался, но не был принят.
Понимает, что определенное ограничение относится только к одному компоненту.
LLM такого неявного контекста не имеет.
Для нее каждый найденный фрагмент представляет собой потенциальный источник ответа.
Если в документах отсутствуют четкие границы ответственности, модель начинает самостоятельно собирать архитектуру из доступного текста.
Она может объединить факты, которые никогда не должны были использоваться вместе.
Может объяснить публичный контракт через временные детали реализации.
Может перенести правило одного уровня системы на другой.
Может принять локальное решение за принцип всей платформы.
Чем убедительнее модель рассуждает, тем труднее заметить ошибку.
Мы столкнулись с этим при разработке Sekura
При разработке платформы Sekura одновременно развиваются несколько связанных систем:
- процессор Memora8;
- операционная система Reganta OS;
- язык Sekura JS;
- Firmware Kernel;
- системные модули;
- модель исполнения потоков;
- компилятор и инструменты разработки.
Эти компоненты связаны между собой.
Но связь не означает, что все они должны знать внутреннее устройство друг друга.
Например, модуль Sekura JS должен понимать контракт исполнения, доступные механизмы обмена данными и правила завершения работы.
Но ему необязательно знать все детали реализации планирования внутри ядра.
Firmware Kernel должен предоставлять определенные системные возможности.
Но остальные компоненты не должны зависеть от случайных внутренних решений его текущей реализации.
Memora8 задает аппаратные ограничения.
Однако не каждая деталь процессора должна автоматически становиться частью контракта прикладного модуля.
Если эти границы не зафиксировать, архитектура быстро превращается в набор неявных зависимостей.
Изменение одного компонента начинает требовать пересмотра всей платформы.
Код можно разделить, а знания оставить связанными неправильно
Можно создать отдельные репозитории.
Разбить систему на каталоги.
Определить программные интерфейсы.
Но при этом сохранить знания в виде одного общего массива документов.
Тогда формальная модульность кода не решает проблему.
Разработчик по-прежнему не понимает:
- какая статья определяет контракт;
- где заканчивается ответственность компонента;
- какие сведения являются внутренними;
- какие зависимости считаются допустимыми;
- какое изменение влияет на соседние модули.
AI-инструмент оказывается в еще более сложном положении.
Он видит много текста, но не видит архитектурных границ.
Поэтому модульность должна существовать не только в коде.
Она должна существовать в базе знаний.
Такую задачу решает Noda
В Noda канонические статьи должны образовывать не архив, а архитектуру знаний.
Каждая статья отвечает за определенную область.
Она фиксирует:
- предмет знания;
- владельца решения;
- область применимости;
- установленный контракт;
- внутренние детали, если они действительно важны;
- связи с другими статьями;
- допустимые зависимости;
- ограничения;
- условия пересмотра.
Это позволяет перенести принцип Парнаса из программной архитектуры в архитектуру знаний.
Статья становится информационным модулем.
Она должна отвечать за конкретное решение и не размывать свою ответственность по всей базе.
Каноническая статья как модуль знания
Хорошую каноническую статью можно сравнить с хорошо спроектированным программным модулем.
У нее есть область ответственности.
Она скрывает лишние детали.
Предоставляет понятный контракт.
Определяет связи с соседними областями.
Допускает внутреннее развитие без разрушения всей системы знаний.
Например, статья о контракте системного модуля Sekura не должна превращаться в полное описание Firmware Kernel, Memora8 и всей Reganta OS.
Она должна объяснять именно то, что обязан знать автор системного модуля:
- как модуль запускается;
- какие системные возможности ему доступны;
- как он взаимодействует с потоками;
- как освобождает вычислительный ресурс;
- какие действия разрешены;
- какие гарантии предоставляет среда исполнения.
Внутреннее устройство механизмов может быть описано в других канонических статьях.
Между ними создаются явные связи.
Так знания остаются связанными, но не смешиваются.
Не весь контекст одинаково полезен
Современные LLM поддерживают большие контекстные окна.
Из этого иногда делают вывод, что модели можно передать всю документацию проекта.
Но техническая возможность поместить данные в контекст еще не означает, что это правильное архитектурное решение.
Лишний контекст создает риски:
- важное знание теряется среди второстепенного;
- внутренние детали начинают конкурировать с контрактом;
- устаревшие сведения влияют на вывод;
- повышается вероятность ложных связей;
- сложнее определить источник ответа;
- модель получает информацию за пределами своей задачи.
В архитектуре Парнаса компонент должен получать только те знания, которые необходимы для выполнения его ответственности.
То же правило должно действовать для AI.
LLM не нужен весь проект.
Ей нужен достаточный канонический контекст для конкретного вопроса или действия.
Минимально достаточное знание
Если AI-инструмент пишет модуль Sekura JS, ему нужны:
- контракт модуля;
- доступные системные интерфейсы;
- правила работы с потоками;
- ограничения среды исполнения;
- требования к завершению и освобождению ресурсов;
- связанные правила языка.
Ему не обязательно передавать всю историю проектирования процессора.
Если инструмент анализирует механизм Memora8, ему нужны каноны ISA, конвейера, памяти и связанных аппаратных ограничений.
Ему не требуется весь пользовательский уровень Reganta OS.
Если LLM готовит изменения Firmware Kernel, она должна получить соответствующий системный контракт и связанные каноны.
Но не случайный архив всех обсуждений проекта.
Таким образом правильный контекст определяется ответственностью задачи.
Сокрытие информации не означает сокрытие смысла
Иногда принцип Парнаса понимают слишком буквально.
Будто компонент должен скрывать от остальных абсолютно все.
Но цель заключается не в том, чтобы сделать систему непрозрачной.
Цель — отделить стабильное знание от изменяемой реализации.
Другие компоненты должны понимать:
- что предоставляет модуль;
- какие обязательства он выполняет;
- какие ограничения существуют;
- что можно считать гарантированным;
- какие действия допустимы.
Но они не должны зависеть от деталей, которые могут измениться без изменения контракта.
Для Noda это означает, что каноническая статья должна быть понятной.
Она не прячет смысл.
Она скрывает ненужную связанность.
Что происходит при изменении архитектуры
Предположим, меняется внутренняя реализация системного механизма Sekura.
Если контракт остается прежним, статьи внешних компонентов не должны переписываться.
Обновляется канон, отвечающий за внутреннее решение.
Связанные статьи продолжают ссылаться на прежний контракт.
Если же меняется сам контракт, Noda должна показать область влияния:
- какие статьи от него зависят;
- какие модули используют это обязательство;
- какие системные компоненты нужно проверить;
- какие AI-инструкции могут стать устаревшими;
- какие реализации должны быть пересмотрены.
В обычном архиве такую зависимость приходится искать вручную.
В архитектуре знаний она должна быть явной.
Границы защищают концептуальную целостность
На первый взгляд разделение знаний может привести к фрагментации.
Каждая статья существует отдельно.
Каждый компонент отвечает только за себя.
Но правильно определенные границы, наоборот, поддерживают целостность.
Они позволяют понимать, где именно принимается решение.
Исключают несколько конкурирующих источников истины.
Уменьшают число случайных зависимостей.
Позволяют изменять одну часть системы, не разрушая остальные.
Концептуальная целостность не требует, чтобы один документ содержал всю архитектуру.
Она требует, чтобы все части подчинялись согласованной системе контрактов и ответственности.
Цикл Парнаса для Noda и Sekura
При развитии Sekura этот подход можно представить как отдельный инженерный цикл.
Архитектурное решение → Определение области ответственности → Каноническая статья в Noda → Контракт с другими компонентами → Реализация → Проверка зависимостей → Изменить внутреннее знание или пересмотреть контракт
Здесь главный вопрос звучит так:
Кому должно принадлежать это знание?
Если одно и то же решение описывается в нескольких местах, ответственность размыта.
Если статья одновременно определяет несколько независимых областей, ее границы слишком широки.
Если для изменения внутренней детали приходится переписывать половину базы, сокрытие информации нарушено.
Если LLM требуется весь архив для выполнения локальной задачи, архитектура знаний не определена.
Какие вопросы нужно задавать при создании канона
Перед утверждением статьи полезно проверить:
Какое решение она фиксирует?
К какому компоненту Sekura оно относится?
Кто является владельцем этого знания?
Что в статье является внешним контрактом?
Что относится к внутренней реализации?
Какие детали могут измениться без влияния на соседние компоненты?
Какие статьи имеют право зависеть от этого знания?
Какие зависимости являются нежелательными?
Что должна знать LLM для применения этого канона?
Какая информация для данной задачи будет лишней?
Такие вопросы превращают документацию в архитектурную систему.
Noda как система информационных модулей
Noda в этом подходе становится не просто местом хранения утвержденных статей.
Она формирует модульную модель предметной области.
Каждая статья представляет отдельный фрагмент ответственности.
Связи показывают контракты и зависимости.
Статус определяет, какое знание действует.
Авторство закрепляет владельца.
История сохраняет развитие решения.
LLM получает только тот набор канонов, который соответствует выполняемой задаче.
Так принцип Парнаса начинает работать сразу на нескольких уровнях:
- в архитектуре Memora8;
- в устройстве Reganta OS;
- в контрактах Sekura JS;
- в разделении системных и firmware-модулей;
- в организации канонических знаний;
- в формировании контекста для AI.
От программных модулей к AI-инструментам
Сегодня LLM все чаще не просто отвечает на вопросы.
Она изменяет код.
Создает модули.
Анализирует архитектуру.
Готовит тесты.
Обновляет документацию.
Предлагает системные решения.
Такой инструмент сам становится участником архитектуры.
И для него принцип минимальной ответственности особенно важен.
AI должен понимать:
- какую задачу он выполняет;
- какие каноны относятся к этой задаче;
- какие компоненты разрешено изменять;
- какие контракты нельзя нарушать;
- какие внутренние детали не должны влиять на решение;
- в какой момент необходимо остановиться.
Если дать AI неограниченный доступ ко всему знанию и всему проекту, он начнет принимать решения за пределами своей ответственности.
Поэтому границы знаний одновременно становятся границами действий.
Вместо вывода
Дэвид Парнас показал, что сложная система становится управляемой не тогда, когда ее просто разбивают на небольшие части.
Она становится управляемой тогда, когда каждой части принадлежит определенное решение, а внутренние детали скрыты за устойчивым контрактом.
В эпоху LLM этот принцип становится еще важнее.
Недостаточно создать каноническую базу знаний.
Нужно правильно разделить ее на области ответственности.
LLM не должна получать всю документацию только потому, что это технически возможно.
Она должна получать минимально достаточный набор действующих знаний для конкретной задачи.
При разработке Sekura мы видим этот принцип сразу в двух формах.
Программные модули должны иметь ясные контракты и границы ответственности.
Канонические статьи Noda должны иметь такие же границы.
Тогда код и знания начинают подчиняться одной архитектуре.
Компонент знает только то, что необходимо для его работы.
Статья отвечает только за собственное решение.
LLM получает только релевантный канонический контекст.
А изменение одной детали перестает бесконтрольно распространяться по всей системе.
Именно поэтому следующий этап развития корпоративного AI связан не с увеличением объема контекста.
Он связан с архитектурой знания.
Не дать модели все, что знает компания, а дать ей правильное знание в правильных границах для правильной задачи.
Share
