# Как AI превращает хаотичную базу знаний в структурированную wiki

> Pipeline из четырёх этапов: audit → categorize → restructure → migrate. Промпты, инструменты (Outline, Notion, Confluence) и модельный пример трансформации.
> Author: Roman Belov · Published: 2026-07-09 · Source: https://futurecraft.pro/ru/blog/knowledge-base-wiki-ai/

В командах до 50 человек знания распределены между Slack-тредами, Google Docs без владельцев, папками в Notion с датой последнего редактирования «август 2023» и markdown-файлами в репозиториях, которые никто не открывает. Половина устарела. Значительная часть дублируется. Остальное невозможно найти.

Классический подход к наведению порядка — выделить одного человека, дать ему два месяца и доступ ко всему. Результат предсказуем: через две недели энтузиазм заканчивается, через месяц проект замораживается. Объём работы несоразмерен результату, потому что 80% времени уходит на механические операции: чтение, классификацию, переформатирование.

LLM снижают стоимость этих операций на порядок. Не потому что «AI всё сделает сам», а потому что модель обрабатывает 200 страниц текста за минуты, выделяя дубликаты, устаревшие секции и пробелы в покрытии. Человек принимает решения, LLM выполняет черновую работу.

Здесь — четырёхэтапный pipeline для трансформации хаотичной базы знаний в структурированную wiki. С промптами, инструментами и конкретными метриками на каждом шаге. Тот же принцип, что в [генерации SOP из хаоса](/ru/blog/sop-generator-ai-documentation/): переиспользование существующих данных вместо создания документации с нуля.

## Этап 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:

```bash
# Конвертация 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-обработки

```python
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

```python
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. Конвертация добавляет шаг:

```python
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:

```bash
pandoc input.md -f gfm -t html -o output.html
```

Затем через REST API:

```python
import requests

CONFLUENCE_URL = "https://company.atlassian.net/wiki"
AUTH = ("email@company.com", "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] назначены на ответственных
□ Права доступа настроены по секциям
```

Скрипт для проверки ссылок:

```python
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](/ru/blog/context-engineering-guide/): качество ответов 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](https://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 документов. При меньшем объёме практичнее ручная сортировка с применением промпта реструктуризации к наиболее устаревшим документам.