iiuniversitet.ruЦентр обучения нейросетямОткрыть каталог

Сведение найденного в один ответ

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

СкиллAnthropicClaudeApache-2.0Загрузить архив в ClaudeПроверка не требуетсяСлужебный: его вызывают другие скиллы
Что делает
Объединяет результаты поиска из разных источников в один ответ без дублей, со ссылками и оценкой надёжности.
Когда брать
Когда информация лежит в чате, почте и документах и нужно получить из неё единый связный ответ.
Когда не брать
Когда нужно просто найти конкретный документ или письмо: для этого есть поиск.
Пример запроса
Что мы решили по API? Свяжи обсуждение в чате, письма и документ в один ответ и укажи источники.
Нужно подключить
почта, чат, облачные документы

Входит в плагин enterprise-search. В Cowork и Claude Code можно поставить плагин целиком.

Как включить

  1. Нажмите «Скачать на русском» и сохраните архив.
  2. В Claude откройте Настройки → Capabilities → Skills → Upload skill и выберите архив.
  3. Включите скилл переключателем.
Для терминала

Распакуйте архив и положите папку knowledge-synthesis в ~/.claude/skills/. Файл SKILL.md должен лежать внутри этой папки.

Текст

---
name: knowledge-synthesis
description: Объединяет результаты поиска из нескольких источников в связные ответы без дублей и со ссылками на источники. Оценивает уверенность по свежести и авторитетности и эффективно сжимает большие наборы результатов.
user-invocable: false
---

Синтез знаний

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

Цель

Превратить вот это:

результат ~~chat: «Sarah в #eng: "берём REST, GraphQL для нашей задачи избыточен"»
результат ~~email: «Тема: API Decision — письмо Sarah с подтверждением подхода REST и обоснованием»
результат ~~cloud storage: «API Design Doc v3 — раздел 2 обновлён под решение о REST»
результат ~~project tracker: «Задача: Finalize API approach — отмечена выполненной Sarah»

Вот в это:

Команда решила использовать REST вместо GraphQL при переработке API. Решение
принимала Sarah, отметив, что GraphQL избыточен для текущей задачи. Это обсуждали
в #engineering во вторник, подтвердили письмом в среду, а проектный документ
обновили в соответствии с решением. Связанная задача в ~~project tracker отмечена выполненной.

Источники:
- ~~chat: ветка в #engineering (14 янв.)
- ~~email: «API Decision» от Sarah (15 янв.)
- ~~cloud storage: «API Design Doc v3» (обновлён 15 янв.)
- ~~project tracker: «Finalize API approach» (завершена 15 янв.)

Устранение дублей

Дубли между источниками

Одна и та же информация часто встречается в нескольких местах. Находи дубли и объединяй их:

Признаки того, что результаты об одном и том же:

  • Тот же или очень похожий текст
  • Тот же автор или отправитель
  • Метки времени рядом (в тот же день или в соседние)
  • Ссылки на один объект (название проекта, документ, решение)
  • Один источник ссылается на другой («как обсуждали в ~~chat», «согласно письму», «см. документ»)

Как объединять:

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

Приоритет при устранении дублей

Если одна и та же информация есть в нескольких источниках, предпочитай:

1. Самую полную версию (с наибольшим контекстом)
2. Самый авторитетный источник (официальный документ > чат)
3. Самую свежую версию (для меняющейся информации побеждает последнее обновление)

Что НЕ объединять

Оставляй отдельными пунктами, когда:

  • Одна тема обсуждается, но с разными выводами
  • Разные люди высказывают разные точки зрения
  • Информация существенно изменилась между источниками (v1 и v2 решения)
  • Представлены разные периоды времени

Цитирование и указание источников

Каждое утверждение в итоговом ответе должно опираться на источник.

Формат ссылок на источники

В тексте — для прямых ссылок:

Sarah подтвердила подход REST в письме в среду.
Проектный документ обновили в соответствии с этим (~~cloud storage: "API Design Doc v3").

Список источников в конце — для полноты:

Источники:
- ~~chat: обсуждение в #engineering (14 янв.) — первоначальная ветка с решением
- ~~email: «API Decision» от Sarah Chen (15 янв.) — официальное подтверждение
- ~~cloud storage: «API Design Doc v3», последнее изменение 15 янв. — обновлённая спецификация

Правила указания источников

  • Всегда называй тип источника (~~chat, ~~email, ~~cloud storage и т. д.)
  • Указывай конкретное место (канал, папка, цепочка)
  • Указывай дату или относительное время
  • Указывай автора, когда это важно
  • Указывай названия документов и цепочек, если они есть
  • Для ~~chat указывай название канала
  • Для ~~email указывай тему письма и отправителя
  • Для ~~cloud storage указывай название документа

Уровни уверенности

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

Свежесть

ДавностьВлияние на уверенность
Сегодня / вчераВысокая уверенность в текущем состоянии
На этой неделеХорошая уверенность
В этом месяцеУмеренная — всё могло измениться
Старше месяцаПониженная — помечай как возможно устаревшее

Для вопросов о статусе свежесть весит очень много. Для вопросов о правилах и фактах свежесть важна меньше.

Авторитетность

Тип источникаУровень авторитетности
Официальная вики / база знанийВысший — подобрано и поддерживается
Общие документы (итоговые версии)Высокий — опубликованы намеренно
Объявления по почтеВысокий — официальная коммуникация
Заметки со встречСредне-высокий — могут быть неполными
Сообщения в чате (выводы по ветке)Средний — неформально, но в реальном времени
Сообщения в чате (середина обсуждения)Пониженный — могут не отражать итоговую позицию
Черновики документовНизкий — не доработаны
Комментарии к задачамПо контексту — зависит от автора комментария

Как выражать уверенность

Когда уверенность высокая (несколько свежих авторитетных источников согласуются):

Команда решила использовать REST при переработке API. [прямое утверждение]

Когда уверенность средняя (один источник или информация несколько устарела):

Судя по обсуждению в #engineering в прошлом месяце, команда склонялась
к REST для переработки API. С тех пор ситуация могла измениться.

Когда уверенность низкая (старые данные, неформальный источник или противоречивые сигналы):

Я нашёл упоминание обсуждения миграции API трёхмесячной давности
в ~~chat, но официального документа с решением не нашёл. Информация
может быть устаревшей. Возможно, стоит уточнить текущий статус у команды.

Противоречивая информация

Когда источники расходятся:

Я нашёл противоречивую информацию о подходе к API:
- Обсуждение в ~~chat 10 янв. предлагало GraphQL
- Но письмо Sarah от 15 янв. подтвердило REST
- Проектный документ (обновлён 15 янв.) отражает REST

Самые свежие источники указывают, что окончательным решением стал REST,
но более раннее обсуждение в ~~chat сначала рассматривало GraphQL.

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

Стратегии сжатия

Для небольших наборов результатов (1–5 результатов)

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

[Прямой ответ, собранный из результатов]

[Деталь из источника 1]
[Деталь из источника 2]

Источники: [полные ссылки на источники]

Для средних наборов результатов (5–15 результатов)

Сгруппируй по темам и кратко опиши каждую группу:

[Общий ответ]

Тема 1: [сводка по связанным результатам]
Тема 2: [сводка по связанным результатам]

Ключевые источники: [3–5 самых релевантных источников]
Все результаты: найдено [число] пунктов в [источники]

Для больших наборов результатов (15 и больше)

Дай обобщённый синтез с возможностью углубиться:

[Общий ответ на основе самых релевантных результатов]

Сводка:
- [Главный вывод 1] (подтверждён N источниками)
- [Главный вывод 2] (подтверждён N источниками)
- [Главный вывод 3] (подтверждён N источниками)

Главные источники:
- [Самый авторитетный или релевантный источник]
- [Второй по релевантности]
- [Третий по релевантности]

Найдено [общее число] результатов в [список источников].
Хочешь, я копну глубже в какой-то конкретный аспект?

Правила сжатия

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

Рабочий процесс синтеза

[Сырые результаты из всех источников]
          ↓
[1. Убрать дубли — объединить одинаковую информацию из разных источников]
          ↓
[2. Сгруппировать — собрать связанные результаты по теме]
          ↓
[3. Ранжировать — упорядочить группы и пункты по релевантности запросу]
          ↓
[4. Оценить уверенность — свежесть × авторитетность × согласованность]
          ↓
[5. Синтезировать — составить связный ответ со ссылками на источники]
          ↓
[6. Оформить — выбрать уровень детализации по числу результатов]
          ↓
[Связный ответ с источниками]

Антипаттерны

Не делай так:

  • Не перечисляй результаты по источникам («Из ~~chat: ... Из ~~email: ... Из ~~cloud storage: ...»)
  • Не включай нерелевантные результаты только потому, что совпало ключевое слово
  • Не прячь ответ за объяснением методики
  • Не показывай противоречивую информацию, не отметив противоречие
  • Не опускай ссылки на источники
  • Не подавай неточную информацию с той же уверенностью, что и подтверждённые факты
  • Не сжимай настолько агрессивно, что теряются полезные детали

Делай так:

  • Начинай с ответа
  • Группируй по темам, а не по источникам
  • Отмечай уровни уверенности, когда это уместно
  • Показывай противоречия явно
  • Подкрепляй каждое утверждение источником
  • Предлагай копнуть глубже, когда результатов много

Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/knowledge-work-plugins/tree/main/enterprise-search/skills/knowledge-synthesis, лицензия Apache-2.0. Изменения: перевод на русский язык.

Оригинал на английском
---
name: knowledge-synthesis
description: Combines search results from multiple sources into coherent, deduplicated answers with source attribution. Handles confidence scoring based on freshness and authority, and summarizes large result sets effectively.
user-invocable: false
---

# Knowledge Synthesis

The last mile of enterprise search. Takes raw results from multiple sources and produces a coherent, trustworthy answer.

## The Goal

Transform this:
```
~~chat result: "Sarah said in #eng: 'let's go with REST, GraphQL is overkill for our use case'"
~~email result: "Subject: API Decision — Sarah's email confirming REST approach with rationale"
~~cloud storage result: "API Design Doc v3 — updated section 2 to reflect REST decision"
~~project tracker result: "Task: Finalize API approach — marked complete by Sarah"
```

Into this:
```
The team decided to go with REST over GraphQL for the API redesign. Sarah made the
call, noting that GraphQL was overkill for the current use case. This was discussed
in #engineering on Tuesday, confirmed via email Wednesday, and the design doc has
been updated to reflect the decision. The related ~~project tracker task is marked complete.

Sources:
- ~~chat: #engineering thread (Jan 14)
- ~~email: "API Decision" from Sarah (Jan 15)
- ~~cloud storage: "API Design Doc v3" (updated Jan 15)
- ~~project tracker: "Finalize API approach" (completed Jan 15)
```

## Deduplication

### Cross-Source Deduplication

The same information often appears in multiple places. Identify and merge duplicates:

**Signals that results are about the same thing:**
- Same or very similar text content
- Same author/sender
- Timestamps within a short window (same day or adjacent days)
- References to the same entity (project name, document, decision)
- One source references another ("as discussed in ~~chat", "per the email", "see the doc")

**How to merge:**
- Combine into a single narrative item
- Cite all sources where it appeared
- Use the most complete version as the primary text
- Add unique details from each source

### Deduplication Priority

When the same information exists in multiple sources, prefer:
```
1. The most complete version (fullest context)
2. The most authoritative source (official doc > chat)
3. The most recent version (latest update wins for evolving info)
```

### What NOT to Deduplicate

Keep as separate items when:
- The same topic is discussed but with different conclusions
- Different people express different viewpoints
- The information evolved meaningfully between sources (v1 vs v2 of a decision)
- Different time periods are represented

## Citation and Source Attribution

Every claim in the synthesized answer must be attributable to a source.

### Attribution Format

Inline for direct references:
```
Sarah confirmed the REST approach in her email on Wednesday.
The design doc was updated to reflect this (~~cloud storage: "API Design Doc v3").
```

Source list at the end for completeness:
```
Sources:
- ~~chat: #engineering discussion (Jan 14) — initial decision thread
- ~~email: "API Decision" from Sarah Chen (Jan 15) — formal confirmation
- ~~cloud storage: "API Design Doc v3" last modified Jan 15 — updated specification
```

### Attribution Rules

- Always name the source type (~~chat, ~~email, ~~cloud storage, etc.)
- Include the specific location (channel, folder, thread)
- Include the date or relative time
- Include the author when relevant
- Include document/thread titles when available
- For ~~chat, note the channel name
- For ~~email, note the subject line and sender
- For ~~cloud storage, note the document title

## Confidence Levels

Not all results are equally trustworthy. Assess confidence based on:

### Freshness

| Recency | Confidence impact |
|---------|------------------|
| Today / yesterday | High confidence for current state |
| This week | Good confidence |
| This month | Moderate — things may have changed |
| Older than a month | Lower confidence — flag as potentially outdated |

For status queries, heavily weight freshness. For policy/factual queries, freshness matters less.

### Authority

| Source type | Authority level |
|-------------|----------------|
| Official wiki / knowledge base | Highest — curated, maintained |
| Shared documents (final versions) | High — intentionally published |
| Email announcements | High — formal communication |
| Meeting notes | Moderate-high — may be incomplete |
| Chat messages (thread conclusions) | Moderate — informal but real-time |
| Chat messages (mid-thread) | Lower — may not reflect final position |
| Draft documents | Low — not finalized |
| Task comments | Contextual — depends on commenter |

### Expressing Confidence

When confidence is high (multiple fresh, authoritative sources agree):
```
The team decided to use REST for the API redesign. [direct statement]
```

When confidence is moderate (single source or somewhat dated):
```
Based on the discussion in #engineering last month, the team was leaning
toward REST for the API redesign. This may have evolved since then.
```

When confidence is low (old data, informal source, or conflicting signals):
```
I found a reference to an API migration discussion from three months ago
in ~~chat, but I couldn't find a formal decision document. The information
may be outdated. You might want to check with the team for current status.
```

### Conflicting Information

When sources disagree:
```
I found conflicting information about the API approach:
- The ~~chat discussion on Jan 10 suggested GraphQL
- But Sarah's email on Jan 15 confirmed REST
- The design doc (updated Jan 15) reflects REST

The most recent sources indicate REST was the final decision,
but the earlier ~~chat discussion explored GraphQL first.
```

Always surface conflicts rather than silently picking one version.

## Summarization Strategies

### For Small Result Sets (1-5 results)

Present each result with context. No summarization needed — give the user everything:
```
[Direct answer synthesized from results]

[Detail from source 1]
[Detail from source 2]

Sources: [full attribution]
```

### For Medium Result Sets (5-15 results)

Group by theme and summarize each group:
```
[Overall answer]

Theme 1: [summary of related results]
Theme 2: [summary of related results]

Key sources: [top 3-5 most relevant sources]
Full results: [count] items found across [sources]
```

### For Large Result Sets (15+ results)

Provide a high-level synthesis with the option to drill down:
```
[Overall answer based on most relevant results]

Summary:
- [Key finding 1] (supported by N sources)
- [Key finding 2] (supported by N sources)
- [Key finding 3] (supported by N sources)

Top sources:
- [Most authoritative/relevant source]
- [Second most relevant]
- [Third most relevant]

Found [total count] results across [source list].
Want me to dig deeper into any specific aspect?
```

### Summarization Rules

- Lead with the answer, not the search process
- Do not list raw results — synthesize them into narrative
- Group related items from different sources together
- Preserve important nuance and caveats
- Include enough detail that the user can decide whether to dig deeper
- Always offer to provide more detail if the result set was large

## Synthesis Workflow

```
[Raw results from all sources]
          ↓
[1. Deduplicate — merge same info from different sources]
          ↓
[2. Cluster — group related results by theme/topic]
          ↓
[3. Rank — order clusters and items by relevance to query]
          ↓
[4. Assess confidence — freshness × authority × agreement]
          ↓
[5. Synthesize — produce narrative answer with attribution]
          ↓
[6. Format — choose appropriate detail level for result count]
          ↓
[Coherent answer with sources]
```

## Anti-Patterns

**Do not:**
- List results source by source ("From ~~chat: ... From ~~email: ... From ~~cloud storage: ...")
- Include irrelevant results just because they matched a keyword
- Bury the answer under methodology explanation
- Present conflicting info without flagging the conflict
- Omit source attribution
- Present uncertain information with the same confidence as well-supported facts
- Summarize so aggressively that useful detail is lost

**Do:**
- Lead with the answer
- Group by topic, not by source
- Flag confidence levels when appropriate
- Surface conflicts explicitly
- Attribute all claims to sources
- Offer to go deeper when result sets are large

Источник: anthropics/knowledge-work-plugins / enterprise-search / knowledge-synthesis ↗. Ссылка проверена 2026-10-10.