The post has been translated automatically. Original language: Russian
When an experienced engineer makes a decision, he rarely starts with a complete formal proof.
Sometimes he immediately sees that a certain option is not suitable.
Notices a dangerous addiction.
He feels that the architecture will become unstable.
Understands that the proposed simplification will create more problems later than it will solve now.
When asked about the reason, he can answer:
"That's understandable enough."
"You can't do that."
"Practice shows that it won't work."
"The very model of the system is being violated here."
The engineer is often right.
But his understanding remains inside his head.
Another developer can't use it.
A new employee repeats an old mistake.
The documentation records the final decision, but does not explain why the alternatives were rejected.
The AI sees only the text and begins to complete the missing logic on its own.
This problem was investigated by the philosopher and scientist Michael Polanyi.
His key message is usually conveyed like this:
a person knows more than he is able to express directly in words.
Today, this idea is becoming especially important for corporate knowledge and development systems with LLM.
What is implicit knowledge?
Not all human knowledge exists in the form of rules and instructions.
The person recognizes the face, although he cannot list the exact signs by which he did it.
An experienced doctor notices an unusual pattern of symptoms before making a diagnosis.
The engineer hears the operation of the mechanism and realizes that something is wrong with it.
The program architect sees the solution and notices in advance where the unwanted connectivity will appear.
This does not mean that such knowledge is mystical or beyond analysis.
It is shaped by experience, observations, many special cases, and internal models.
But a person cannot always immediately decompose it into explicit statements.
Polanyi called this understanding implicit knowledge.
We use it all the time.
However, it is much more difficult to transfer it to another person than to apply it yourself.
Why does the documentation keep only the visible part?
Technical documentation usually records the result.
How the interface works.
Which parameters the function accepts.
Which instruction exists in the processor.
What features does the system provide?
How the module is launched.
But behind every such decision there are many questions.
Why does the interface have this exact shape?
What alternatives were considered?
What limitations were critical?
What kind of behavior is considered unacceptable?
What happens if you change one of the elements?
In which cases can the rule be revised?
What assumptions does the author consider so obvious that he didn't even write them down?
Without these answers, the document retains the form of a solution, but it does not always retain understanding.
The code also does not extract knowledge from the author's head.
The source code shows which solution has been implemented.
Sometimes you can use it to restore part of the idea.
But the code doesn't explain all the reasons.
Let's say there is no specific mechanism in the system.
It can be:
- a conscious architectural prohibition;
- time limit;
- the result of a lack of resources;
- an opportunity that has not yet been realized;
- an experimental solution;
- a consequence of another system principle.
It is impossible to reliably determine the reason for the absence in the code alone.
The LLM can analyze the implementation and offer a plausible explanation.
But plausibility does not guarantee that she has restored the author's real theory.
We are constantly faced with this during the development of Sekura.
Sekura is developing as a connected architectural platform.
It includes the Memora8 processor, Reganta OS, Sekura JS language, Firmware Kernel, system modules, and a streaming execution model.
Many solutions of this system differ from common approaches.
For example, a habitual developer may automatically expect classic processes, a preemptive scheduler, a traditional driver model, or standard component interaction mechanisms.
But Sekura is based on a different theory of execution.
The author of the system understands why certain familiar mechanisms are not suitable.
He sees connections between hardware architecture, memory model, modules, threads, and system contracts.
However, this understanding cannot be conveyed in one phrase.:
"Our processes are not used."
For reliable knowledge, it is necessary to disclose:
- why were they abandoned;
- what problem does the alternative model solve?;
- what advantages are expected;
- What new obligations do the modules have?;
- what are the limitations?;
- in what cases can the decision be reviewed?;
- why can't you just transfer the familiar model to another OS?
This is where the work with implicit knowledge begins.
The discussion history contains knowledge, but does not make it accessible.
During the conversation with the LLM, the engineer gradually formulates his model.
First he expresses an idea.
Then he responds to objections.
Clarifies the terms.
Corrects incorrect interpretations.
Compares the options.
Detects hidden assumptions.
At the end of the discussion, his understanding becomes much clearer.
But if the entire result remains in the chat history, the problem is not solved.
The dialog contains:
- the initial hypothesis;
- mistakes;
- rejected options;
- temporary formulations;
- contradictions;
- clarifications;
- the final decision.
The next AI tool does not have to go through the whole path again and independently determine which fragment is valid knowledge.
Implicit understanding doesn't just need to be discussed.
It needs to be turned into a canon.
LLM as a knowledge extraction tool
Classical expert systems faced the so-called bottleneck of knowledge extraction.
It was difficult for the expert to formalize everything he knows.
The knowledge engineer asked questions, observed the specialist's work, clarified the rules, and tried to turn the experience into a formal structure.
LLM radically simplifies this process.
She can have a long conversation.
Ask clarifying questions.
Offer counterexamples.
Show alternative interpretations.
To look for contradictions.
Ask to define the boundaries of the rule.
To help turn intuitive understanding into a consistent explanation.
The model does not create expert knowledge instead of human knowledge.
It helps a person to make his knowledge explicit.
What questions reveal hidden insights
Let's say the architect says:
"This module should work like firmware and should not be superseded."
The statement itself captures the solution.
But for a full-fledged canon, the LLM can continue its research.
Why can't the module be displaced?
Is it directly connected to the device?
What guarantees of execution time are needed?
Can it load other modules?
Does it support the full Reganta OS contract?
How does it exchange streams with the rest of the system?
What happens in case of an error?
Can a separate CPU group belong only to this task?
Where is the boundary between firmware, kernel, and system modules?
Which cases are the exceptions?
After such questions, the initial intuition turns into an architectural model.
Noda saves not the dialogue, but the extracted knowledge.
The Noda Task The goal is not to accumulate all the conversations with LLM.
The value is not in the number of discussions.
The value lies in the knowledge that has been extracted from them.
After the dialog, a canonical article is created.
She fixes:
- the decision taken;
- the meaning of the decision;
- reasons;
- scope of applicability;
- limitations;
- exceptions;
- links to other solutions;
- rejected assumptions, if they are important to understand;
- conditions for possible revision.
In this way, Noda becomes a layer between the expert's personal understanding and the subsequent use of knowledge by humans and AI.
Why is one final rule not enough?
Suppose the canon contains the phrase:
"Sekura JS modules are required to complete execution on their own after processing a unit of work."
This is a useful rule.
But AI can apply it incorrectly if it doesn't understand the context.
What is considered a unit of work?
How does the module report completion?
What happens if there is no new data yet?
Should the module terminate or go to sleep?
Is this usually due to the lack of a classical process?
Who is responsible for the relaunch?
How does it work in a cyclical flow?
Which system modules may have a different lifecycle?
Implicit knowledge is often hidden in these clarifications.
The expert perceives them as a single model.
But in the canon, the connections must be expressed explicitly.
Implicit constraints are more important than explicit features
Documentation often lists what the system can do.
But limitations are especially important for architecture.
What can not be done?
What assumptions are unacceptable?
What actions violate the model?
Where can you not use the usual approach?
When is the LLM obligated to stop and request a solution?
It is the constraints that often remain implicit.
The engineer simply does not consider the prohibited option, because he internally understands its incompatibility with the system.
AI has no such understanding.
If the prohibition is not expressed, the model may offer a technically plausible but architecturally unacceptable solution.
Example: A common solution is not a Sekura solution
Suppose the AI analyzes an execution planning task.
There are many typical approaches in common sources.
The model can suggest a process, an operating system thread that displaces a quantum, or a standard task pool.
Every suggestion will look reasonable.
But Sekura can use a different unit of execution and a different CPU release contract.
In order for AI not to transfer someone else's architecture automatically, the canon should contain not only a description of the operating mechanism.
He should explain it clearly.:
- which traditional assumptions don't apply here;
- why aren't they working;
- what replaced them;
- what obligations does the module assume?;
- how does the solution relate to the Reganta OS streaming model;
- which properties of Memora8 support this architecture.
This is how the implicit understanding of the author becomes available to the system.
A single developer is especially dependent on explicit knowledge
In a large team, some of the understanding can be restored through colleagues.
You can ask the author.
Hold a meeting.
Find the person who participated in the discussion.
A single developer does not have this option.
Today he remembers all the details.
After a year, some of the reasons will disappear from memory.
After three years, your own decision may look like someone else's.
At the same time, LLM allows one person to create systems that previously required a team.
The volume of decisions being made is growing.
Dependence on the author's memory becomes more dangerous.
Therefore, a single development needs a mechanism for systematically extracting knowledge from one's own head.
Polanyi Cycle for Sekura and Noda
This process can be represented as a separate cycle.
Intuitive understanding → Dialogue with LLM → Clarifying questions and counterexamples → Explicit formulation of the solution → Canon in Noda → Human or AI usage → Discovery of a new implicit assumption → Updating the canon
The main issue of the cycle:
What does the expert understand, but not yet expressed?
Sometimes the answer is discovered only after an AI error.
The model received the article, but interpreted it differently.
This does not always mean that the LLM does not reason well.
Perhaps the author assumed a condition that he never wrote down.
It was obvious to him.
Not for the external reader.
Then the wrong answer helps to reveal the hidden part of knowledge.
AI error as an interview with an expert
Usually, a model error is perceived as a defect.
But when working with the canonical database, it can perform a diagnostic function.
If the LLM systematically understands the article differently from the author, you need to ask:
What part of the meaning exists only in the author's head?
What connection was not expressed?
Which limitation was considered obvious?
Which term allows for a different interpretation?
What counterexample destroys the current formulation?
So the AI's response turns into a kind of interview with the owner of knowledge.
Each discrepancy shows where implicit understanding has not yet become canon.
Not all implicit knowledge can be fully formalized
It's important not to go to the other extreme.
It is impossible to guarantee that all the expert's experience will be completely transformed into text.
Some skills are formed only by practice.
Some decisions depend on the context.
Some signs are difficult to list in advance.
But this does not mean that the extraction attempt is useless.
Even partial fixation:
- reasons;
- restrictions;
- examples;
- Counterexamples;
- selection criteria;
- signs of risk;
- The limits of confidence
significantly improves the quality of knowledge transfer.
Noda is not obligated to replace a live expert.
It should preserve as much of his current understanding as possible and clearly define the boundaries where a human solution is required.
The possession of knowledge remains with the person
LLM can ask good questions.
Suggest formulations.
Detect logical gaps.
Compare articles.
Show contradictions.
But it should not independently approve the architectural canon.
The model is not responsible for the consequences of the decision.
It does not have the full implicit context of the author.
He does not know all the goals of the project.
It does not determine which compromise is acceptable.
Therefore, the roles must remain separate.
The expert has a substantive understanding.
LLM helps to explore and express it.
Noda saves the approved result.
Sekura develops based on this canon.
From personal knowledge to a scalable system
As long as the knowledge is only in the expert's head, it can be used by one person.
After it is fixed in the canon, it becomes available.:
- to other developers;
- to the future author;
- To the AI assistant;
- a code analysis tool;
- the module generator;
- architecture verification system;
- technical support;
- to users of the platform.
LLM scales access to knowledge.
But first, this knowledge must be extracted, purified, and validated.
It is Noda that makes the transition from personal understanding to a managed database.
The canon should store not only the answer, but also the method of discrimination.
Strong expert knowledge is not just a ready—made rule.
This is the ability to distinguish between suitable the case is from an unsuitable one.
Therefore, a good article should help to answer:
When does the rule apply?
When does it not apply?
What signs are important?
What are the secondary signs?
What similar cases require a different solution?
What information is needed to make a choice?
When is there not enough data?
This is especially important for AI.
Without discrimination criteria, the LLM may know the rule, but apply it too broadly.
An example of a knowledge structure for Sekura
Let's say a separate firmware module is described for a special task.
A full-fledged canon should contain more than just the statement that such modules are acceptable.
He has to explain:
- what special task do they solve?;
- why is a CPU or a CPU group allocated to this task?;
- what part of the Reganta OS contract does such a module support?;
- which system modules does it not load;
- how is the flow exchange carried out?;
- why can't the mechanism be considered an ordinary user module?;
- which hardware resources belong to the task;
- when is such an architecture justified?;
- when should a regular system module be used?
Such differences usually exist in the architect's understanding, but are absent from the brief technical description.
Noda as a continuation of the expert's work
Classic documentation is often created as a separate responsibility after making a decision.
In the Noda model, knowledge extraction becomes part of the engineering process itself.
The discussion with the LLM does not end with the choice of an option.
After selecting it, you need to check:
Was it possible to explain the reason?
Are the boundaries clear?
Are the hidden limitations expressed?
Are there any counterexamples?
Will another AI be able to apply this knowledge without the author's personal presence?
If not, the solution has not yet fully become canon.
Instead of output
Michael Polanyi has shown that human knowledge is much broader than what a person can immediately formulate.
For engineering systems, this means a simple but unpleasant conclusion.
Even if an expert has written documentation, most of his understanding may remain implicit.
The code preserves the implementation.
The article retains the wording.
But the reasons, differences, limitations, and criteria often continue to live only in the author's head.
LLM provides a new way to work with this problem.
She can become a patient conversationalist who asks questions, checks examples, suggests alternative interpretations, and helps discover hidden assumptions.
Noda turns the result of such a conversation into canonical knowledge.
Sekura uses this canon as the basis for the architecture, implementation, and operation of AI tools.
It turns out a new engineering cycle:
The expert knows more than he can immediately say → LLM helps to discover this → the author formulates a solution → Noda preserves the canon → Sekura develops based on it → new questions reveal the next layer of implicit knowledge.
This is how personal understanding stops disappearing along with the author's memory.
It becomes part of an evolving engineering system.
Когда опытный инженер принимает решение, он редко начинает с полного формального доказательства.
Иногда он сразу видит, что определенный вариант не подойдет.
Замечает опасную зависимость.
Чувствует, что архитектура станет нестабильной.
Понимает, что предлагаемое упрощение позже создаст больше проблем, чем решит сейчас.
На вопрос о причине он может ответить:
«Это и так понятно».
«Так делать нельзя».
«Практика показывает, что это не сработает».
«Здесь нарушается сама модель системы».
Часто инженер оказывается прав.
Но его понимание остается внутри головы.
Другой разработчик не может им воспользоваться.
Новый сотрудник повторяет старую ошибку.
Документация фиксирует итоговое решение, но не объясняет, почему альтернативы были отвергнуты.
AI видит только текст и начинает достраивать отсутствующую логику самостоятельно.
Эту проблему исследовал философ и ученый Майкл Полани.
Его ключевую мысль обычно передают так:
человек знает больше, чем способен непосредственно выразить словами.
Сегодня эта идея становится особенно важной для систем корпоративных знаний и разработки с LLM.
Что такое неявное знание
Не все человеческое знание существует в форме правил и инструкций.
Человек узнает лицо, хотя не может перечислить точные признаки, по которым это сделал.
Опытный врач замечает необычную картину симптомов раньше, чем формулирует диагноз.
Инженер слышит работу механизма и понимает, что с ним что-то не так.
Архитектор программы видит решение и заранее замечает, где появится нежелательная связанность.
Это не означает, что такое знание мистично или недоступно анализу.
Оно сформировано опытом, наблюдениями, множеством частных случаев и внутренними моделями.
Но человек не всегда может сразу разложить его на явные утверждения.
Полани называл такое понимание неявным знанием.
Мы используем его постоянно.
Однако передать его другому человеку значительно сложнее, чем применить самому.
Почему документация сохраняет только видимую часть
Техническая документация обычно фиксирует результат.
Как устроен интерфейс.
Какие параметры принимает функция.
Какая инструкция существует в процессоре.
Какие возможности предоставляет система.
Каким образом запускается модуль.
Но за каждым таким решением скрывается множество вопросов.
Почему интерфейс имеет именно такую форму?
Какие альтернативы рассматривались?
Какие ограничения оказались критическими?
Какое поведение считается недопустимым?
Что произойдет, если изменить один из элементов?
В каких случаях правило можно пересмотреть?
Какие предположения автор считает настолько очевидными, что даже не записал их?
Без этих ответов документ сохраняет форму решения, но не всегда сохраняет понимание.
Код тоже не извлекает знание из головы автора
Исходный код показывает, какое решение было реализовано.
Иногда по нему можно восстановить часть замысла.
Но код не объясняет все причины.
Допустим, в системе отсутствует определенный механизм.
Это может быть:
- сознательный архитектурный запрет;
- временное ограничение;
- результат нехватки ресурсов;
- еще не реализованная возможность;
- экспериментальное решение;
- следствие другого системного принципа.
По одному отсутствию в коде невозможно надежно определить причину.
LLM может проанализировать реализацию и предложить правдоподобное объяснение.
Но правдоподобие не гарантирует, что она восстановила реальную теорию автора.
Мы постоянно сталкиваемся с этим при разработке Sekura
Sekura развивается как связанная архитектурная платформа.
Она включает процессор Memora8, Reganta OS, язык Sekura JS, Firmware Kernel, системные модули и потоковую модель исполнения.
Многие решения этой системы отличаются от распространенных подходов.
Например, привычный разработчик может автоматически ожидать классические процессы, вытесняющий планировщик, традиционную модель драйверов или стандартные механизмы взаимодействия компонентов.
Но Sekura строится на другой теории исполнения.
Автор системы понимает, почему определенные привычные механизмы не подходят.
Он видит связи между аппаратной архитектурой, моделью памяти, модулями, потоками и системными контрактами.
Однако это понимание нельзя передать одной фразой:
«У нас процессы не используются».
Для надежного знания необходимо раскрыть:
- почему от них отказались;
- какую задачу решает альтернативная модель;
- какие преимущества ожидаются;
- какие новые обязательства появляются у модулей;
- какие ограничения возникают;
- в каких случаях решение может быть пересмотрено;
- почему нельзя просто перенести привычную модель другой ОС.
Именно здесь начинается работа с неявным знанием.
История обсуждения содержит знание, но не делает его доступным
Во время разговора с LLM инженер постепенно формулирует свою модель.
Сначала высказывает идею.
Потом отвечает на возражения.
Уточняет термины.
Исправляет неправильные интерпретации.
Сравнивает варианты.
Обнаруживает скрытые предположения.
В конце обсуждения его понимание становится намного яснее.
Но если весь результат останется в истории чата, проблема не решена.
Диалог содержит:
- исходную гипотезу;
- ошибки;
- отвергнутые варианты;
- временные формулировки;
- противоречия;
- уточнения;
- итоговое решение.
Следующий AI-инструмент не должен заново проходить весь путь и самостоятельно определять, какой фрагмент является действующим знанием.
Неявное понимание нужно не только обсудить.
Его необходимо превратить в канон.
LLM как инструмент извлечения знания
Классические экспертные системы сталкивались с так называемым узким местом извлечения знаний.
Эксперту было трудно формализовать все, что он знает.
Инженер по знаниям задавал вопросы, наблюдал за работой специалиста, уточнял правила и пытался превратить опыт в формальную структуру.
LLM радикально упрощает этот процесс.
Она может вести длинный диалог.
Задавать уточняющие вопросы.
Предлагать контрпримеры.
Показывать альтернативные интерпретации.
Искать противоречия.
Просить определить границы правила.
Помогать превратить интуитивное понимание в последовательное объяснение.
Модель не создает экспертное знание вместо человека.
Она помогает человеку сделать свое знание явным.
Какие вопросы раскрывают скрытое понимание
Допустим, архитектор говорит:
«Этот модуль должен работать как firmware и не должен вытесняться».
Само утверждение фиксирует решение.
Но для полноценного канона LLM может продолжить исследование.
Почему модуль нельзя вытеснять?
Связан ли он напрямую с устройством?
Какие гарантии времени исполнения необходимы?
Может ли он загружать другие модули?
Поддерживает ли он полный контракт Reganta OS?
Как он обменивается потоками с остальной системой?
Что произойдет при ошибке?
Может ли отдельная группа CPU принадлежать только этой задаче?
Где проходит граница между firmware, kernel и system-модулями?
Какие случаи являются исключениями?
После таких вопросов первоначальная интуиция превращается в архитектурную модель.
Noda сохраняет не диалог, а извлеченное знание
Задача Noda заключается не в том, чтобы накопить все разговоры с LLM.
Ценность находится не в количестве обсуждений.
Ценность — в знаниях, которые удалось из них извлечь.
После диалога создается каноническая статья.
Она фиксирует:
- принятое решение;
- смысл решения;
- причины;
- область применимости;
- ограничения;
- исключения;
- связи с другими решениями;
- отвергнутые предположения, если они важны для понимания;
- условия возможного пересмотра.
Таким образом Noda становится слоем между личным пониманием эксперта и последующим использованием знания людьми и AI.
Почему одного итогового правила недостаточно
Предположим, канон содержит фразу:
«Модули Sekura JS обязаны самостоятельно завершать выполнение после обработки единицы работы».
Это полезное правило.
Но AI может применить его неправильно, если не понимает контекст.
Что считается единицей работы?
Как модуль сообщает о завершении?
Что происходит, если новых данных пока нет?
Должен ли модуль завершиться или перейти в сон?
Как правило связано с отсутствием классического процесса?
Кто отвечает за повторный запуск?
Как оно работает в циклическом потоке?
Какие системные модули могут иметь другой жизненный цикл?
Неявное знание часто скрывается именно в этих уточнениях.
Эксперт воспринимает их как единую модель.
Но в каноне связи должны быть выражены явно.
Неявные ограничения важнее явных возможностей
Документация часто перечисляет, что система умеет.
Но для архитектуры особенно важны ограничения.
Что нельзя делать?
Какие предположения недопустимы?
Какие действия нарушают модель?
Где нельзя использовать привычный подход?
Когда LLM обязана остановиться и запросить решение?
Именно ограничения часто остаются неявными.
Инженер просто не рассматривает запрещенный вариант, потому что внутренне понимает его несовместимость с системой.
AI такого понимания не имеет.
Если запрет не выражен, модель может предложить технически правдоподобное, но архитектурно недопустимое решение.
Пример: распространенное решение не является решением Sekura
Предположим, AI анализирует задачу планирования исполнения.
В общих источниках существует множество типичных подходов.
Модель может предложить процесс, поток операционной системы, вытесняющий квант или стандартный пул задач.
Каждое предложение будет выглядеть разумно.
Но Sekura может использовать другую единицу исполнения и другой контракт освобождения CPU.
Чтобы AI не переносил чужую архитектуру автоматически, канон должен содержать не только описание действующего механизма.
Он должен ясно объяснять:
- какие традиционные предположения здесь не действуют;
- почему они не действуют;
- чем заменены;
- какие обязательства принимает модуль;
- как решение связано с потоковой моделью Reganta OS;
- какие свойства Memora8 поддерживают эту архитектуру.
Так неявное понимание автора становится доступным системе.
Одиночный разработчик особенно зависит от явного знания
В большой команде часть понимания можно восстановить через коллег.
Можно спросить автора.
Провести встречу.
Найти человека, участвовавшего в обсуждении.
У одиночного разработчика такой возможности нет.
Сегодня он помнит все детали.
Через год часть причин исчезнет из памяти.
Через три года собственное решение может выглядеть чужим.
При этом LLM позволяет одному человеку создавать системы, которые раньше требовали команды.
Объем принимаемых решений растет.
Зависимость от памяти автора становится опаснее.
Поэтому одиночной разработке нужен механизм систематического извлечения знания из собственной головы.
Цикл Полани для Sekura и Noda
Этот процесс можно представить как отдельный цикл.
Интуитивное понимание → Диалог с LLM → Уточняющие вопросы и контрпримеры → Явная формулировка решения → Канон в Noda → Использование человеком или AI → Обнаружение нового неявного предположения → Обновление канона
Главный вопрос цикла:
Что эксперт понимает, но еще не выразил?
Иногда ответ обнаруживается только после ошибки AI.
Модель получила статью, но истолковала ее иначе.
Это не всегда означает, что LLM плохо рассуждает.
Возможно, автор предполагал условие, которое никогда не записал.
Для него оно было очевидным.
Для внешнего читателя — нет.
Тогда неверный ответ помогает выявить скрытую часть знания.
Ошибка AI как интервью с экспертом
Обычно ошибку модели воспринимают как дефект.
Но в работе с канонической базой она может выполнять диагностическую функцию.
Если LLM систематически понимает статью не так, как автор, нужно спросить:
Какая часть смысла существует только в голове автора?
Какая связь не была выражена?
Какое ограничение считалось очевидным?
Какой термин допускает другую интерпретацию?
Какой контрпример разрушает текущую формулировку?
Так ответ AI превращается в своеобразное интервью с владельцем знания.
Каждое расхождение показывает, где неявное понимание еще не стало каноном.
Не все неявное знание можно полностью формализовать
Важно не впасть в другую крайность.
Нельзя гарантировать, что весь опыт эксперта будет полностью превращен в текст.
Некоторые навыки формируются только практикой.
Некоторые решения зависят от контекста.
Некоторые признаки трудно перечислить заранее.
Но это не означает, что попытка извлечения бесполезна.
Даже частичная фиксация:
- причин;
- ограничений;
- примеров;
- контрпримеров;
- критериев выбора;
- признаков риска;
- границ уверенности
значительно повышает качество передачи знания.
Noda не обязана заменить живого эксперта.
Она должна сохранить максимально возможную часть его действующего понимания и четко обозначить границы, где требуется человеческое решение.
Владение знанием остается у человека
LLM может задавать хорошие вопросы.
Предлагать формулировки.
Обнаруживать логические пробелы.
Сравнивать статьи.
Показывать противоречия.
Но она не должна самостоятельно утверждать архитектурный канон.
Модель не несет ответственности за последствия решения.
Она не обладает полным неявным контекстом автора.
Не знает всех целей проекта.
Не определяет, какой компромисс допустим.
Поэтому роли должны оставаться разделенными.
Эксперт обладает предметным пониманием.
LLM помогает его исследовать и выразить.
Noda сохраняет утвержденный результат.
Sekura развивается на основании этого канона.
От личного знания к масштабируемой системе
Пока знание находится только в голове эксперта, им может пользоваться один человек.
После фиксации в каноне оно становится доступным:
- другим разработчикам;
- будущему автору;
- AI-ассистенту;
- инструменту анализа кода;
- генератору модулей;
- системе проверки архитектуры;
- технической поддержке;
- пользователям платформы.
LLM масштабирует доступ к знанию.
Но сначала это знание должно быть извлечено, очищено и утверждено.
Именно Noda выполняет переход от личного понимания к управляемой базе.
Канон должен хранить не только ответ, но и способ различения
Сильное экспертное знание — это не только готовое правило.
Это способность отличать подходящий случай от неподходящего.
Поэтому хорошая статья должна помогать ответить:
Когда правило применяется?
Когда оно не применяется?
Какие признаки важны?
Какие признаки второстепенны?
Какие похожие случаи требуют другого решения?
Какая информация нужна для выбора?
Когда недостаточно данных?
Это особенно важно для AI.
Без критериев различения LLM может знать правило, но применять его слишком широко.
Пример структуры знания для Sekura
Допустим, описывается отдельный firmware-модуль для специальной задачи.
Полноценный канон должен содержать не только утверждение, что такие модули допустимы.
Он должен объяснить:
- какую специальную задачу они решают;
- почему CPU или группа CPU выделяется этой задаче;
- какую часть контракта Reganta OS такой модуль поддерживает;
- какие системные модули он не загружает;
- как осуществляется обмен потоками;
- почему механизм нельзя считать обычным пользовательским модулем;
- какие аппаратные ресурсы принадлежат задаче;
- когда подобная архитектура оправдана;
- когда следует использовать обычный системный модуль.
Именно такие различия обычно существуют в понимании архитектора, но отсутствуют в кратком техническом описании.
Noda как продолжение работы эксперта
Классическая документация часто создается как отдельная обязанность после принятия решения.
В модели Noda извлечение знания становится частью самого инженерного процесса.
Обсуждение с LLM не заканчивается выбором варианта.
После выбора необходимо проверить:
Удалось ли объяснить причину?
Понятны ли границы?
Выражены ли скрытые ограничения?
Указаны ли контрпримеры?
Сможет ли другой AI применить это знание без личного присутствия автора?
Если нет, решение еще не полностью стало каноном.
Вместо вывода
Майкл Полани показал, что человеческое знание значительно шире того, что человек способен сразу сформулировать.
Для инженерных систем это означает простой, но неприятный вывод.
Даже если эксперт написал документацию, большая часть его понимания может остаться неявной.
Код сохраняет реализацию.
Статья сохраняет формулировку.
Но причины, различия, ограничения и критерии часто продолжают жить только в голове автора.
LLM дает новый способ работать с этой проблемой.
Она может стать терпеливым собеседником, который задает вопросы, проверяет примеры, предлагает альтернативные толкования и помогает обнаружить скрытые предположения.
Noda превращает результат такого разговора в каноническое знание.
Sekura использует этот канон как основу архитектуры, реализации и работы AI-инструментов.
Получается новый инженерный цикл:
Эксперт знает больше, чем может сразу сказать → LLM помогает это обнаружить → автор формулирует решение → Noda сохраняет канон → Sekura развивается на его основе → новые вопросы раскрывают следующий слой неявного знания.
Именно так личное понимание перестает исчезать вместе с памятью автора.
Оно становится частью развивающейся инженерной системы.
Share
