Как AI превращает хаотичную базу знаний в структурированную wiki
Что такое knowledge base wiki?
Knowledge base wiki — структурированный, поисковый репозиторий командной документации (процессы, runbook-и, онбординг-гайды, архитектурные решения), организованный в навигируемую иерархию с чёткими владельцами и процессом поддержки. В отличие от разрозненных документов в Slack, Google Docs или папках Notion, правильно структурированная wiki позволяет находить информацию за минуты, а не часы, и служит надёжным источником контекста как для команды, так и для AI-агентов.
TL;DR
- -Корпоративные базы знаний типично содержат существенную долю устаревших или дублирующихся документов — в модельном примере ниже это 46% из 312 документов; LLM снижают стоимость механической работы audit/categorize/restructure в 5–6 раз — со 120 человеко-часов до 20.
- -Четырёхэтапный pipeline покрывает полную трансформацию: Audit (инвентаризация и классификация 300+ документов за 20 минут через Claude API за $3–5), Categorize (AI-генерация таксономии с gap analysis), Restructure (батч-переработка по стандарту качества), Migrate (автоматизированный импорт через API платформ).
- -Gap analysis из этапа 2 — самый ценный артефакт: LLM выявляет темы, которые должны существовать, но не задокументированы, немедленно формируя бэклог документации.
- -Маркеры [NEEDS CLARIFICATION] и [CONFLICT] обязательны — LLM должна помечать спорный контент для человека, а не принимать решение самостоятельно.
- -Без процесса поддержки после миграции (quarterly review, freshness score, docs-as-code) база знаний деградирует обратно к исходному состоянию за 6–12 месяцев.
В командах до 50 человек знания распределены между Slack-тредами, Google Docs без владельцев, папками в Notion с датой последнего редактирования «август 2023» и markdown-файлами в репозиториях, которые никто не открывает. Половина устарела. Значительная часть дублируется. Остальное невозможно найти.
Классический подход к наведению порядка — выделить одного человека, дать ему два месяца и доступ ко всему. Результат предсказуем: через две недели энтузиазм заканчивается, через месяц проект замораживается. Объём работы несоразмерен результату, потому что 80% времени уходит на механические операции: чтение, классификацию, переформатирование.
LLM снижают стоимость этих операций на порядок. Не потому что «AI всё сделает сам», а потому что модель обрабатывает 200 страниц текста за минуты, выделяя дубликаты, устаревшие секции и пробелы в покрытии. Человек принимает решения, LLM выполняет черновую работу.
Здесь — четырёхэтапный pipeline для трансформации хаотичной базы знаний в структурированную wiki. С промптами, инструментами и конкретными метриками на каждом шаге. Тот же принцип, что в генерации SOP из хаоса: переиспользование существующих данных вместо создания документации с нуля.
Этап 1: Audit — инвентаризация и оценка состояния
Порядок начинается с понимания масштаба проблемы. Audit отвечает на три вопроса: сколько документов существует, какого они качества и где критические пробелы.
Извлечение контента
Первый шаг — собрать всё в единый формат. Источники типичной команды:
Notion → Export → Markdown (встроенный экспорт)
Google Docs → Export → Markdown (через Google Takeout или Docs API)
Confluence → Export → HTML/XML (Space Export → конвертация pandoc)
Slack/Teams → Export → JSON (Admin Export → фильтрация каналов)
GitHub/GitLab → Clone → Markdown (wiki + docs/ + README)
Loom/видео → API → Транскрипты (Loom API или Whisper)
Для Confluence конвертация через pandoc:
# Конвертация HTML-экспорта Confluence в markdown
find ./confluence-export -name "*.html" -exec sh -c '
pandoc "$1" -f html -t gfm -o "${1%.html}.md"
' _ {} \;
Для Notion экспорт проще — он выгружает markdown нативно. Но экспорт теряет связи между страницами и database views. Это нормально для целей аудита.
Промпт для аудита документов
После сбора контента в markdown-файлы LLM анализирует каждый документ:
ROLE: Technical documentation auditor.
TASK: Analyze the document below and produce a structured assessment.
ASSESSMENT CRITERIA:
1. FRESHNESS: Last meaningful update date (from content clues, not metadata).
Rate: current (< 6 months) | stale (6-12 months) | outdated (> 12 months)
2. COMPLETENESS: Does the document cover its topic fully?
Rate: complete | partial | stub
3. ACCURACY: Are there references to deprecated tools, old URLs,
removed features, or contradictory statements?
Rate: accurate | has_issues | unreliable
4. DUPLICATES: Does this document overlap with others in the batch?
List overlapping document IDs if yes.
5. AUDIENCE: Who is the intended reader?
Options: engineering | product | operations | all | unclear
OUTPUT FORMAT (JSON):
{
"doc_id": "<filename>",
"title": "<extracted title>",
"topic": "<one-line summary>",
"freshness": "current|stale|outdated",
"completeness": "complete|partial|stub",
"accuracy": "accurate|has_issues|unreliable",
"duplicates": ["<doc_id>", ...],
"audience": "engineering|product|operations|all|unclear",
"issues": ["<specific issue 1>", ...],
"recommendation": "keep|update|merge|archive|delete"
}
DOCUMENT:
{document_content}
Промпт работает в batch-режиме. При базе из 300 документов обработка через Claude API (модель Sonnet) занимает 15–20 минут и стоит $3–5. Ключевой момент: рекомендация recommendation не является финальным решением. Это входные данные для человека, который подтверждает или корректирует.
Скрипт для batch-обработки
import anthropic
import json
from pathlib import Path
client = anthropic.Anthropic()
AUDIT_PROMPT = Path("prompts/audit.txt").read_text()
def audit_document(file_path: Path) -> dict:
content = file_path.read_text(encoding="utf-8")
# Ограничение: документы > 50K символов разбиваются на части
if len(content) > 50_000:
content = content[:50_000] + "\n\n[TRUNCATED — full document is longer]"
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=1024,
messages=[{
"role": "user",
"content": AUDIT_PROMPT.replace("{document_content}", content)
}]
)
return json.loads(response.content[0].text)
# Обработка всех файлов
docs_dir = Path("./exported-docs")
results = []
for md_file in sorted(docs_dir.glob("**/*.md")):
result = audit_document(md_file)
results.append(result)
print(f" {result['doc_id']}: {result['recommendation']}")
# Сохранение результатов
Path("audit-results.json").write_text(
json.dumps(results, indent=2, ensure_ascii=False)
)
Метрики аудита
На выходе — dashboard состояния базы знаний:
Всего документов: 312
├── keep: 89 (29%)
├── update: 104 (33%)
├── merge: 47 (15%)
├── archive: 58 (19%)
└── delete: 14 (4%)
Дубликатов найдено: 63 пары
Без владельца: 187 (60%)
Устаревших (> 12 мес): 142 (46%)
Типичная картина: треть документов можно сохранить, треть требует обновления, остальное — балласт. Когда масштаб проблемы виден в цифрах, довести проект до конца проще.
Этап 2: Categorize — таксономия и иерархия
Аудит показал что есть. Категоризация определяет куда это разместить. Плоский список из 300 документов бесполезен. Нужна иерархия, которая отражает реальную навигацию: как люди ищут информацию.
Два подхода к таксономии
Top-down: сначала определить структуру, потом распределить документы. Работает, если структура очевидна (engineering wiki с разделами по сервисам).
Bottom-up: LLM анализирует все документы и предлагает кластеры. Работает для хаотичных баз, где «правильная» структура неочевидна.
На практике эффективен гибридный подход: LLM генерирует кластеры (bottom-up), человек корректирует под реальные потребности (top-down).
Промпт для генерации таксономии
ROLE: Information architect specializing in knowledge management.
TASK: Analyze the document inventory below and propose a hierarchical
taxonomy for a team wiki.
CONSTRAINTS:
- Maximum 3 levels of nesting (section → subsection → page)
- Maximum 8 top-level sections
- Every document must belong to exactly one section
- Section names should be action-oriented or domain-oriented,
not generic ("How-to Guides" instead of "Documents")
- Consider the audience field from audit data
DOCUMENT INVENTORY:
{audit_results_json}
OUTPUT FORMAT:
For each proposed section:
1. Section name and one-line description
2. Subsections (if needed)
3. List of doc_ids assigned to this section
4. Gap analysis: topics that SHOULD exist but don't
Also provide:
- CROSS-REFERENCES: Documents that should link to each other
- LANDING PAGES: Sections that need an overview/index page (not present
in current docs)
Результат категоризации
LLM генерирует структуру, в которой видны связи и пробелы:
PROPOSED TAXONOMY:
1. Getting Started
├── Onboarding checklist
├── Development environment setup
├── Access & permissions
└── [GAP] Architecture overview for new engineers
2. Engineering Practices
├── Code Review
│ ├── review-guidelines.md
│ ├── pr-template.md
│ └── [MERGE] code-standards.md + style-guide.md
├── Testing
│ ├── testing-strategy.md
│ └── [GAP] E2E testing guide
└── CI/CD
├── pipeline-overview.md
└── deploy-process.md
3. Operations & Runbooks
├── Incident Response
│ ├── on-call-rotation.md
│ └── incident-playbook.md
├── Monitoring
│ └── alerts-reference.md
└── [GAP] Post-mortem template
...
Gap analysis — самый ценный артефакт этого этапа. LLM находит отсутствующие документы, которые «все собирались написать». Список пробелов сразу становится бэклогом для следующей итерации.
Кросс-ссылки
Отдельная ценность LLM — обнаружение связей между документами. Документ о процессе деплоя должен ссылаться на runbook отката. Гайд по мониторингу должен ссылаться на описание алертов. В хаотичной базе эти связи отсутствуют, потому что документы создавались в разное время разными людьми.
Промпт для генерации кросс-ссылок:
TASK: For each document in the taxonomy, identify 2-5 documents
that SHOULD be linked from it. Explain why each link is needed.
CRITERIA for a valid cross-reference:
- Document A explains a concept that Document B assumes as known
- Document A describes a process that includes steps from Document B
- Document A and B cover the same system from different angles
(architecture vs operations vs troubleshooting)
OUTPUT: List of {source_doc, target_doc, link_type, reason}
link_type: prerequisite | related | see_also | continuation
Этап 3: Restructure — переработка контента
Документы отсортированы, структура определена. Теперь каждый документ, помеченный как update или merge, проходит через LLM-обработку.
Стандарт качества документа
Перед реструктуризацией нужен эталон. Что делает документ хорошим:
DOCUMENT QUALITY STANDARD:
1. TITLE: Descriptive, searchable. Not "Notes" or "Untitled".
2. METADATA: Owner, last reviewed date, audience, status.
3. STRUCTURE:
- TL;DR or summary at the top (2-3 sentences)
- Logical heading hierarchy (H2 → H3, never skip levels)
- Steps numbered, not bulleted
- Code blocks with language tags
4. CONTENT:
- No assumptions about reader's context
- Links to prerequisites
- Concrete examples, not abstract descriptions
- Version-specific information marked explicitly
5. MAINTENANCE:
- Review date set (quarterly for processes, monthly for configs)
- Owner assigned
- Change log at the bottom
Промпт для реструктуризации
ROLE: Technical editor. You restructure documentation to match
a quality standard.
TASK: Rewrite the document below according to the QUALITY STANDARD.
RULES:
- Preserve ALL factual content. Do not invent information.
- If something is ambiguous, mark it with [NEEDS CLARIFICATION: ...].
- If a section references external knowledge, add
[LINK NEEDED: <topic>].
- Convert implicit knowledge into explicit steps.
- Remove duplicate paragraphs and redundant phrasing.
- Add metadata header.
QUALITY STANDARD:
{quality_standard}
ORIGINAL DOCUMENT:
{document_content}
CONTEXT: This document belongs to section "{section_name}"
in the wiki. Target audience: {audience}.
OUTPUT: Restructured document in markdown. After the document,
provide a CHANGE LOG listing every significant change made
and why.
Слияние дубликатов
Документы, помеченные как merge, требуют отдельного промпта:
TASK: Merge these documents into one definitive document.
RULES:
- Take the most recent and complete information from each source.
- Where sources contradict each other, keep BOTH versions with
a [CONFLICT: Source A says X, Source B says Y — needs resolution] marker.
- Do not silently drop information from any source.
- Structure the merged document according to the quality standard.
DOCUMENTS TO MERGE:
--- Document A ({doc_a_id}, last updated: {date_a}) ---
{doc_a_content}
--- Document B ({doc_b_id}, last updated: {date_b}) ---
{doc_b_content}
Маркеры [NEEDS CLARIFICATION] и [CONFLICT] — обязательный элемент pipeline. LLM не должна принимать решения о спорном контенте. Эти маркеры превращаются в задачи для конкретных людей после миграции.
Генерация отсутствующих документов
Gap analysis из этапа 2 выявил темы, которые должны быть задокументированы, но не были. LLM генерирует skeleton-документы:
TASK: Generate a skeleton document for the topic below.
TOPIC: {gap_topic}
SECTION: {parent_section}
AUDIENCE: {audience}
RULES:
- Create the document structure with headings and 1-2 sentence
descriptions of what each section should contain.
- Mark every section body as [TO BE WRITTEN BY: <suggested owner>].
- Include a "Questions to Answer" section listing what information
needs to be gathered.
- Do NOT generate fake content. Structure only.
Skeleton-документы — низко висящий фрукт. Создать структуру из 10 заголовков с описанием каждой секции за минуту вместо того, чтобы смотреть на пустую страницу. Снижение барьера входа для авторов.
Этап 4: Migrate — перенос в целевую платформу
Контент реструктурирован. Теперь его нужно разместить в wiki-системе с правильной навигацией, правами и поиском.
Выбор платформы
Три варианта, каждый со своей спецификой:
| Критерий | Outline | Notion | Confluence |
|---|---|---|---|
| Self-hosted | Да (Docker) | Нет | Да (Data Center) |
| API для импорта | REST + markdown native | REST, блочная модель | REST, XHTML storage |
| Поиск | Full-text, быстрый | Full-text + AI | Full-text + CQL |
| Цена (50 человек) | $0 (self-hosted) | $500/мес (Plus, годовая) | $520/мес (Cloud) |
| Markdown-native | Да | Нет (конвертация) | Нет (конвертация) |
| Open-source | Да (BSL) | Нет | Нет |
Для команд, которые уже работают в markdown и ценят контроль, Outline — оптимальный выбор. API принимает markdown без конвертации, поиск быстрый, self-hosted версия функционально полная.
Автоматизация импорта в Outline
import requests
from pathlib import Path
OUTLINE_URL = "https://wiki.company.com"
API_TOKEN = "ol_api_..."
def get_or_create_collection(name: str) -> str:
"""Получить или создать коллекцию (top-level section)."""
resp = requests.post(f"{OUTLINE_URL}/api/collections.list",
headers={"Authorization": f"Bearer {API_TOKEN}"},
json={}
)
for col in resp.json()["data"]:
if col["name"] == name:
return col["id"]
resp = requests.post(f"{OUTLINE_URL}/api/collections.create",
headers={"Authorization": f"Bearer {API_TOKEN}"},
json={"name": name, "permission": "read_write"}
)
return resp.json()["data"]["id"]
def create_document(title: str, markdown: str,
collection_id: str, parent_id: str = None) -> str:
"""Создать документ в коллекции."""
payload = {
"title": title,
"text": markdown,
"collectionId": collection_id,
"publish": True
}
if parent_id:
payload["parentDocumentId"] = parent_id
resp = requests.post(f"{OUTLINE_URL}/api/documents.create",
headers={"Authorization": f"Bearer {API_TOKEN}"},
json=payload
)
return resp.json()["data"]["id"]
def migrate_taxonomy(taxonomy: dict, docs_dir: Path):
"""Мигрировать всю таксономию в Outline."""
for section in taxonomy["sections"]:
collection_id = get_or_create_collection(section["name"])
for subsection in section.get("subsections", []):
# Создать родительский документ для подсекции
parent_id = create_document(
title=subsection["name"],
markdown=f"# {subsection['name']}\n\n{subsection.get('description', '')}",
collection_id=collection_id
)
for doc_id in subsection["doc_ids"]:
file_path = docs_dir / f"{doc_id}.md"
if file_path.exists():
content = file_path.read_text()
title = content.split("\n")[0].lstrip("# ")
create_document(title, content, collection_id, parent_id)
print(f" Migrated: {doc_id} → {section['name']}/{subsection['name']}")
Импорт в Notion
Notion использует блочную модель вместо markdown. Конвертация добавляет шаг:
from notion_client import Client
notion = Client(auth="secret_...")
def markdown_to_notion_blocks(markdown: str) -> list:
"""Конвертировать markdown в Notion blocks."""
blocks = []
for line in markdown.split("\n"):
if line.startswith("## "):
blocks.append({
"type": "heading_2",
"heading_2": {"rich_text": [{"text": {"content": line[3:]}}]}
})
elif line.startswith("### "):
blocks.append({
"type": "heading_3",
"heading_3": {"rich_text": [{"text": {"content": line[4:]}}]}
})
elif line.startswith("- "):
blocks.append({
"type": "bulleted_list_item",
"bulleted_list_item": {"rich_text": [{"text": {"content": line[2:]}}]}
})
elif line.strip():
blocks.append({
"type": "paragraph",
"paragraph": {"rich_text": [{"text": {"content": line}}]}
})
return blocks
def create_notion_page(title: str, markdown: str, parent_page_id: str):
"""Создать страницу в Notion."""
blocks = markdown_to_notion_blocks(markdown)
# Notion API ограничивает 100 блоков за запрос
notion.pages.create(
parent={"page_id": parent_page_id},
properties={"title": [{"text": {"content": title}}]},
children=blocks[:100]
)
Ограничение Notion API: максимум 100 блоков за один запрос. Для длинных документов требуется пагинация через blocks.children.append.
Импорт в Confluence
Confluence ожидает XHTML (Atlassian Storage Format). Конвертация markdown → XHTML через pandoc:
pandoc input.md -f gfm -t html -o output.html
Затем через REST API:
import requests
CONFLUENCE_URL = "https://company.atlassian.net/wiki"
AUTH = ("[email protected]", "api-token")
def create_confluence_page(title: str, html_body: str,
space_key: str, parent_id: int = None):
payload = {
"type": "page",
"title": title,
"space": {"key": space_key},
"body": {
"storage": {
"value": html_body,
"representation": "storage"
}
}
}
if parent_id:
payload["ancestors"] = [{"id": parent_id}]
requests.post(f"{CONFLUENCE_URL}/rest/api/content",
auth=AUTH, json=payload)
Валидация после миграции
Миграция без валидации — источник проблем. Чеклист:
POST-MIGRATION VALIDATION:
□ Количество документов в wiki = количеству запланированных
□ Все кросс-ссылки ведут на существующие страницы
□ Изображения отображаются (частая проблема при миграции)
□ Code blocks сохранили форматирование и подсветку
□ Иерархия навигации соответствует таксономии
□ Поиск находит документы по ключевым терминам
□ Маркеры [NEEDS CLARIFICATION] собраны в отдельный список задач
□ Маркеры [CONFLICT] назначены на ответственных
□ Права доступа настроены по секциям
Скрипт для проверки ссылок:
import re
from pathlib import Path
def validate_internal_links(docs_dir: Path) -> list[str]:
"""Найти сломанные внутренние ссылки."""
broken = []
all_slugs = {f.stem for f in docs_dir.glob("**/*.md")}
for md_file in docs_dir.glob("**/*.md"):
content = md_file.read_text()
links = re.findall(r'\[.*?\]\((?!http)(.*?)\)', content)
for link in links:
slug = link.strip("/").split("/")[-1]
if slug not in all_slugs:
broken.append(f"{md_file.name} → {link}")
return broken
Поддержка актуальности: процесс после миграции
Миграция — не финальная точка. База знаний деградирует без процесса поддержки. Три механизма, которые работают:
Quarterly review. Каждый документ имеет дату следующего ревью в metadata. Автоматический reminder владельцу за неделю до даты. LLM помогает ревью: сравнивает документ с текущим состоянием кода, конфигов, API.
Freshness score. Автоматический расчёт на основе: дата последнего редактирования, частота просмотров, количество ссылок на документ из других страниц. Документы с низким score попадают в очередь на ревью.
Doc-as-code. Документация в том же репозитории, что и код. Изменения в коде, затрагивающие задокументированные процессы, автоматически создают задачу на обновление документации. CI проверяет, что PR с изменением API включает обновление соответствующей документации.
Промпт для автоматического ревью:
TASK: Compare this document against the current state
of the codebase/system and identify outdated sections.
DOCUMENT (from wiki):
{document_content}
CURRENT STATE (from code/config):
{relevant_code_or_config}
OUTPUT:
1. Sections that are still accurate (no changes needed)
2. Sections that need updating (with specific diffs)
3. Sections that reference removed/deprecated features
4. New features/changes not yet documented
Метрики трансформации: модельный пример
Ниже — не отчёт по конкретному проекту, а модельный пример на типичной базе из 300+ документов: как может выглядеть результат pipeline при заданных на входе 312 документах и распределении из этапа Audit.
BEFORE:
- 312 документов, 46% устарели
- Среднее время поиска информации: 12 минут
- 60% документов без владельца
- 0 кросс-ссылок
AFTER:
- 218 документов (89 сохранены, 104 обновлены, 20 получены слиянием из 47, 5 созданы)
- 72 архивированы/удалены
- Среднее время поиска: 2 минуты
- 100% документов с владельцем
- 340+ кросс-ссылок
COST:
- LLM API (audit + restructure + merge): ~$15-25
- Человеческое время: ~20 часов (вместо ~120 при ручной работе)
- Calendar time: 2 недели (вместо 2-3 месяцев)
Экономия времени в этом примере — 5-6x. Но главная ценность не в экономии, а в том, что проект доводится до конца. Ручная миграция из 300 документов — это задача, которую бросают на середине. Pipeline с LLM-автоматизацией — задача, которую завершают за две недели.
Интеграция с контекстом AI-агентов
Структурированная wiki — не только для людей. Она становится источником контекста для AI-агентов. Тот же подход, что описан в руководстве по context engineering: качество ответов LLM определяется качеством контекста, а не промптами.
Конкретные сценарии:
RAG поверх wiki. Outline и Notion предоставляют API для full-text search. AI-ассистент в Slack ищет по wiki и отвечает на вопросы команды, ссылаясь на конкретные документы.
MCP-сервер для wiki. Outline имеет MCP-сервер (search, get, create, update documents). Claude Code или другой AI-агент получает доступ к wiki как к инструменту. Инженер спрашивает «как деплоить сервис X», агент находит runbook и выдаёт актуальные шаги.
Автоматическое обновление. CI/CD pipeline при деплое проверяет, затронуты ли задокументированные процессы. Если да — LLM генерирует diff для документации и создаёт PR или задачу.
Чеклист: от хаоса к структуре за 2 недели
Неделя 1: Audit + Categorize
□ День 1-2: Экспорт всех источников в markdown
□ День 3: Batch-аудит через LLM (автоматизация)
□ День 4: Ревью результатов аудита (ручная корректировка)
□ День 5: Генерация таксономии + gap analysis
□ День 5: Утверждение структуры с командой
Неделя 2: Restructure + Migrate
□ День 6-7: Batch-реструктуризация (LLM) + ревью маркеров
□ День 8: Слияние дубликатов + генерация skeleton-документов
□ День 9: Миграция в целевую платформу
□ День 10: Валидация + настройка процесса поддержки
Pipeline работает для баз от 50 до 1000 документов. Для меньших объёмов LLM-автоматизация избыточна. Для больших — добавляется этап кластеризации через embeddings перед категоризацией, чтобы LLM не обрабатывала весь корпус за один проход.
Ключевой принцип: LLM выполняет механическую работу (чтение, классификация, переформатирование), человек принимает решения (что оставить, какую структуру выбрать, кто владеет документом). Распределение, при котором обе стороны делают то, в чём сильны.
Нужна помощь с организацией базы знаний? Я помогаю стартапам внедрять AI-решения и строить продукты — belov.works.
FAQ
Что делать с документами, содержащими конфиденциальную бизнес-информацию — можно ли их отправлять в LLM для аудита? Это наиболее частый барьер для команд, рассматривающих LLM-аудит. Два варианта: запустить аудит локально через self-hosted модель (Llama 3, Mistral) через Ollama или приватный API — это полностью исключает передачу данных. Второй вариант — обезличить чувствительные поля (имена клиентов, финансовые цифры, кодовые названия проектов) перед отправкой в облачный API. Структурный и лингвистический анализ, который выполняет LLM, не требует конкретных значений — только паттерны содержания документа.
Как обрабатывать документацию, существующую только в видеоформате — записи Loom, записи встреч, внутренние презентации?
Сначала транскрибировать, затем обрабатывать транскрипт как документ. Whisper (OpenAI, open-source) хорошо справляется с задачей при стоимости $0.006/минута. 30-минутный Loom даёт транскрипт ~5000 слов, который напрямую подаётся в промпт аудита. Основная сложность — сегментация: запись 3-часовой онбординг-сессии нужно разбить на тематические фрагменты перед аудитом, иначе LLM затрудняется с классификацией recommendation и audience.
С какого минимального размера команды pipeline окупается экономически? Порог в 50 документов из статьи — про сложность pipeline, а не про размер команды. Команда из 5 человек с 60 документами, накопленными за 2 года, выиграет уже от одного этапа аудита — AI-классификация занимает 20 минут и стоит $1, против 4–6 часов ручной сортировки. Полный четырёхэтапный pipeline (включая скриптинг миграции) окупается примерно от 100 документов. При меньшем объёме практичнее ручная сортировка с применением промпта реструктуризации к наиболее устаревшим документам.