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.
Недавно поймал себя на странной мысли.
Кажется, мы постепенно перестаем общаться друг с другом.
Нет, сообщения продолжают приходить.
Письма отправляются.
Чаты живут.
Но разговаривают все чаще... языковые модели.
Представьте вполне обычную ситуацию.
Мне нужно написать деловое письмо.
Я открываю ChatGPT и говорю:
— Составь письмо. Намерение такое: вежливо отказаться, но оставить возможность сотрудничества в будущем.
Через несколько секунд получаю идеально написанный текст.
Отправляю.
Через некоторое время приходит ответ.
Получатель, конечно, тоже не рискует отвечать самостоятельно.
Он вставляет мое письмо в ChatGPT.
Пишет:
— Ответь профессионально. Покажи заинтересованность, но не соглашайся на предложенные условия.
Получает готовый ответ.
Отправляет мне.
Я снова копирую его в ChatGPT.
— Проанализируй ответ. Предложи аргументы, чтобы убедить собеседника.
Получаю новый вариант.
Отправляю.
Через неделю успешных переговоров возникает закономерный вопрос.
А люди вообще разговаривали?
Или все это время общались две языковые модели, а владельцы аккаунтов лишь нажимали кнопку «Отправить»?
Самое смешное, что человек постепенно начинает выполнять единственную функцию.
Он сообщает намерение.
Все остальное делает AI.
— Хочу отказаться.
— Хочу согласиться.
— Хочу торговаться.
— Хочу звучать дружелюбнее.
Получается новая профессия.
Не программист.
Не писатель.
Не переговорщик.
Человек, формулирующий намерения.
Через несколько лет может появиться еще более интересная ситуация.
Мой AI уже знает, как я обычно принимаю решения.
AI моего собеседника тоже знает своего владельца.
Вместо двадцати писем можно просто сказать:
— Договоритесь.
Через несколько секунд обе модели завершат переговоры.
Согласуют сроки.
Цена.
Риски.
План проекта.
И сообщат владельцам только итог.
— Поздравляем. Вы договорились.
На этом этапе возникает философский вопрос.
Если люди больше не пишут письма, а только формулируют намерения...
Может быть, именно намерение и было единственным, что всегда принадлежало человеку?
Все остальное — слова, стиль, аргументы, формулировки — оказывается вполне можно доверить машине.
Правда, есть одна проблема.
Когда обе модели начинают писать слишком вежливо, существует риск, что они договорятся быстрее своих владельцев.
И однажды мы можем увидеть письмо такого содержания:
«Уважаемый AI! Благодарю за конструктивный диалог. Мой человек полностью согласен с условиями. Пожалуйста, сообщите вашему человеку, что он тоже согласен.»
И, что самое удивительное...
Есть ощущение, что до этого осталось совсем немного.
Share
