База знаний

Материал из Вики Optimism
Перейти к навигации Перейти к поиску

База знаний это собранные в одном месте рабочие документы компании, по которым сотрудник находит ответ сам: регламенты, инструкции, описания товаров, разборы частых вопросов клиентов. От общей папки с файлами её отличает не место хранения, а порядок ведения. У каждой статьи есть тема, владелец, дата последнего пересмотра и адрес, по которому на неё ссылаются остальные.

У термина три разных значения, и путаница между ними стоит дороже, чем кажется. В информатике базой знаний называют хранилище фактов и правил вывода внутри экспертной системы. В работе компании так называют внутренний справочник для сотрудников либо справочный центр для клиентов. Третье значение пришло вместе с корпоративными ИИ-ассистентами: это корпус документов, по которому отвечает языковая модель.

Дальше речь про второе и третье значение, то есть про сами документы и порядок их ведения. Как система ищет в них нужный фрагмент, разобрано в статьях RAG и ИИ-ассистент, и здесь это не повторяется. Важно другое. Беспорядок, который сотрудник обходит привычкой и вопросом коллеге, для модели непреодолим, и цена такого беспорядка уже измерена, числа приведены ниже.

Чем отличается от соседних понятий

Половина споров о внедрении базы знаний это спор о том, что именно внедряют. Покупка портала, наведение порядка в документах и подключение ассистента к ним это три разные работы.

Что это Единица хранения Кто отвечает за свежесть Чем отличается от базы знаний
Общий диск, файловое хранилище файл никто, владелец есть у папки нет срока пересмотра и нет способа понять, какая версия действует
Вики компании, портал, раздел в CRM страница автор последней правки это движок: на нём базу знаний можно вести, а можно просто складывать файлы
Справочный центр для клиентов публичная статья поддержка или маркетинг написан для внешнего читателя, поэтому у него другой язык и другая глубина, а живёт он внутри пути клиента
База данных строка таблицы администратор системы хранит значения; ответить по ней на вопрос «почему так» нельзя
Поисковый индекс ассистента фрагмент документа пересобирается из базы знаний производная от базы, а первоисточником остаётся сама база
Датасет размеченный пример владелец модели нужен, чтобы обучить модель; база знаний ничему не учит, её читают в момент вопроса

Отдельно стоит развести два значения самого термина. Классическое, из информатики, описывает часть программы, которая умеет выводить новые утверждения из старых. Рыночное описывает справочник, написанный людьми для людей. Общего у них меньше, чем общего слова: справочник компании ничего не выводит, он отвечает текстом, который кто-то однажды написал.

Откуда взялось

Термин вырос в исследованиях искусственного интеллекта шестидесятых и семидесятых годов. Экспертные системы формально введены около 1965 года Стэнфордским проектом эвристического программирования под руководством Эдварда Фейгенбаума; из ранних систем известны MYCIN, диагностировавшая инфекционные заболевания, и DENDRAL, определявшая строение органических молекул. Экспертная система делится на две части: базу знаний, где лежат факты и правила, и машину вывода, которая применяет правила к фактам.

Само слово появилось, чтобы отделить такое хранилище от привычной базы данных. В семидесятых почти все крупные управленческие системы держали данные в иерархических или реляционных базах, и разница читалась просто. База данных хранит строки про конкретных Ивановых и Петровых. База знаний хранит утверждение «все люди смертны» и умеет вывести из него частный случай. Международные словари закрепили именно этот смысл: русская Википедия приводит определение по двум стандартам, ISO/IEC/IEEE 24765-2010 и ISO/IEC 2382-1:1993, где база знаний это база данных с правилами вывода и сведениями об опыте и знаниях в предметной области. Область науки, изучающую такие хранилища, называют инженерией знаний, и к машинному обучению она отношения не имела: знания в неё вносил человек.

Корпоративная ветка началась отдельно и позже. Двадцать пятого марта 1995 года программист Уорд Каннингем поставил на сайт своей компании первый вики-движок WikiWikiWeb, название которого пришло от гавайского слова «wiki», «быстро», в аэропорту Гонолулу сотрудник за стойкой посоветовал ему шаттл Wiki Wiki, ходящий между терминалами. Первый вики с первого февраля 2015 года работает только на чтение, а сама идея страницы, которую правит любой сотрудник, разошлась по корпоративным порталам. Оттуда и пошло второе значение термина, к правилам вывода и экспертным системам не относящееся вовсе.

Как устроена

Единица знания

Статья закрывает один вопрос целиком. Проверка простая: заголовок статьи переписывается вопросом, и статья отвечает на него полностью, без отсылок «смотри также пункт 4.2 регламента». Регламент на сорок страниц единицей знания не является, это сборник, и работать с ним придётся как со сборником: резать на части при каждой правке и при каждом поиске.

Требование выглядит редакторской придиркой ровно до того момента, когда к базе подключают поиск. Поиск возвращает фрагмент, а не документ. Если в одной статье уложены пять тем, четыре из них в ответе лишние, и они же занимают место, за которое заказчик платит на каждом вопросе.

Владелец и срок пересмотра

У каждой статьи один человек, отвечающий за содержание, и дата, после которой статью надо перечитать заново. Владелец записывается должностью, а не фамилией: люди уходят, роль остаётся. Срок пересмотра назначают по скорости протухания предмета. Единое число на всю базу тут не работает: прайс и условия доставки живут неделями, описание процедуры увольнения годами.

Пустое поле владельца выглядит мелочью в таблице и работает как отложенная поломка. Пока владельца нет, никто не узнает, что документ перестал быть верным, и первым об этом сообщит клиент. Статья про RAG называет базу знаний без владельца отдельным источником риска для ассистента, и это тот же самый дефект, просто с более громкими последствиями.

Структура и словарь

Дерево разделов, единый шаблон статьи, перекрёстные ссылки и общий словарь терминов. Последнее важнее, чем кажется: если склад называет товар артикулом, продажи наименованием, а поддержка народным прозвищем, поиск по базе не найдёт ничего ни человеку, ни машине. Одно утверждение живёт в одном месте, остальные статьи на него ссылаются. Копия того же утверждения в соседней статье рано или поздно разойдётся с оригиналом, и тогда база начнёт спорить сама с собой.

Права доступа

Права описываются на уровне статьи. Уровня общей папки для этого мало, и причина техническая: при подключении ассистента права считаются на этапе поиска, иначе система перескажет сотруднику документ, которого он не должен видеть. Сам механизм разбирает статья RAG, а работа здесь ложится на базу: пока у документов нет внятных уровней доступа, ассистенту нечего показывать и нечего скрывать.

Что меняется, когда базу читает языковая модель

Схема сравнения того, что видит в базе знаний человек и что получает языковая модель
Одна и та же база знаний глазами сотрудника и глазами языковой модели

У базы знаний появился второй читатель, и он ведёт себя иначе. Сотрудник, не найдя ответа, спросит коллегу в чате. Модель не спросит: она ответит по тем фрагментам, которые вернул поиск, и ответит уверенно. Поэтому дефекты, которые компания годами обходила живыми людьми, впервые становятся видимыми и измеримыми.

Устаревшая копия рядом с действующей версией. Это самая дорогая из всех неисправностей базы, и разница с прочим мусором измерена. Бенчмарк HoH, собранный в Университете науки и технологий Китая из версий статей Википедии (96 124 вопроса и 219 463 документа), сравнил два случая. Шесть фрагментов, близких к вопросу по смыслу, но без ответа в тексте, роняли итоговую оценку модели Llama-70B меньше чем на 2 %. Один устаревший фрагмент по теме вопроса ронял ту же оценку больше чем на 24 %, долю безупречных ответов больше чем на 10 %, а долю ответов, отнесённых авторами к вредным, поднимал на величину до 11 %. У моделей поменьше, Llama-8B и Qwen-7B, доля безупречных ответов падала примерно на 20 %. Вывод для владельца базы прямой: статья по теме, но без ответа, обходится дёшево, устаревшая редакция нужной статьи дорого.

Почти подходящий документ хуже постороннего. Работа группы из Римского университета Сапиенца, представленная на конференции SIGIR в июле 2024 года, проверяла, какие именно фрагменты стоит подавать модели. Документы, которые поиск ставит высоко, но ответа в себе не содержат, качество ответа снижали. Добавление в тот же запрос случайных документов качество, наоборот, поднимало, в их замере до 35 %. Объяснения этому авторы не дают и называют результат контринтуитивным. Для владельца базы важен сам знак: близкая по теме статья без ответа вредит сильнее, чем документ не по делу.

Противоречия между документами. Обзор исследователей Университета Цинхуа, Уэстлейкского университета и Китайского университета Гонконга, вышедший в марте 2024 года, выделяет конфликт между найденными документами в отдельный класс проблем наряду с конфликтом между документом и тем, что модель усвоила при обучении. Две статьи базы, по-разному описывающие один порядок возврата, для человека повод уточнить у старшего. Для модели это два равноправных источника, и выбор между ними она сделает сама.

Знание в картинке и скане. Модель работает с тем, что прочитано текстом. Хранилище файлов GigaChat, например, принимает документы в форматах txt, doc, docx, pdf, epub, ppt, pptx и xlsx, изображения в jpeg, png, tiff и bmp, с ограничением в 40 МБ на текстовый файл (документация обновлена 17 июля 2026 года, сверено 19.09.2026). Список форматов у каждого поставщика свой и конечный. Сканы договоров и схемы, нарисованные картинкой, попадают в такую базу файлом, содержимое которого поиску недоступно. Чтобы извлечь оттуда текст, нужен отдельный шаг распознавания, разобранный в статьях Компьютерное зрение и ИИ для работы с документами.

Дата и статус внутри текста статьи. Сотрудник видит в интерфейсе, что документ обновлён вчера, а рядом висит красная плашка «черновик». В поиск уходит голый фрагмент, и вся эта обвязка до модели не доезжает. Поэтому дату вступления в силу, номер редакции и пометку об отмене пишут словами в самом тексте. Отдельного замера под это правило нет, оно выводится из устройства самого поиска.

Документ в базе знаний при этом становится ещё и каналом атаки: правка документа меняет поведение ассистента. Сценарий разобран в той же статье про RAG, и повторять его здесь незачем; для ведения базы из него следует одно правило, право на запись в базу знаний по цене ошибки равно правам администратора.

Что делать на практике

  • Начинать со списка вопросов, которые уже задают. Источник списка это тикеты поддержки, переписки в рабочих чатах, разметка записанных звонков (Речевая аналитика) и то, что спрашивает новичок в первую неделю. Дерево разделов рисуется после, под собранные вопросы.
  • Держать правило «одна статья, один вопрос» с самого начала. Разрезать сросшийся регламент через год дороже, чем написать шесть отдельных статей сразу.
  • Завести у каждой статьи два обязательных поля: владелец должностью и дата следующего пересмотра. Статья без владельца в базу не принимается.
  • Писать дату вступления в силу и номер редакции словами в текст статьи. Свойств файла и плашки в интерфейсе для этого мало.
  • Убирать отменённые редакции из рабочей базы. Архив нужен, но живёт он отдельно и в поисковый индекс ассистента не попадает.
  • Перевести в текст то, что лежит картинками и сканами. Начинать с документов, которые спрашивают чаще всего.
  • Свести словарь терминов: один предмет называется одним словом во всех статьях, остальные написания уходят в синонимы.
  • Встроить ведение в рабочий процесс, чтобы статья правилась тем же человеком и в той же задаче, где обнаружено расхождение. Отдельное время «на документацию» не выделяется никогда, и это общее место любой автоматизации бизнес-процессов.
  • Перед подключением ассистента прогнать базу набором контрольных вопросов с заранее известными ответами: приём описан в статье RAG и проверяет он в первую очередь документы.
  • Решить судьбу базы до старта большого проекта: порядок работ и роли разобраны в статье Внедрение ИИ.

Чем измеряют

  • Доля статей с назначенным владельцем. Первая метрика, с которой начинают, и единственная, которую видно сразу после заведения базы.
  • Доля статей, просроченных по сроку пересмотра. Рост этой доли предсказывает смерть базы за несколько месяцев до того, как она станет заметна людям.
  • Доля вопросов поддержки, на которые в базе нет статьи. Считается по тикетам за период, показывает белые пятна.
  • Повторяемость вопроса. Сколько раз за месяц спросили одно и то же. Единственная метрика, которая ведёт к правке самого продукта или процесса.
  • Число дублей. Сколько статей отвечают на один вопрос, и расходятся ли они между собой.
  • Доля документов в нечитаемом для поиска виде: сканы, картинки, таблицы в виде изображений.
  • Со стороны ассистента: доля вопросов, где нужный фрагмент вообще попал в выдачу поиска. Считает её система поиска, а чинится она правкой документов.
  • Не метрика: число статей в базе. Рост числа статей без чистки означает рост числа противоречий, и связь эта прямая.

Почему базы знаний умирают

База знаний умирает тихо и почти всегда одинаково. Её не закрывают приказом, ею просто перестают пользоваться, и на вопрос снова отвечает самый опытный сотрудник в чате.

Ведение не встроено в работу. Написание статьи стоит времени, а время выделяется под задачи, которые кто-то принимает. Пока за статью никто не спрашивает, её не будет.

Нет владельца. Правку некому принять, устаревание некому заметить, спор о формулировке некому закрыть.

Старое не удаляется. Отменённый регламент остаётся лежать рядом с действующим, потому что удалять страшно, а помечать лень. Дальше работает механика из раздела выше, и сильнее всех от неё страдает ассистент.

Поиск не находит. Статья есть, но названа внутренним термином, которого никто не набирает. Формально база полная, практически пустая.

База заведена под проект. Проект кончился, база осталась без хозяина и за полгода превратилась в архив непонятного назначения.

Знание живёт в переписке. Ответ дан в чате, там и остался. Через месяц его не найдёт даже тот, кто писал.

Признаки, по которым это видно со стороны: доля просроченных статей растёт от месяца к месяцу, новые статьи пишут два человека из сорока, а вопросы в рабочем чате повторяются теми же словами, что и полгода назад.

Ограничения и спорные места

Ходовые цифры рынка в статью не взяты, потому что первоисточника у них нет. По запросам про базу знаний ходят утверждения, что её специально ищут на сайте 88 % клиентов и что бизнес с базой знаний зарабатывает на 47 % больше конкурентов, а также что некий крупный маркетплейс снизил число ошибок при оформлении заказов на 30 %. Поиск первоисточника 19.09.2026 вывел к тем же коммерческим страницам и к блогу поставщика программы; исследования с годом, выборкой и методикой за этими числами найти не удалось. Пока первоисточник не назван, все три числа остаются рекламным утверждением.

Замеры про устаревшие документы сделаны не на корпоративных документах. Бенчмарк HoH построен из версий статей Википедии, вопросы в нём фактологические, язык английский. Порядок величины он показывает надёжно, перенос конкретных процентов на регламент российской компании не доказан ничем.

Связь порядка в базе знаний с деньгами публично не измерена. Точность поиска и качество ответов померены многократно, а замера вида «база с назначенными владельцами приносит столько-то» в открытых источниках найти не удалось. Всё, что об этом говорят, идёт от поставщиков платформ и от их собственных клиентских историй.

Стандарта корпоративной базы знаний не существует. Стандарты ISO, на которые ссылается определение термина, описывают понятие информатики. Как вести справочник компании, международный стандарт не предписывает, поэтому любые «требования к базе знаний» это чья-то методика, и сослаться в споре о ней не на что.

Платформы здесь не сравниваются. Выбор движка зависит от требований к размещению, интеграциям и доступу, и обзор вендоров быстро устаревает. Ограничения конкретных облачных сервисов, включая размеры фрагментов и лимиты индексов, разобраны в статье ИИ-ассистент.

Правовая сторона не толкуется. Передача документов компании внешнему сервису затрагивает персональные данные и коммерческую тайну; норма названа в той же статье про ИИ-ассистента, а её применение к конкретному договору это работа юриста.

Что здесь быстро устаревает

  • Списки поддерживаемых форматов и предельные размеры файлов у поставщиков моделей: они меняются с каждым обновлением документации.
  • Числа из бенчмарков про устаревшую информацию: наборы обновляются, модели выходят каждый квартал, а измеренный разрыв между сильными и слабыми моделями сокращается.
  • Требования к оформлению документов под поиск. Сегодня дату и статус приходится писать словами в тексте; поставщики уже учатся передавать метаданные фрагмента вместе с ним.
  • Состав и названия платформ для ведения базы знаний.
  • Медленнее всего устаревает главное: одна статья на один вопрос, владелец должностью, срок пересмотра и удаление отменённого.

См. также

Источники

  1. База знаний. Определение по ISO/IEC/IEEE 24765-2010 и ISO/IEC 2382-1:1993, понятие инженерии знаний. Русская Википедия. Проверено 19.09.2026. https://ru.wikipedia.org/wiki/База_знаний
  2. Knowledge base. Происхождение термина: слово введено, чтобы отличить хранилище знаний от базы данных, семидесятые годы. Английская Википедия. Проверено 19.09.2026. https://en.wikipedia.org/wiki/Knowledge_base
  3. Expert system. Экспертные системы введены около 1965 года Стэнфордским проектом эвристического программирования под руководством Эдварда Фейгенбаума; MYCIN и DENDRAL; деление на базу знаний и машину вывода. Английская Википедия. Проверено 19.09.2026. https://en.wikipedia.org/wiki/Expert_system
  4. WikiWikiWeb. Первый вики запущен 25 марта 1995 года Уордом Каннингемом, происхождение названия от гавайского «wiki», режим только для чтения с 1 февраля 2015 года. Английская Википедия. Проверено 19.09.2026. https://en.wikipedia.org/wiki/WikiWikiWeb
  5. Ouyang J., Pan T., Cheng M. и др. HoH: A Dynamic Benchmark for Evaluating the Impact of Outdated Information on Retrieval-Augmented Generation: 96 124 вопроса и 219 463 документа, влияние одного устаревшего фрагмента против шести посторонних. Университет науки и технологий Китая, arXiv:2503.04800, версия от 18 июля 2025 года. Проверено 19.09.2026. Числовые значения сняты с полного текста. https://arxiv.org/abs/2503.04800 и https://arxiv.org/html/2503.04800v3
  6. Cuconasu F., Trappolini G., Siciliano F. и др. The Power of Noise: Redefining Retrieval for RAG Systems: высоко ранжированные документы без ответа снижают качество, случайные документы повышают его до 35 %. Римский университет Сапиенца, SIGIR 2024, arXiv:2401.14887, версия от 1 мая 2024 года. Проверено 19.09.2026. Место работы авторов и сведения о конференции сняты с полного текста. https://arxiv.org/abs/2401.14887 и https://arxiv.org/html/2401.14887v4
  7. Xu R., Qi Z., Guo Z. и др. Knowledge Conflicts for LLMs: A Survey: три класса конфликтов знаний, включая конфликт между найденными документами. Университет Цинхуа, Уэстлейкский университет, Китайский университет Гонконга, arXiv:2403.08319, первая версия от 13 марта 2024 года. Проверено 19.09.2026. Места работы авторов сняты с полного текста. https://arxiv.org/abs/2403.08319 и https://arxiv.org/html/2403.08319v2
  8. Загрузить файл. Поддерживаемые форматы документов, изображений и аудио, предельные размеры файлов. Документация GigaChat API, Сбер, обновлено 17 июля 2026 года. Проверено 19.09.2026. https://developers.sber.ru/docs/ru/gigachat/api/reference/rest/post-file
Источник — https://wiki.optimism.ru/index.php?title=База_знаний&oldid=5747