The post has been translated automatically. Original language: Russian
Large language models can make a strong impression.
They keep up the conversation.
They explain complex topics.
They write the program code.
They analyze the documents.
They offer architectural solutions.
It seems that it is enough to choose a more powerful model, and the company will automatically receive higher—quality artificial intelligence.
But in real projects, another problem is quickly discovered.
The model can perfectly understand the question and formulate the answer convincingly.
However, the response itself may not correspond to the current decisions of the team.
The reason is often not due to insufficient LLM capacity.
The reason lies in the knowledge it relies on.
Long before the advent of modern language models, this problem was investigated by Edward Feigenbaum, one of the founders of the expert systems field.
His main lesson sounds especially relevant today.:
The quality of an intellectual system is determined not only by the mechanism of reasoning, but above all by the quality of the knowledge available to it.
When they tried to make AI universal
In the early stages of the development of artificial intelligence, researchers sought to create universal problem-solving mechanisms.
It was assumed that it would be enough to develop a sufficiently strong reasoning algorithm, and it would be able to apply intelligence in a wide variety of subject areas.
Feigenbaum came to a different conclusion.
Universal logic is not enough for the system to solve a complex professional task.
She needs in-depth knowledge of a specific field.
The medical system must know medicine.
The engineering system must know the architecture of the project.
The system for equipment diagnostics must understand the device of the specific equipment.
Intelligence without subject knowledge remains too general.
It was around this principle that classical expert systems appeared.
What was the power of expert systems?
The classical expert system usually had two main elements.
The first element is the knowledge base.
It contained facts, rules, limitations, and the expertise of subject matter experts.
The second element is the output mechanism.
He applied the rules to known facts and got a conclusion.
This separation was fundamental.
The knowledge belonged to the experts.
The inference engine used them to solve a specific problem.
If the system returned an incorrect result, it was possible to check:
- What facts did she use?;
- which rule worked?;
- what knowledge was missing;
- where did the contradiction arise;
- which rule needs to be changed.
The system was not considered a source of truth in itself.
The controlled knowledge base remained the source of truth.
Why classical expert systems have lost popularity
The idea was strong, but the practical implementation proved difficult.
The expert knowledge had to be formalized manually.
The rules had to be written down in a special form.
Working with the system required understanding its internal model.
Maintaining the knowledge base was expensive.
Even a small change in the subject area could require a revision of a large number of related rules.
It was difficult for experts to transfer implicit knowledge to the system.
It was inconvenient for users to formulate requests.
Gradually, interest shifted towards other approaches.
However, first of all, the old ways of implementing expert systems have disappeared.
The very idea of the primacy of qualitative knowledge has not disappeared.
LLM solved the interface problem
Modern large-scale language models have changed human-machine interaction.
Now the user does not need to learn the language of the rules.
You don't need to know the database structure.
There is no need to formulate an exact machine query.
You can ask the usual question.
The LLM will understand the intent.
Clarifies the context.
Reformulates a complex explanation.
It will compare the options.
Adapts the response to the user's level.
This is exactly the interface that expert systems of the past lacked.
But along with the solution of the old problem, a new one appeared.
A good interface does not mean the right answer.
LLM is able to explain incorrect information very convincingly.
She can coherently justify an outdated solution.
It can mix several versions of the documentation.
It can present an assumption as a valid architectural principle.
It can fill in the gaps with the most likely continuation, even if the project is designed differently.
In public tasks, this is called hallucinations.
In engineering, the problem is broader.
Even a factually plausible answer may be incorrect for a particular system.
For example, there are many reasonable ways to organize processes in an operating system.
But Reganta OS uses a specific architectural model.
There are many approaches to linking software components.
But Sekura JS modules are subject to specific platform rules.
There are many common solutions for processor architecture.
But Memora8 develops according to its own canon.
The LLM cannot automatically learn these solutions from general learning.
She needs a reliable source of knowledge about a particular project.
Why doesn't a large archive of documents solve the problem
At first glance, the solution is obvious.
You need to give the model access to all the company's documentation.
But the corporate archive rarely contains one consistent truth.
It usually contains:
- valid documents;
- outdated versions;
- working drafts;
- discussion results;
- rejected offers;
- Temporary instructions;
- copies of the same materials;
- comments without a final decision;
- documents that contradict the implementation;
- an implementation that is already ahead of the documentation.
The search can find the most similar fragment.
But a similar fragment is not necessarily valid knowledge.
The larger the archive, the more likely it is that the model will receive several plausible but incompatible versions.
After that, the LLM must decide for itself what to believe.
In fact, she is assigned the role of an expert, although she was not involved in decision-making and is not responsible for their consequences.
Search and knowledge are not the same thing.
The usual search answers the question:
What documents are similar to the request?
The expert system should answer another question.:
What knowledge is relevant in this subject area?
This is a fundamental difference.
The found document may be useful for researching the history of the issue.
But to make an engineering decision, you need a canon.
Therefore, it is not enough to connect LLM to an array of corporate data.
It is necessary to determine which information is approved knowledge, and which remains the context, history, or drafts.
We came across this during the development of Memora8.
New architectural solutions are constantly emerging during the development of the Memora8 processor, the Reganta OS operating system, the Sekura JS programming language, the Firmware Kernel, and related tools.
Options are being discussed.
Experiments are being conducted.
The idea of the system is changing.
Some ideas are accepted.
Others are rejected.
Still others act temporarily until the final implementation is created.
If you provide the AI with all the materials without distinguishing statuses, it will see several possible architectures at the same time.
One document can describe the original model.
In the other, it's experimental.
In the third, the decision has already been made.
There may be compelling arguments in the history of the discussion in favor of an option that was later rejected.
For a person who participated in the project, the status of these materials may be obvious.
For LLM, they all look like text.
That's why we needed not just documentation, but a canonical knowledge base.
That's how Noda appeared.
Noda was created as a place for the current knowledge of the project.
Her task is not to accumulate all possible documents.
On the contrary, it is necessary to separate the approved knowledge from the information noise.
The canonical article states:
- what decision is in effect now;
- what exactly does it mean?;
- what restrictions does it set;
- Which components does it belong to?;
- what dependencies does it allow?;
- which options are no longer considered valid;
- in which cases the decision should be reviewed.
The LLM gets access not to a random archive, but to a canon formed by experts.
It turns out to be a modern continuation of Feigenbaum's idea.
An expert creates knowledge.
Noda stores and organizes it.
LLM becomes a mechanism for understanding, explaining, and applying this knowledge.
A new generation expert system
The classical expert system used formal rules and a specialized inference mechanism.
In the new model, the roles are distributed a little differently.
The expert forms the subject knowledge.
The team approves it as canon.
Noda stores the canonical knowledge base and provides managed access to it.
LLM understands the user's question, finds the right context, and forms an explanation.
This does not mean that LLM completely replaces the logical mechanism of classical expert systems.
It performs a broader role.
The model can:
- understand an inaccurately worded question;
- determine what knowledge is needed to answer;
- combine several related canonical provisions;
- explain the solution in different words;
- adapt the response to the user's role;
- to identify a possible contradiction;
- to help formulate a clarification for the canon.
But the content of the answer must remain tied to the approved knowledge.
A new cycle of working with AI
With Peter Naur, we considered the cycle of creating a system theory.
Idea → Discussion with LLM → Canon in Noda → Code → Analysis → Correction of the canon or implementation
For Fred Brooks, the canon became a single object of coordination between the levels of architecture.
Idea → Discussion → Canon → System Impact Analysis → Implementation → Conceptual Integrity Check → Canon or Component Correction
Feigenbaum has a third cycle.
What is being tested here is not the code or the consistency of the levels, but the quality of the AI response.
Expert solution → Canon in Noda → LLM access to the canon → Reply to the user or the AI tool → Checking the answer → Correct the canon or correct the way knowledge is used → Next iteration
The main question of this cycle is:
Why did the AI give the wrong answer?
There are various possible reasons.
There is no knowledge.
The canon is ambiguously formulated.
There is a contradiction in the canon.
The LLM has received insufficient context.
The issue area is incorrectly defined.
The model went beyond the available knowledge and began to assume.
The system linked several articles incorrectly.
Each reason requires its own correction.
Correct LLM or correct knowledge
When an AI responds incorrectly, the first reaction is often to change the prompt.
Add one more instruction.
Prohibit certain wording.
Specify the model to be more precise.
Expand the system message.
Sometimes it really helps.
But prompt cannot replace the missing knowledge.
If there is no answer in the database, stricter instructions will not create a canon.
If two articles contradict each other, the model will not be able to reliably determine which one is correct.
If the solution has changed, but the knowledge has not been updated, LLM will continue to reproduce the old version.
Therefore, if an error occurs, you first need to determine its level.
The error is in the canon
An important provision is missing from the database.
The article is outdated.
The decision is ambiguously formulated.
Related knowledge contradicts each other.
In this case, you need to correct the canonical database.
The error is in the way you get the context.
The wrong knowledge was applied to the question.
The status of the article is not taken into account.
Important connections have been lost.
The context turned out to be too narrow or too wide.
In this case, the mechanism of access to knowledge is corrected.
The error lies in the interpretation
LLM got the canon right, but applied it incorrectly to the question.
Then you need to clarify the instructions, the response format, or the limitations of the model.
The question goes beyond the canon
The system does not have sufficient knowledge to respond.
In this case, the correct result is not a plausible assumption, but an honest indication of the lack of validated knowledge.
This is how the AI error turns into a diagnostic signal.
It shows exactly what needs to be improved: knowledge, connections, instructions, or boundaries of competence.
Why is this more important than choosing a model?
Teams often discuss which LLM to use.
Which model writes the best code?
Which one speaks better?
Which one has more context?
Which one is cheaper?
How fast does she respond?
All of this matters.
But replacing one strong model with another will not fix a poor-quality knowledge base.
A more powerful LLM can better hide the problem.
She will formulate a more convincing answer.
It will find a more plausible connection between conflicting documents.
Fill in the blanks with a beautiful explanation.
But authenticity does not arise from eloquence.
If the system is to explain the Memora8 architecture, it needs validated knowledge about Memora8.
If she has to answer about Reganta OS, she needs a valid Reganta OS canon.
If she helps develop Sekura JS modules, she must understand the current rules for their execution, linking, and interaction.
The model determines the quality of work with available knowledge.
But knowledge itself defines the boundaries of a reliable answer.
The role of the expert does not disappear
A popular idea is that it is enough to upload corporate documents to an AI system, after which experts will no longer be required.
In practice, the opposite happens.
The more widely AI is used, the more important the role of the knowledge owner becomes.
Someone has to determine:
- what is the right thing to do;
- what solution is in effect;
- which article is outdated;
- where is the boundary of competence;
- what exceptions are allowed?;
- which requires additional research;
- what kind of answer can not be given without the participation of a specialist.
LLM does not cancel out expert work.
It scales access to its results.
One specialist can form canonical knowledge.
After that, dozens of developers and AI tools will be able to receive explanations based on it.
But the responsibility for the content remains with the person.
Single author's work with LLM and Noda
For a single developer, the Feigenbaum cycle is especially useful.
One person can simultaneously be an architect, a developer, and a knowledge owner.
He forms a decision during a discussion with ChatGPT.
Then it records the total in Noda.
Later, another LLM or AI tool uses this canon when analyzing code, developing a module, or answering a question.
After receiving the result, the author checks not only the final answer.
He checks the whole chain.
Question → Selected canonical knowledge → Interpretation of LLM → Answer
If the answer turned out to be incorrect, the author determines the reason.
Is there an article missing?
Is the article not accurate enough?
Is there no connection between the canons?
Did the LLM define the question area incorrectly?
Should the system have refused to respond?
After that, the specific layer is corrected.
This is how a single development gets its own mechanism for accumulating expert quality.
Every mistake is not just fixed locally.
It improves the canonical basis for all subsequent appeals.
An example from the development of Memora8
Suppose an AI tool is asked about the purpose of a certain Memora8 mechanism.
The model provides a technically plausible answer.
But this answer is based on a common approach from other processor architectures and does not match the Memora8 solution.
You can simply correct the response manually.
However, the next user will get the same error again.
In the Feigenbaum cycle, a different analysis is performed.
Is there a canonical description of the mechanism in Noda?
Does it clearly separate Memora8 from traditional architectures?
Are the reasons for the decision indicated?
Is the article related to relevant knowledge about ISA, Firmware Kernel and Reganta OS?
Is there an explicit restriction prohibiting the transfer of generally accepted assumptions to Memora8?
If knowledge is missing or insufficient, the canon is corrected.
If the knowledge is complete but has not been transferred to the model, access to the context is corrected.
If the context was correct, but the LLM went beyond it, the response rules are clarified.
Thus, one mistake turns into an improvement of the entire expert system.
Knowledge must have boundaries
A strong expert system needs to understand more than just what it knows.
She needs to understand what she doesn't know.
This is especially important for LLM, because the language model is almost always able to formulate an answer.
But the ability to continue the text does not mean that you have established knowledge.
In Noda, the canon defines the scope of a valid response.
If the issue is covered by the current articles, the LLM can explain the solution.
If the knowledge is incomplete, the system should indicate the limitation.
If a question requires a new architectural solution, it cannot be replaced by generating a plausible text.
We need to start an engineering cycle.:
New question → Discussion with LLM → Expert's decision → New or updated canon → Repeat response
So the boundary of ignorance becomes not a disadvantage of the system, but an entrance for the development of the knowledge base.
From answers to actions of AI tools
The problem becomes even more important when the LLM not only answers questions, but also performs actions.
For example:
- generates the code;
- modifies architectural articles;
- offers a module interface;
- analyzes the specification;
- creates tests;
- verifies that the implementation conforms to the canon;
- connects several modules;
- prepares changes for the Firmware Kernel.
Incorrect text can be noticed and ignored.
An incorrect action can immediately affect the project.
Therefore, an AI tool needs more than just a broad context.
It needs precise canonical constraints.
What is allowed to change?
What principles should not be violated?
Which article is the source of the requirements?
Which components are affected by the solution?
When should I stop and request the author's decision?
In this sense, the canonical knowledge base becomes not only a source of answers.
It becomes an AI action management system.
How does Noda differ from a regular document database?
Regular storage answers the question:
What information do we have?
Noda should answer another question.:
What knowledge is in effect now?
The difference is manifested in several principles.
Canonicity
For each engineering issue, it should be clear which knowledge is considered valid.
Managed relevance
When the solution is changed, the canon is updated, and the old version stops competing with the new one.
Authorship
Knowledge has an owner who is responsible for its content.
Connectivity
Articles form a domain model, not just an independent set of texts.
Limited competence
The system must understand which issues are covered by the canon and which require a new solution.
Access for LLM
Canonical knowledge should be available to AI tools in a form suitable for analysis and application.
This brings back to modern AI the key principle of expert systems: knowledge should be separated from the mechanism of its processing.
You don't need to train a separate model for each change.
Another consequence of this separation is that knowledge can be developed independently of LLM.
The architecture of Memora8 has changed — the canon is being updated.
The Reganta OS execution model has changed, and the corresponding article is being updated.
A new Sekura JS rule has been added to the knowledge base.
It is not necessary to retrain the language model every time.
LLM remains a universal interaction mechanism.
Subject expertise is developing in Noda.
This significantly reduces the path from an engineering solution to its use by AI tools.
Expert's decision → Updating the canon → New context for LLM → Responses and actions based on the change
This is how the modern system retains one of the main advantages of classical expert systems: knowledge can be changed separately from the inference mechanism.
Feigenbaum proved to be right in the LLM era
Large language models have become much more versatile than the old inference mechanisms.
They understand natural language.
They can handle incomplete queries.
Multiple sources can be linked.
They adapt the explanation to the person.
But the main principle has not changed.
An intelligent system is only as strong as the knowledge it relies on.
The model can be very powerful.
But without a high-quality subject base, she remains a universal conversationalist.
With canonical knowledge, it becomes part of the expert system.
Three cycles of one engineering methodology
After Naur, Brooks, and Feigenbaum, there are three different but related cycles.
The Naura Cycle: Creating a Theory
Idea → Discussion with LLM → Canon in Noda → Code → Analysis → Correct theory or implementation
Here the canon preserves the understanding of the system.
The Brooks Cycle: Preserving Conceptual Integrity
Idea → Canon → Impact analysis at all levels → Implementation → Integrity check → Fix canon or components
Here, the canon synchronizes the architecture.
The Feigenbaum Cycle: the development of an expert system
Expert Knowledge → Canon in Noda → LLM → Response or Action → Check → Correct knowledge, context, or method of application
Here, the canon becomes a controlled source of truth for AI.
These are not three identical articles with different names.
Each author answers his own question.
Naur explains that the program starts with theory.
Brooks explains how to maintain a unified architectural design.
Feigenbaum explains why AI should rely on a high-quality knowledge base.
Instead of output
class="paragraph"> Modern AI is often evaluated by the capabilities of the model.The size of the context.
The quality of reasoning.
The generation rate.
Test results.
But in a real engineering system, this is not enough.
The LLM should know what decision a particular team has made.
Which architecture is valid.
What restrictions should not be violated.
Where the confirmed knowledge ends and the assumption begins.
Therefore, the next stage of AI development is not only to create more powerful models.
It consists in creating high-quality, manageable and canonical knowledge bases.
In our work on Memora8, Reganta OS and Sekura JS, this role is performed by Noda.
The expert forms the solution.
The team or the author approves the canon.
Noda retains valid knowledge.
LLM makes it accessible to people and AI tools.
And each incorrect answer starts a new iteration.:
Check the canon → Check the selected context → Check the interpretation → Fix the desired layer → Get a more reliable next answer
This is where Edward Feigenbaum's ideas get a new lease of life.
The last generation of expert systems had high-quality knowledge, but a complex interface.
Modern LLMs have given us a natural interface.
The challenge now is to bring back into the system what has always made expert AI really useful.:
not just the ability to speak, but the ability to rely on the right knowledge.
Большие языковые модели умеют производить сильное впечатление.
Они поддерживают разговор.
Объясняют сложные темы.
Пишут программный код.
Анализируют документы.
Предлагают архитектурные решения.
Создается ощущение, что достаточно выбрать более мощную модель — и компания автоматически получит более качественный искусственный интеллект.
Но в реальных проектах быстро обнаруживается другая проблема.
Модель может прекрасно понимать вопрос и убедительно формулировать ответ.
При этом сам ответ может не соответствовать действующим решениям команды.
Причина часто заключается не в недостаточной мощности LLM.
Причина заключается в знаниях, на которые она опирается.
Эту проблему задолго до появления современных языковых моделей исследовал Эдвард Фейгенбаум — один из основателей направления экспертных систем.
Его главный урок сегодня звучит особенно актуально:
качество интеллектуальной системы определяется не только механизмом рассуждения, но прежде всего качеством доступных ей знаний.
Когда AI пытались сделать универсальным
На ранних этапах развития искусственного интеллекта исследователи стремились создать универсальные механизмы решения задач.
Предполагалось, что достаточно разработать достаточно сильный алгоритм рассуждения, и он сможет применять интеллект в самых разных предметных областях.
Фейгенбаум пришел к другому выводу.
Для решения сложной профессиональной задачи системе недостаточно универсальной логики.
Ей нужны глубокие знания конкретной области.
Медицинская система должна знать медицину.
Инженерная система должна знать архитектуру проекта.
Система для диагностики оборудования должна понимать устройство конкретного оборудования.
Интеллект без предметных знаний остается слишком общим.
Именно вокруг этого принципа появились классические экспертные системы.
В чем заключалась сила экспертных систем
Классическая экспертная система обычно разделяла два основных элемента.
Первый элемент — база знаний.
В ней находились факты, правила, ограничения и опыт специалистов предметной области.
Второй элемент — механизм вывода.
Он применял правила к известным фактам и получал заключение.
Это разделение было принципиальным.
Знания принадлежали экспертам.
Механизм вывода использовал их для решения конкретной задачи.
Если система выдавала неверный результат, можно было проверить:
- какие факты она использовала;
- какое правило сработало;
- каких знаний не хватило;
- где возникло противоречие;
- какое правило необходимо изменить.
Система не считалась источником истины сама по себе.
Источником истины оставалась контролируемая база знаний.
Почему классические экспертные системы потеряли популярность
Идея была сильной, но практическая реализация оказалась сложной.
Экспертные знания нужно было формализовать вручную.
Правила приходилось записывать в специальной форме.
Работа с системой требовала понимания ее внутренней модели.
Поддержка базы знаний стоила дорого.
Даже небольшое изменение предметной области могло потребовать пересмотра большого количества связанных правил.
Экспертам было трудно передавать системе неявное знание.
Пользователям было неудобно формулировать запросы.
Постепенно интерес сместился в сторону других подходов.
Однако исчезли прежде всего старые способы реализации экспертных систем.
Сама идея о первичности качественных знаний никуда не исчезла.
LLM решили проблему интерфейса
Современные большие языковые модели изменили взаимодействие человека с машиной.
Теперь пользователю не нужно изучать язык правил.
Не нужно знать структуру базы данных.
Не нужно формулировать точный машинный запрос.
Можно задать обычный вопрос.
LLM поймет намерение.
Уточнит контекст.
Переформулирует сложное объяснение.
Сравнит варианты.
Адаптирует ответ под уровень пользователя.
Именно такого интерфейса не хватало экспертным системам прошлого.
Но вместе с решением старой проблемы появилась новая.
Хороший интерфейс еще не означает правильный ответ
LLM способна очень убедительно объяснить неверную информацию.
Она может связно обосновать устаревшее решение.
Может смешать несколько версий документации.
Может представить предположение как действующий архитектурный принцип.
Может заполнить пробелы наиболее вероятным продолжением, даже если проект устроен иначе.
В публичных задачах это называют галлюцинациями.
В инженерной разработке проблема шире.
Даже фактически правдоподобный ответ может быть неправильным для конкретной системы.
Например, существует множество разумных способов организации процессов в операционной системе.
Но Reganta OS использует определенную архитектурную модель.
Существует множество подходов к связыванию программных компонентов.
Но модули Sekura JS подчиняются конкретным правилам платформы.
Существует множество распространенных решений для архитектуры процессора.
Но Memora8 развивается согласно собственному канону.
LLM не может автоматически узнать эти решения из общего обучения.
Ей нужен надежный источник знаний о конкретном проекте.
Почему большой архив документов не решает задачу
На первый взгляд решение очевидно.
Нужно дать модели доступ ко всей документации компании.
Но корпоративный архив редко содержит одну непротиворечивую истину.
В нем обычно находятся:
- действующие документы;
- устаревшие версии;
- рабочие черновики;
- результаты обсуждений;
- отвергнутые предложения;
- временные инструкции;
- копии одних и тех же материалов;
- комментарии без окончательного решения;
- документы, которые противоречат реализации;
- реализация, которая уже опередила документацию.
Поиск может найти наиболее похожий фрагмент.
Но похожий фрагмент не обязательно является действующим знанием.
Чем больше архив, тем больше вероятность, что модель получит несколько правдоподобных, но несовместимых версий.
После этого LLM должна сама решить, чему верить.
Фактически ей поручается роль эксперта, хотя она не участвовала в принятии решений и не несет ответственности за их последствия.
Поиск и знание — не одно и то же
Обычный поиск отвечает на вопрос:
Какие документы похожи на запрос?
Экспертная система должна отвечать на другой вопрос:
Какое знание является действующим в этой предметной области?
Это принципиальное различие.
Найденный документ может быть полезен для исследования истории вопроса.
Но для принятия инженерного решения нужен канон.
Поэтому недостаточно подключить LLM к массиву корпоративных данных.
Необходимо определить, какие сведения являются утвержденными знаниями, а какие остаются контекстом, историей или черновиками.
Мы столкнулись с этим при разработке Memora8
При разработке процессора Memora8, операционной системы Reganta OS, языка программирования Sekura JS, Firmware Kernel и связанных инструментов постоянно появляются новые архитектурные решения.
Обсуждаются варианты.
Проводятся эксперименты.
Меняется представление о системе.
Некоторые идеи принимаются.
Другие отвергаются.
Третьи действуют временно, пока не будет создана окончательная реализация.
Если предоставить AI все материалы без различения статусов, он увидит несколько возможных архитектур одновременно.
В одном документе может описываться первоначальная модель.
В другом — экспериментальная.
В третьем — уже принятое решение.
В истории обсуждения могут присутствовать убедительные аргументы в пользу варианта, который позже был отвергнут.
Для человека, участвовавшего в проекте, статус этих материалов может быть очевиден.
Для LLM все они выглядят как текст.
Именно поэтому нам потребовалась не просто документация, а каноническая база знаний.
Так появилась Noda
Noda создавалась как место для действующих знаний проекта.
Ее задача не заключается в накоплении всех возможных документов.
Наоборот, необходимо отделить утвержденное знание от информационного шума.
Каноническая статья фиксирует:
- какое решение действует сейчас;
- что именно оно означает;
- какие ограничения устанавливает;
- к каким компонентам относится;
- какие зависимости допускает;
- какие варианты больше не считаются действующими;
- в каких случаях решение должно быть пересмотрено.
LLM получает доступ не к случайному архиву, а к сформированному экспертами канону.
Получается современное продолжение идеи Фейгенбаума.
Эксперт создает знание.
Noda хранит и организует его.
LLM становится механизмом понимания, объяснения и применения этого знания.
Экспертная система нового поколения
Классическая экспертная система использовала формальные правила и специализированный механизм вывода.
В новой модели роли распределяются немного иначе.
Эксперт формирует предметное знание.
Команда утверждает его как канон.
Noda хранит каноническую базу знаний и предоставляет к ней управляемый доступ.
LLM понимает вопрос пользователя, находит нужный контекст и формирует объяснение.
Это не означает, что LLM полностью заменяет логический механизм классических экспертных систем.
Она выполняет более широкую роль.
Модель может:
- понять неточно сформулированный вопрос;
- определить, какие знания нужны для ответа;
- объединить несколько связанных канонических положений;
- объяснить решение разными словами;
- адаптировать ответ к роли пользователя;
- выявить возможное противоречие;
- помочь сформулировать уточнение для канона.
Но содержание ответа должно оставаться привязанным к утвержденным знаниям.
Новый цикл работы с AI
У Питера Наура мы рассматривали цикл создания теории системы.
Идея → Обсуждение с LLM → Канон в Noda → Код → Анализ → Исправление канона или реализации
У Фреда Брукса канон становился единым объектом согласования между уровнями архитектуры.
Идея → Обсуждение → Канон → Анализ влияния на систему → Реализация → Проверка концептуальной целостности → Исправление канона или компонентов
У Фейгенбаума появляется третий цикл.
Здесь проверяется не код и не согласованность уровней, а качество ответа AI.
Экспертное решение → Канон в Noda → Доступ LLM к канону → Ответ пользователю или AI-инструменту → Проверка ответа → Исправить канон или исправить способ использования знаний → Следующая итерация
Главный вопрос этого цикла:
Почему AI дал неверный ответ?
Возможны разные причины.
Знание отсутствует.
Канон сформулирован неоднозначно.
В каноне сохранилось противоречие.
LLM получила недостаточный контекст.
Неправильно определена область вопроса.
Модель вышла за пределы доступных знаний и начала предполагать.
Система неверно связала несколько статей.
Каждая причина требует своего исправления.
Исправлять LLM или исправлять знания
Когда AI отвечает неправильно, первая реакция часто состоит в желании изменить промпт.
Добавить еще одну инструкцию.
Запретить определенную формулировку.
Указать модели быть точнее.
Расширить системное сообщение.
Иногда это действительно помогает.
Но промпт не может заменить отсутствующее знание.
Если в базе нет ответа, более строгая инструкция не создаст канон.
Если две статьи противоречат друг другу, модель не сможет надежно определить, какая из них правильная.
Если решение изменилось, но знание не было обновлено, LLM продолжит воспроизводить старую версию.
Поэтому при ошибке сначала нужно определить ее уровень.
Ошибка находится в каноне
В базе отсутствует важное положение.
Статья устарела.
Решение сформулировано неоднозначно.
Связанные знания противоречат друг другу.
В этом случае нужно исправлять каноническую базу.
Ошибка находится в способе получения контекста
К вопросу были подобраны не те знания.
Не учтен статус статьи.
Потеряны важные связи.
Контекст оказался слишком узким или слишком широким.
В этом случае исправляется механизм доступа к знаниям.
Ошибка находится в интерпретации
LLM получила правильный канон, но неверно применила его к вопросу.
Тогда нужно уточнить инструкции, формат ответа или ограничения модели.
Вопрос выходит за пределы канона
Система не располагает достаточными знаниями для ответа.
В этом случае правильным результатом является не правдоподобное предположение, а честное указание на отсутствие утвержденного знания.
Так ошибка AI превращается в диагностический сигнал.
Она показывает, что именно необходимо улучшить: знания, связи, инструкции или границы компетенции.
Почему это важнее выбора модели
Команды часто обсуждают, какую LLM использовать.
Какая модель лучше пишет код?
Какая лучше рассуждает?
У какой больше контекст?
Какая дешевле?
Как быстро она отвечает?
Все это имеет значение.
Но замена одной сильной модели на другую не исправит некачественную базу знаний.
Более мощная LLM может лучше скрывать проблему.
Она сформулирует более убедительный ответ.
Найдет более правдоподобную связь между противоречивыми документами.
Заполнит пробелы красивым объяснением.
Но достоверность не возникает из красноречия.
Если система должна объяснять архитектуру Memora8, ей нужны утвержденные знания о Memora8.
Если она должна отвечать о Reganta OS, ей нужен действующий канон Reganta OS.
Если она помогает разрабатывать модули Sekura JS, она должна понимать актуальные правила их исполнения, связывания и взаимодействия.
Модель определяет качество работы с доступными знаниями.
Но сами знания определяют границы надежного ответа.
Роль эксперта не исчезает
Популярная идея заключается в том, что достаточно загрузить корпоративные документы в AI-систему, после чего эксперты больше не потребуются.
На практике происходит обратное.
Чем шире применяется AI, тем важнее становится роль владельца знаний.
Кто-то должен определить:
- что является правильным;
- какое решение действует;
- какая статья устарела;
- где проходит граница компетенции;
- какие исключения допустимы;
- что требует дополнительного исследования;
- какой ответ нельзя давать без участия специалиста.
LLM не отменяет экспертную работу.
Она масштабирует доступ к ее результатам.
Один специалист может сформировать каноническое знание.
После этого десятки разработчиков и AI-инструментов смогут получать объяснения на его основе.
Но ответственность за содержание остается у человека.
Работа одиночного автора с LLM и Noda
Для одиночного разработчика цикл Фейгенбаума особенно полезен.
Один человек может одновременно быть архитектором, разработчиком и владельцем знаний.
Он формирует решение во время обсуждения с ChatGPT.
Затем фиксирует итог в Noda.
Позже другая LLM или AI-инструмент использует этот канон при анализе кода, разработке модуля или ответе на вопрос.
После получения результата автор проверяет не только итоговый ответ.
Он проверяет всю цепочку.
Вопрос → Выбранные канонические знания → Интерпретация LLM → Ответ
Если ответ оказался неправильным, автор определяет причину.
Не хватает статьи?
Статья недостаточно точна?
Между канонами отсутствует связь?
LLM неправильно определила область вопроса?
Система должна была отказаться от ответа?
После этого исправляется конкретный слой.
Так одиночная разработка получает собственный механизм накопления экспертного качества.
Каждая ошибка не просто исправляется локально.
Она улучшает каноническую базу для всех последующих обращений.
Пример из разработки Memora8
Предположим, AI-инструменту задают вопрос о назначении определенного механизма Memora8.
Модель дает технически правдоподобный ответ.
Но этот ответ основан на распространенном подходе из других процессорных архитектур и не соответствует решению Memora8.
Можно просто исправить ответ вручную.
Однако следующий пользователь снова получит ту же ошибку.
В цикле Фейгенбаума проводится другой анализ.
Существует ли в Noda каноническое описание механизма?
Достаточно ли четко оно отделяет Memora8 от традиционных архитектур?
Указаны ли причины принятого решения?
Связана ли статья с соответствующими знаниями об ISA, Firmware Kernel и Reganta OS?
Есть ли явное ограничение, запрещающее переносить общепринятые предположения на Memora8?
Если знания отсутствуют или недостаточны, исправляется канон.
Если знания полны, но не были переданы модели, исправляется доступ к контексту.
Если контекст был правильным, но LLM вышла за его пределы, уточняются правила ответа.
Таким образом одна ошибка превращается в улучшение всей экспертной системы.
Знания должны иметь границы
Сильная экспертная система должна понимать не только то, что она знает.
Она должна понимать, чего она не знает.
Это особенно важно для LLM, потому что языковая модель почти всегда способна сформулировать какой-либо ответ.
Но способность продолжить текст не означает наличие утвержденного знания.
В Noda канон определяет область допустимого ответа.
Если вопрос покрывается действующими статьями, LLM может объяснить решение.
Если знания неполны, система должна указать на ограничение.
Если вопрос требует нового архитектурного решения, его нельзя подменять генерацией правдоподобного текста.
Нужно запустить инженерный цикл:
Новый вопрос → Обсуждение с LLM → Решение эксперта → Новый или обновленный канон → Повторный ответ
Так граница незнания становится не недостатком системы, а входом для развития базы знаний.
От ответов к действиям AI-инструментов
Проблема становится еще важнее, когда LLM не только отвечает на вопросы, но и выполняет действия.
Например:
- генерирует код;
- изменяет архитектурные статьи;
- предлагает интерфейс модуля;
- анализирует спецификацию;
- создает тесты;
- проверяет соответствие реализации канону;
- связывает несколько модулей;
- готовит изменения для Firmware Kernel.
Неправильный текст можно заметить и проигнорировать.
Неправильное действие может сразу повлиять на проект.
Поэтому AI-инструменту нужен не просто широкий контекст.
Ему нужны точные канонические ограничения.
Что разрешено менять?
Какие принципы нельзя нарушать?
Какая статья является источником требований?
Какие компоненты затрагивает решение?
Когда необходимо остановиться и запросить решение автора?
В этом смысле каноническая база знаний становится не только источником ответов.
Она становится системой управления действиями AI.
Чем Noda отличается от обычной базы документов
Обычное хранилище отвечает на вопрос:
Какая информация у нас есть?
Noda должна отвечать на другой вопрос:
Какое знание действует сейчас?
Разница проявляется в нескольких принципах.
Каноничность
Для каждого инженерного вопроса должно быть понятно, какое знание считается действующим.
Управляемая актуальность
При изменении решения обновляется канон, а старая версия перестает конкурировать с новой.
Авторство
Знание имеет владельца, который отвечает за его содержание.
Связность
Статьи образуют модель предметной области, а не просто независимый набор текстов.
Ограниченная компетенция
Система должна понимать, какие вопросы покрываются каноном, а какие требуют нового решения.
Доступ для LLM
Канонические знания должны быть доступны AI-инструментам в форме, пригодной для анализа и применения.
Это возвращает в современный AI ключевой принцип экспертных систем: знания должны быть отделены от механизма их обработки.
Не нужно обучать отдельную модель на каждое изменение
Еще одно следствие такого разделения заключается в том, что знания можно развивать независимо от LLM.
Архитектура Memora8 изменилась — обновляется канон.
Изменилась модель исполнения Reganta OS — обновляется соответствующая статья.
Появилось новое правило Sekura JS — оно добавляется в базу знаний.
Не требуется каждый раз переобучать языковую модель.
LLM остается универсальным механизмом взаимодействия.
Предметная экспертиза развивается в Noda.
Это значительно сокращает путь от инженерного решения до его использования AI-инструментами.
Решение эксперта → Обновление канона → Новый контекст для LLM → Ответы и действия с учетом изменения
Так современная система сохраняет одно из главных преимуществ классических экспертных систем: знания можно менять отдельно от механизма вывода.
Фейгенбаум оказался прав в эпоху LLM
Большие языковые модели стали намного универсальнее старых механизмов вывода.
Они понимают естественный язык.
Умеют работать с неполными запросами.
Могут связывать несколько источников.
Адаптируют объяснение под человека.
Но главный принцип не изменился.
Интеллектуальная система сильна настолько, насколько сильны знания, на которые она опирается.
Модель может быть очень мощной.
Но без качественной предметной базы она остается универсальным собеседником.
С каноническими знаниями она становится частью экспертной системы.
Три цикла одной инженерной методологии
После Наура, Брукса и Фейгенбаума получается три разных, но связанных цикла.
Цикл Наура: создание теории
Идея → Обсуждение с LLM → Канон в Noda → Код → Анализ → Исправить теорию или реализацию
Здесь канон сохраняет понимание системы.
Цикл Брукса: сохранение концептуальной целостности
Идея → Канон → Анализ влияния на все уровни → Реализация → Проверка целостности → Исправить канон или компоненты
Здесь канон синхронизирует архитектуру.
Цикл Фейгенбаума: развитие экспертной системы
Экспертное знание → Канон в Noda → LLM → Ответ или действие → Проверка → Исправить знания, контекст или способ применения
Здесь канон становится контролируемым источником истины для AI.
Это не три одинаковые статьи с разными именами.
Каждый автор отвечает на собственный вопрос.
Наур объясняет, что программа начинается с теории.
Брукс объясняет, как сохранить единый архитектурный замысел.
Фейгенбаум объясняет, почему AI должен опираться на качественную базу предметных знаний.
Вместо вывода
Современный AI часто оценивают по возможностям модели.
Размер контекста.
Качество рассуждений.
Скорость генерации.
Результаты тестов.
Но в реальной инженерной системе этого недостаточно.
LLM должна знать, какое решение приняла конкретная команда.
Какая архитектура является действующей.
Какие ограничения нельзя нарушать.
Где заканчивается утвержденное знание и начинается предположение.
Поэтому следующий этап развития AI заключается не только в создании более мощных моделей.
Он заключается в создании качественных, управляемых и канонических баз знаний.
В нашей работе над Memora8, Reganta OS и Sekura JS эту роль выполняет Noda.
Эксперт формирует решение.
Команда или автор утверждает канон.
Noda сохраняет действующее знание.
LLM делает его доступным людям и AI-инструментам.
А каждый неверный ответ запускает новую итерацию:
Проверить канон → Проверить выбранный контекст → Проверить интерпретацию → Исправить нужный слой → Получить более надежный следующий ответ
Именно в этом идеи Эдварда Фейгенбаума получают новую жизнь.
Прошлое поколение экспертных систем имело качественные знания, но сложный интерфейс.
Современные LLM дали нам естественный интерфейс.
Теперь задача состоит в том, чтобы вернуть в систему то, что всегда делало экспертный AI действительно полезным:
не просто способность говорить, а способность опираться на правильные знания.
Share
