Корпоративная AI-база знаний: архитектура внутреннего ассистента
Внутренний ассистент начинается с актуальных разрешённых и проверяемых evidence
Source contracts, staged ingestion, permission-aware retrieval и human review
Авторский KBASE-9 workflow с примером input/output и acceptance criteria
корпоративная AI-база знаний, RAG ассистент, enterprise RAG assistant, AI knowledge base, архитектура внутреннего ассистента и KBASE-9
$ initialize knowledge-base --contract KBASE-9
> register: source / owner / revision / scope
> stage: extract / normalize / chunk / attach locator
> verify: access / currentness / known-answer / no-answer
> promote: candidate version / eligible retrieval
> reconcile: source registry / index / answer receiptКорпоративная AI-база знаний — не папка с документами, к которой подключили чат. Это система работы с доказательствами: она определяет, какой источник можно использовать, для кого, в какой версии, с каким ограничением ответа и как человек сможет проверить или исправить результат.
Этот материал отвечает на узкий вопрос внедрения: как спроектировать внутреннего ассистента вокруг управляемой базы знаний. За более широким объёмом работ обращайтесь к RAG-системам. Если нужен план delivery, роли и контролируемый пилот, начните с брифа AI-проекта. Ни одна из этих страниц не обещает, что универсальный чат-бот безопасно заменит источник истины.
Сначала определите решение, которое ассистенту разрешено поддерживать
Первое архитектурное решение — не модель и не векторная база. Это задача, которую ассистент вправе выполнять. У полезной ограниченной задачи известны читатель, источники доказательств, последствия ошибки и ответственный владелец. Например: помочь support-команде найти действующую процедуру, помочь продажам найти правило по продукту или помочь operations-команде сверить исключение с политикой.
Сразу зафиксируйте и запреты. Ассистент не должен придумывать политику, показывать документы вне scope пользователя, превращать черновик в утверждённое решение или выдавать отсутствие доказательств за ответ. Короткий маршрут no-answer — полезная функция: он подсказывает сотруднику открыть источник, обратиться к владельцу или зарегистрировать контентный пробел.
До ingestion соберите реестр источников. Для каждого нужны устойчивый ID, бизнес-владелец, audience или permission scope, версия или revision marker, lifecycle state, путь обновления и URL, который человек может открыть. Файл без владельца или механизма обновления должен попадать в review queue, а не в production retrieval.
Спроектируйте контракт знаний раньше индекса
Ассистенту нужно извлекать доказательства, а не просто семантически похожий текст. Практичный knowledge contract разделяет четыре записи:
| Запись | Минимальные поля | Зачем нужна |
|---|---|---|
| Источник | ID, владелец, revision, scope, lifecycle, locator | Подтверждает авторитет документа |
| Производный chunk | source ID, revision, locator, text hash, access labels | Делает каждый результат retrieval проверяемым |
| Запрос | user identity, role, tenant, purpose, timestamp | Применяет те же границы при поиске |
| Answer receipt | retrieved IDs, versions, policy decision, feedback | Позволяет проверить ответ после выдачи |
Авторитетной остаётся запись источника. Chunks, embeddings и строки индекса — заменяемые проекции. Это различие предотвращает типовую ошибку: старый chunk остаётся в индексе после изменения процедуры или отзыва доступа.
Используйте source metadata в retrieval filters, а не только в отчётности. Отдел, tenant, роль, состояние документа, язык и дата вступления в силу могут определять допустимость кандидата ещё до similarity ranking. Если система не может последовательно применять границу во время retrieval, ей нельзя заявлять, что она наследует права из document system.
Спроектируйте workflow как контролируемый маршрут
Ниже — авторский паттерн KBASE-9. Он намеренно достаточно мал, чтобы проверить его на одном подразделении до широкого rollout.
- Register. Принять source event с source ID, revision, owner, scope и lifecycle.
- Validate. Отправить неполные metadata, неподдерживаемые форматы и источники без владельца в видимую очередь.
- Derive. Извлечь текст, нормализовать, создать детерминированные chunks и добавить source locators.
- Stage. Записать candidate version вне live retrieval set.
- Verify. Проверить count, hashes, permissions, known-answer probes и намеренные no-answer probes.
- Promote. Атомарно открыть только проверенную candidate version допустимым запросам.
- Answer. Извлечь разрешённые доказательства, сформировать ограниченный ответ и вернуть citations с uncertainty.
- Review. Направить low-confidence, конфликтные или значимые запросы назначенному человеку.
- Reconcile. Сверить source register, staged jobs и live index; retry, quarantine или удалить устаревшие проекции.
Критическая граница лежит между staging и promotion. Успешный extraction job ещё не доказывает, что ассистенту можно использовать результат. Promotion требует явных проверок, а удалению нужен быстрый exclusion gate: отозванный или устаревший материал перестаёт появляться, пока downstream stores сходятся к новому состоянию.
Пример запроса и проверяемого ответа
Сотрудник operations спрашивает: «Какое согласование нужно для исключения из действующей закупочной политики?» Запрос несёт роль и подразделение. Retrieval layer сначала ограничивает кандидаты актуальными procurement policies, доступными этой роли. Затем ответ называет правило, даёт ссылку на revision, locator раздела и объясняет, нужен ли менеджер или владелец финансов.
Если два действующих документа противоречат друг другу, ассистент должен показать конфликт и маршрут, а не выбирать политику по похожести формулировок. Хороший ответ может быть коротким:
Найдено доказательство: procurement-policy / revision 18 / section 4.2
Совпадение scope: operations / approved access
Вывод: нужно согласование менеджера; выше указанного порога требуется finance review
Неопределённость: второй current source содержит конфликтное правило исключения
Маршрут: владелец procurement / приложить оба source locatorТакой результат полезнее гладкого общего ответа: читатель проверяет evidence, а владелец устраняет конфликт источников.
Считайте интеграции контрактами, а не коннекторами
Внутренний ассистент обычно касается document system, identity provider, бизнес-приложения и destination для feedback или задач. Само название ПО не делает интеграцию безопасной. У каждой границы нужен контракт.
Document connector должен отдавать устойчивый source ID, сигнал revision, deletion event или периодическую reconciliation, permission labels и рабочий locator. Identity boundary обязана разрешать активного пользователя и group claims, не доверяя тексту роли, присланному клиентом. Writable destination требует idempotency или duplicate-safe lookup, назначенного владельца и независимого read-back. Ассистент должен хранить request и answer receipt, не копируя чувствительный source content в неконтролируемый лог.
Для scheduled ingestion подготовьте duplicate, out-of-order и missed events. Job key вида sourceId + revision + pipelineVersion делает retries проверяемыми. Reconciliation ловит изменения источников, пропущенные event stream. Событие удаления или отзыва доступа сначала исключает source IDs из retrieval, затем удаляет производные представления и проверяет отсутствие через probes.
Зафиксируйте acceptance criteria до пилота
Пилот готов к реальным внутренним пользователям, только когда команда способна проверить важные failure paths. Acceptance criteria должны быть наблюдаемыми и привязанными к одному owner.
- Разрешённый пользователь получает действующий approved source и открывает процитированный locator.
- Пользователь вне scope не получает этот источник через обычные варианты формулировки.
- Изменённый документ становится current только после проверки staged candidate.
- Удалённый или отозванный источник исключается из retrieval до сообщения о завершении workflow удаления.
- Намеренно неотвечаемый запрос приводит к no-answer или review route, а не к выдуманной процедуре.
- Конфликтующие источники видны reviewer с source IDs и revisions.
- Ошибочный job можно retry или quarantine с причиной; он не исчезает молча.
- Answer receipt сопоставляется с versions источников и policy decision.
Не сводите эти критерии к общему проценту точности, если у команды нет определённых test set, метода выборки и порога приёмки. Для первого пилота curated evaluation set с known answers, access-denied cases, stale revisions и no-answer cases полезнее, чем метрика без ясного смысла.
Эксплуатируйте ассистента как изменяющуюся систему
После запуска базе знаний требуется регулярное владение. Наблюдайте source-to-index lag, ошибки promotion candidate, попытки retrieval без прав, coverage citations, долю no-answer, конфликтные маршруты и feedback, который привёл к исправлению источника. Эти сигналы означают разное: no-answer может быть здоровой границей, а скачок после обновления процедуры — признаком проблемы ingestion или ownership.
Назначьте для каждого класса источников ритм review и путь retirement. Ассистент должен показывать, когда evidence достаточно устарело, чтобы решение принял человек. Когда владелец уходит или документ перестаёт получать revisions, задайте lifecycle явно; не оставляйте его «current» только потому, что последний index job завершился успешно.
Расширение должно следовать за доказательствами, а не за спросом на интерфейс. Добавляйте по одному подразделению, классу источников или уровню последствий. Переиспользуйте тот же register, permission checks, evaluation set, review route и rollback path. Так корпоративная AI-база знаний остаётся проверяемой по мере роста.
Контролируемый первый пилот
Выберите один узкий внутренний вопрос с ответственным владельцем, ограниченной коллекцией источников и ясным no-answer route. Создайте source register, соберите staged ingestion path, проверьте доступ и stale-content cases, затем откройте систему только этой группе. Разбирайте ответы и source gaps вместе с людьми, которые владеют исходной процедурой.
В этом и состоит практическая архитектура внутреннего ассистента: актуальные разрешённые доказательства, видимая неопределённость и ответственный человеческий контроль. Чтобы обсудить контролируемый RAG-пилот для конкретного workflow, посетите страницу RAG-систем или начните с брифа AI-проекта.
require(source.id && source.owner && source.revision && source.scope);
require(candidate.locators.length && candidate.accessVerified);
require(testSet.knownAnswer && testSet.accessDenied && testSet.noAnswer);
if (!candidate.accepted) route = "retry-or-quarantine";
if (source.revoked || source.stale) route = "exclude-from-retrieval";
if (answer.conflict || answer.consequential) route = "named-human-review";