Понять
Различать источник, утверждение и подтверждённое для заданных условий знание.
Документ — начало проверки§
В инструкции может быть верное правило для старой версии оборудования. В разговоре эксперт может описать удачный случай, который ещё не стал общей практикой. При переносе в базу важно сохранить условия, при которых утверждение было сделано, и основание его использования.
Полезно различать три объекта: исходный материал; извлечённое утверждение; решение о том, где и в каком статусе это утверждение можно применять. Они могут храниться рядом, но выполняют разные функции. Ошибка возникает, когда аккуратно оформленный пересказ начинает выглядеть как утверждённая инструкция.
Разберите одно противоречие§
Статус «не выяснено» полезнее выдуманного согласия. Такая запись может направить человека к уточнению, но не должна незаметно попадать в ответ как действующее правило.
Учебный пример. В учебном кейсе инструкция версии 2 разрешает процедуру для прошивки 4.0, а заметка инженера рекомендует её и для 4.1. Это может быть обновление, исключение или ошибка. Сначала фиксируем обе записи и их условия. Утверждать новую область действия должен назначенный эксперт.
Эксперт раскрывает ход решения§
Просьба «расскажите всё про ремонт» даёт трудно проверяемый поток. Возьмите конкретный завершённый случай и выясните: что произошло, какие признаки заметили, какие варианты рассматривали, почему выбрали действие и как проверили результат. Затем попросите случай, в котором привычный способ не сработал.
Не публикуйте чувствительные исходные материалы просто потому, что они полезны для извлечения знаний. Отдельно определите право использовать источник, круг читателей производной записи и ограничения на раскрытие фрагментов.
Проверить себя
LLM извлекла из переписки правило и добавила ссылку на сообщение. Стало ли оно действующим правилом компании?
Свериться с разбором
Нет. Ссылка показывает происхождение. Нужно выяснить контекст, полномочия автора, статус решения и область действия. Извлечение и организационное принятие — разные шаги.
Что прочитать по теме · 2
- Knowledge Engineering and Management: The CommonKADS MethodologyГлавы о моделях организации, задачи, агента и знаний; глава об извлечении знаний. Поиск по PDF: organization model, task model, knowledge elicitation.
- PROV-O: The PROV OntologyStarting Point Terms: Entity, Activity, Agent и отношения происхождения.
Практические шаги и учебный кейс — адаптация для этой программы. Роль и ограничения каждого источника указаны в библиографии.
Применить
Подготовить реестр источников, провести разбор случая с экспертом и отделить принятые утверждения от спорных.
Сначала инвентаризация§
- Сопоставьте вопросы из паспорта с возможными источниками. Начните с источников, которые реально нужны для этих вопросов.
- Для каждого источника запишите владельца, версию, область действия, условия доступа и способ узнавать об изменениях.
- Отметьте пробелы: устаревшая версия, неизвестный владелец, недоступное приложение, неясное разрешение на использование.
- Выберите несколько утверждений и проследите их до конкретного места в источнике. Ссылка на большой файл без раздела может оказаться недостаточной.
Интервью по одному случаю§
После интервью покажите эксперту короткую запись с условиями и исключениями. Попросите разобрать по ней новый пример. Это проверяет полезность модели лучше, чем простое согласие с красивой формулировкой.
- Как выглядел запрос и какие данные были известны в начале?
- Какой признак изменил ваш выбор?
- Какие альтернативы вы отвергли и почему?
- Когда этот способ нельзя применять?
- По чему вы поняли, что задача решена?
- Кто вправе изменить описанное правило?
Фиксируйте разногласие как рабочую задачу§
Сохраняйте происхождение на уровне существенного утверждения. Для автоматически извлечённой записи полезны версия исходника, место фрагмента, способ извлечения и дата проверки человеком. Показатель уверенности модели сам по себе не заменяет эти основания.
| Поле | Учебный пример |
|---|---|
| Утверждение | Процедура P-17 применима к прошивке 4.1 |
| Основания | Инструкция v2: только 4.0; заметка инженера: 4.1 |
| Статус | Требует проверки |
| Кто разрешает | Владелец процедуры |
| До решения | Не рекомендовать для 4.1 автоматически |
| Результат проверки | Заполняется после разбора и подтверждения |
Практика: Проверяемый пакет знаний
- Составьте реестр источников одного сценария.
- Разберите с экспертом один обычный и один исключительный случай.
- Создайте несколько записей, включая спорную; укажите их основания и статусы.
Критерии готовности
- Каждое существенное утверждение прослеживается до источника.
- Спорные записи отличаются от действующих.
- Определён ответственный за разрешение противоречия.
- У производной записи не расширены права чтения относительно допустимого раскрытия источника.
Проверить себя
Что делать с двумя источниками, если один новее, а другой имеет более высокий статус?
Свериться с разбором
Сначала проверить область действия и полномочия обновления. Дата сама по себе не разрешает конфликт. До решения владельца сохраняют противоречие и ограничивают автоматическое применение.
Что прочитать по теме · 3
- Knowledge Engineering and Management: The CommonKADS MethodologyГлавы о моделях организации, задачи, агента и знаний; глава об извлечении знаний. Поиск по PDF: organization model, task model, knowledge elicitation.
- KCS v6 Practices GuideArticle Structure, KCS Article State, Reuse is Review, Content Standard, Archiving Old Articles, Content Health Indicators.
- PROV-O: The PROV OntologyStarting Point Terms: Entity, Activity, Agent и отношения происхождения.
Практические шаги и учебный кейс — адаптация для этой программы. Роль и ограничения каждого источника указаны в библиографии.
Спроектировать
Спроектировать поток извлечения и проверки знаний с управляемыми ошибками и воспроизводимым происхождением.
Разделите этапы обработки§
Практичная схема: обнаружить источник → получить разрешённую версию → разобрать структуру → извлечь кандидаты → проверить их → опубликовать принятые записи. Для каждого перехода определите вход, выход, допустимые ошибки и человека или программу, отвечающую за действие.
Сохраняйте стабильные идентификаторы источника и утверждения. Повторная обработка той же версии не должна создавать новый независимый факт. Если источник изменился, нужно выяснить, какие записи зависят от изменённого фрагмента, а затем перепроверить их и производные представления.
Выберите подход к извлечению§
| Подход | Когда рассмотреть | Основной риск |
|---|---|---|
| Ручная запись по шаблону | Небольшой объём и дорогая ошибка | Нагрузка на эксперта и неодинаковая детализация |
| Детерминированный разбор | Стабильные таблицы и формы | Изменение формата незаметно ломает извлечение |
| LLM предлагает кандидаты | Разнообразные неструктурированные материалы | Потеря условий, выдуманные связи, неверное объединение |
| Смешанный процесс | Разные типы источников и рисков | Неясная граница автоматической и ручной проверки |
Проверка должна видеть пропуски§
Если эксперт проверяет только предложенные записи, незамеченными остаются сведения, которые извлекатель вообще пропустил. Выберите небольшую размеченную выборку исходных материалов и сравните с ожидаемыми утверждениями: что найдено верно, что добавлено ошибочно и что потеряно.
Отдельно проверяйте исключения, отрицания, единицы измерения, сроки действия и ссылки на приложения. Например, «не применять при температуре ниже заданной границы» нельзя превращать в общее разрешение после удаления отрицания или условий.
Не считайте автоматический текст источника доверенной командой для агента. В архитектуре отделите извлекаемый материал от инструкций системы и ограничьте возможность действовать по содержимому документов. Это проектное требование к обработке недоверенных входов.
Практика: Контракт извлечения
- Опишите вход и выход каждого этапа обработки.
- Добавьте набор документов с конфликтом, исключением и изменённой версией.
- Проверьте поведение при повторном запуске и при отказе проверки.
Критерии готовности
- Один повторный запуск не размножает записи.
- Отклонённый кандидат не попадает в рабочую выдачу.
- Можно восстановить источник и версию результата.
- Проверка учитывает как ошибочные добавления, так и пропуски.
Проверить себя
Почему история запусков извлекателя не заменяет происхождение каждой записи?
Свериться с разбором
История показывает выполнение процесса, но может не связывать конкретное утверждение с фрагментом и версией источника. Для проверки и пересмотра нужна эта связь.
Что прочитать по теме · 2
- Machine Knowledge: Creation and Curation of Comprehensive Knowledge BasesТемы canonicalization, entity linking, knowledge extraction, knowledge curation.
- PROV-O: The PROV OntologyStarting Point Terms: Entity, Activity, Agent и отношения происхождения.
Практические шаги и учебный кейс — адаптация для этой программы. Роль и ограничения каждого источника указаны в библиографии.