Как сделать ИИ-агента для базы знаний компании

Что получится в результате

Соберем ИИ-агента, который отвечает сотрудникам по внутренним документам компании и показывает, откуда взял ответ. Это не чат “на все темы”, а рабочий помощник по базе знаний: регламенты, инструкции, FAQ, онбординг, продуктовые документы, политики и шаблоны.

Первая версия будет работать так:

1. документы лежат в `knowledge_sources`;
2. таблица `source_registry` хранит список источников, владельцев и права доступа;
3. n8n забирает новые или измененные документы;
4. агент разбивает документы на смысловые блоки;
5. блоки попадают в `knowledge_chunks`;
6. для каждого блока сохраняются ссылка, владелец, дата обновления и уровень доступа;
7. пользователь задает вопрос через форму, чат или Slack;
8. агент ищет релевантные блоки;
9. проверяет, имеет ли пользователь право видеть найденные документы;
10. отвечает только на основе найденных источников;
11. показывает ссылки на документы;
12. вопросы без ответа попадают в `unanswered_questions`;
13. владелец знания обновляет документ;
14. регрессионные тесты проверяют, что ответы не сломались.

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

Что понадобится

• n8n Cloud или self-hosted n8n.
• Google Drive, Notion, Confluence или другой источник документов.
• Google Sheets для реестра, логов и тестов.
• Векторная база или встроенный RAG-инструмент платформы.
• LLM API для ответа по найденным фрагментам.
• 30-100 документов для первого индекса.
• Список ролей сотрудников и правил доступа.
• 20 тестовых вопросов, по которым можно проверить качество.
• Владелец базы знаний, который будет принимать вопросы без ответа.

Шаг 1. Выберите одну аудиторию

Не начинайте с “вся база знаний для всех”.

Для первого прототипа выберите одну аудиторию:

новые сотрудники отдела продаж

Что входит:

• онбординг;
• продуктовые FAQ;
• инструкции по CRM;
• скрипты коммуникации;
• регламент передачи клиента;
• ответы на частые вопросы.

Что не входит:

• зарплаты;
• персональные данные;
• закрытые финансовые документы;
• юридические договоры;
• security-инциденты;
• личные переписки;
• документы других отделов без прав доступа.

Проверка: вы можете назвать одну группу пользователей и 5-7 типов документов, по которым агент будет отвечать.

Шаг 2. Создайте структуру источников

В Google Drive, Notion или Confluence создайте рабочее пространство:

Knowledge AI agent
  knowledge_sources
  archived_sources
  drafts
  owner_review
  exports

Правило:

в индекс попадают только документы из knowledge_sources
drafts не индексируются
archived_sources не используются для новых ответов

Проверка: у команды есть одно понятное место, откуда агент берет знания.

Шаг 3. Создайте таблицу проекта

Создайте Google Sheet:

Knowledge base AI agent

Добавьте листы:

source_registry
knowledge_chunks
access_rules
question_log
unanswered_questions
owner_tasks
answer_feedback
regression_tests
index_runs
error_log
settings

Проверка: n8n может читать и обновлять таблицу.

Шаг 4. Заполните source_registry

`source_registry` - главный реестр документов.

Колонки:

source_id
source_type
source_title
source_url
department
audience
owner_name
owner_role
access_level
status
last_updated_at
review_after
indexed_at
version
notes

Статусы:

active
draft
needs_review
archived
do_not_index

Уровни доступа:

public_internal
department_only
managers_only
restricted

Проверка: у каждого документа есть владелец, статус и уровень доступа.

Шаг 5. Назначьте владельцев знаний

Для каждого раздела назначьте человека, который отвечает за актуальность.

Пример:

CRM инструкции -> руководитель продаж
Продуктовые FAQ -> product marketing
Онбординг -> HR
Тарифы -> finance или sales ops
Security правила -> IT/security

Владелец должен:

• подтверждать новые документы;
• разбирать вопросы без ответа;
• обновлять устаревшие инструкции;
• закрывать противоречия между документами;
• принимать изменения в базе знаний.

Проверка: документ без владельца получает `status = needs_review` и не считается надежным источником.

Шаг 6. Создайте access_rules

В `access_rules` добавьте колонки:

rule_id
access_level
allowed_roles
allowed_departments
denied_roles
description
is_active

Пример:

public_internal | все сотрудники | all | none
department_only | только отдел документа | sales, support, product | external
managers_only | руководители | managers | interns, contractors
restricted | ручной доступ | security, legal, finance | all_without_access

Проверка: для каждого `access_level` понятно, кто может видеть ответ.

Шаг 7. Подготовьте документы к индексации

Перед запуском агента очистите базу знаний.

Удалите или вынесите:

• дубли одной инструкции;
• устаревшие версии;
• файлы “копия финальная v3 новая”;
• документы без владельца;
• черновики;
• документы без даты обновления;
• противоречащие инструкции.

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

Шаг 8. Настройте workflow индексации

Создайте workflow:

Knowledge base indexing

Минимальные узлы:

1. `Schedule Trigger`;
2. `Read source_registry`;
3. `Filter status = active`;
4. `Load source content`;
5. `Split into chunks`;
6. `Create embeddings`;
7. `Save chunks`;
8. `Write index_runs`.

Для первого запуска используйте ручной trigger, чтобы не индексировать мусор автоматически.

Проверка: workflow может обработать один документ и записать результат в `knowledge_chunks`.

Шаг 9. Разбейте документы на смысловые блоки

Не режьте документ механически по 1000 символов без структуры.

Правило chunking:

один chunk = один смысловой блок: вопрос FAQ, раздел инструкции, шаг процесса, правило или таблица

В `knowledge_chunks` добавьте колонки:

chunk_id
source_id
chunk_title
chunk_text
chunk_type
source_url
source_section
owner_name
access_level
last_updated_at
embedding_id
status
created_at

Типы блоков:

faq
instruction_step
policy_rule
process
definition
table
template
warning

Проверка: по одному chunk можно понять смысл без чтения всего документа.

Шаг 10. Сохраните ссылку на источник

Каждый ответ должен уметь показать, на чем он основан.

Для каждого chunk сохраняйте:

source_url
source_title
source_section
last_updated_at
owner_name

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

Проверка: ответ агента можно открыть и проверить в исходном документе.

Шаг 11. Настройте поиск по базе

Создайте workflow:

Knowledge base answer

Минимальные узлы:

1. `Webhook` или `Slack Trigger`;
2. `Normalize question`;
3. `Detect user role`;
4. `Vector search`;
5. `Access filter`;
6. `Answer with sources`;
7. `Write question_log`;
8. `If no answer -> unanswered_questions`.

Проверка: пользователь может задать вопрос и получить ответ со ссылками.

Шаг 12. Нормализуйте вопрос

Создайте LLM-узел `Normalize question`.

Prompt:

Переформулируй вопрос сотрудника для поиска по базе знаний.
Не отвечай на вопрос.
Верни только JSON:
{
  "normalized_question": "",
  "intent": "",
  "department_context": "",
  "keywords": [],
  "needs_sensitive_data": true|false
}

Пример:

Вопрос: как передать клиента после оплаты?
normalized_question: регламент передачи клиента после оплаты
intent: process
keywords: ["передача клиента", "оплата", "регламент", "CRM"]

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

Шаг 13. Проверьте права пользователя

Перед ответом получите:

user_id
email
role
department
manager_status

Затем примените `access_rules`.

Если найденный chunk закрыт для пользователя, агент должен:

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

Проверка: сотрудник отдела продаж не видит закрытый finance-документ, даже если вопрос релевантный.

Шаг 14. Соберите prompt ответа

Создайте LLM-узел `Answer from knowledge`.

Prompt:

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

Формат ответа:
1. Короткий ответ.
2. Что сделать по шагам, если вопрос про процесс.
3. Ссылки на источники.
4. К кому обратиться, если нужен владелец.

Передавайте в prompt только отфильтрованные chunk, доступные пользователю.

Проверка: ответ содержит ссылки на источники и не выходит за найденный контекст.

Шаг 15. Ограничьте стиль ответа

В `settings` добавьте:

max_answer_length: 1200
require_sources: true
allow_no_answer: true
show_owner: true
show_last_updated: true

Правила:

• если источников нет, ответа нет;
• если источник устарел, показать предупреждение;
• если найдено противоречие, отправить вопрос владельцу;
• если вопрос просит секретные данные, отказать;
• если вопрос требует решения руководителя, не принимать решение за него.

Проверка: агент лучше честно говорит “не нашел”, чем выдумывает.

Шаг 16. Записывайте question_log

В `question_log` добавьте колонки:

question_id
created_at
user_email
user_role
department
original_question
normalized_question
answer_status
sources_used
access_denied_count
answer_text
latency_ms
feedback_score

Статусы:

answered
no_answer
access_denied
needs_owner_review
error

Проверка: можно увидеть, какие вопросы задают чаще всего.

Шаг 17. Собирайте unanswered_questions

Если ответа нет, создавайте строку в `unanswered_questions`.

Колонки:

question_id
original_question
normalized_question
suggested_owner
suggested_source
priority
status
owner_comment
created_at
closed_at

Приоритет:

high: вопрос повторяется или влияет на клиента
medium: вопрос рабочий, но не срочный
low: редкий или общий вопрос

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

Шаг 18. Создайте owner_tasks

`owner_tasks` нужен, чтобы владельцы знаний не терялись.

Колонки:

task_id
source_id
owner_name
task_type
description
related_question_ids
status
due_date
created_at
closed_at

Типы задач:

create_article
update_article
merge_duplicates
resolve_conflict
confirm_access
archive_old_source

Проверка: владелец видит конкретную задачу, а не абстрактное “улучшить базу”.

Шаг 19. Добавьте feedback на ответ

После ответа покажите пользователю простую оценку:

Полезно / Не полезно

Если не полезно, спросите:

что было не так: нет ответа, устарело, не тот документ, слишком длинно, нет доступа, другое

Записывайте в `answer_feedback`:

feedback_id
question_id
score
reason
comment
created_at

Проверка: плохие ответы превращаются в данные для улучшения, а не остаются ощущением.

Шаг 20. Сделайте проверку устаревших документов

В `source_registry.review_after` храните дату следующей проверки.

Создайте workflow:

Knowledge source freshness check

Он раз в неделю ищет:

review_after < today
status = active

И создает задачу владельцу.

Проверка: старые документы не продолжают молча участвовать в ответах.

Шаг 21. Обработайте противоречия

Если поиск нашел два источника с разными ответами, агент не должен выбирать случайный.

Правило:

если найдено противоречие, ответить кратко и отправить вопрос владельцу

Ответ пользователю:

Нашел два документа с разными правилами. Не буду выбирать сам. Отправил вопрос владельцу базы знаний.

В `owner_tasks` создайте `resolve_conflict`.

Проверка: агент не маскирует конфликт уверенным ответом.

Шаг 22. Создайте regression_tests

В `regression_tests` добавьте тестовые вопросы.

Колонки:

test_id
question
user_role
department
expected_status
expected_source_id
must_include
must_not_include
last_run_at
last_result

Примеры:

как передать клиента после оплаты?
где инструкция по CRM?
какой SLA ответа клиенту?
что делать если клиент просит скидку?
как получить доступ к закрытому отчету?

Проверка: после изменения базы или prompt можно быстро увидеть, что сломалось.

Шаг 23. Запустите первый индекс

Для первого запуска выберите 30-50 документов.

Порядок:

1. заполните `source_registry`;
2. проверьте владельцев;
3. проверьте access_level;
4. запустите `Knowledge base indexing`;
5. проверьте `index_runs`;
6. проверьте 10 случайных строк `knowledge_chunks`;
7. задайте 10 тестовых вопросов;
8. исправьте документы и chunking.

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

Шаг 24. Настройте error_log

В `error_log` добавьте колонки:

error_id
workflow_name
node_name
source_id
question_id
error_type
error_message
input_snapshot
status
owner
created_at

Типы ошибок:

source_not_found
permission_denied
empty_document
chunking_failed
embedding_failed
vector_search_failed
llm_json_invalid
no_owner
access_rule_missing

Проверка: если ответ не получился, видно, где именно сломался процесс.

Шаг 25. Сделайте безопасный запуск

Первую неделю запускайте агента в режиме:

pilot

Ограничения:

• доступ только одной команде;
• ответы только с источниками;
• закрытые документы не используются;
• вопросы без ответа уходят владельцу;
• feedback обязателен;
• каждый день просматриваются `no_answer` и плохие оценки.

Проверка: за неделю вы видите реальные вопросы и понимаете, какие документы нужно дописать.

Минимальная проверка результата

Прототип работает, если выполняются все пункты:

• документы внесены в `source_registry`;
• у каждого активного документа есть владелец;
• access_level заполнен;
• документы разбиваются на `knowledge_chunks`;
• каждый chunk содержит source_url и owner_name;
• пользовательский вопрос логируется в `question_log`;
• поиск возвращает только доступные пользователю фрагменты;
• ответ содержит ссылки на источники;
• при отсутствии источника создается строка в `unanswered_questions`;
• владельцу создается задача в `owner_tasks`;
• feedback сохраняется;
• устаревшие документы попадают на review;
• ошибки пишутся в `error_log`;
• regression tests проходят после изменения базы.

Что нельзя автоматизировать в первой версии

• ответы по закрытым документам без проверки прав;
• ответы без источников;
• автоматическое удаление документов;
• публикацию черновиков;
• объединение противоречащих регламентов без владельца;
• выдачу персональных данных;
• принятие управленческих решений за руководителя;
• изменение базы знаний без review;
• обучение на приватных документах без правил хранения и доступа.

Частые вопросы

Можно ли сделать агента только на Google Drive?

Да. Для первого прототипа достаточно Google Drive, Google Sheets, n8n, LLM API и векторного поиска. Notion или Confluence можно подключить позже, когда процесс уже проверен.

Что важнее: модель или порядок в базе знаний?

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

Нужно ли показывать пользователю источники?

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

Что делать с вопросами, на которые агент не ответил?

Записывать в `unanswered_questions`, назначать владельца и создавать задачу на новую статью или обновление документа. Так база знаний улучшается по реальным вопросам.

Какой минимум нужен для запуска?

`source_registry`, `knowledge_chunks`, `access_rules`, `question_log`, `unanswered_questions`, `owner_tasks`, `regression_tests`, один workflow индексации, один workflow ответа и 20 тестовых вопросов.