ДЗ-08: Graph + AI — автоматичне резюмування кластерів
Урок: Урок-08-Теорія-графів
Graph + AI: автоматичне резюмування кластерів
Датасет:
готовий граф із репозиторію GephiDatasets або власний knowledge graph.
Основний датасет для роботи за запитом лектора:
patents_full_enrichment_0304.xlsx
Мета: після виконання цього домашнього завдання ви маєте:
- побудувати граф на основі підготовленого датасету;
- навчитися знаходити спільноти / кластери у графі через modularity;
- експортувати дані про вузли та їхню належність до кластерів;
- використати LLM для створення коротких описів кластерів;
- вручну перевірити AI-опис і прибрати недоказові або вигадані твердження;
- зрозуміти межу між автоматизацією аналізу та доказовим OSINT.
ЩО ПОТРІБНО ЗРОБИТИ
1. Побудова графа
Побудуйте граф на основі одного з варіантів:
- готового графа з репозиторію GephiDatasets;
- власного knowledge graph;
- датасету
patents_full_enrichment_0304.xlsx, якщо працюєте з кейсом за запитом лектора.
Для кейсу з патентами потрібно:
- patents_full_enrichment_0304.xlsx — датасет;
- встановити відношення групи патентів до виробу типу БЕК;
- встановити зв’язки між кластерами патентів та науковим персоналом;
- репрезентувати це як очищений від зайвих даних граф.
На що звернути увагу:
- у графі мають залишитися тільки ті вузли та зв’язки, які допомагають зрозуміти структуру кластерів;
- зайві, дубльовані або нерелевантні дані потрібно прибрати;
- граф має бути придатним для аналізу, а не просто “великим і страшним павуком”, від якого хочеться закрити ноутбук.
2. Запуск modularity
У Gephi запустіть modularity для визначення спільнот / кластерів.
Після цього перевірте, що для вузлів з’явився атрибут:
community;- або
modularity class; - або інший аналогічний параметр, який показує належність вузла до кластера.
На що звернути увагу:
- modularity допомагає побачити, які вузли частіше пов’язані між собою;
- це не автоматичний доказ, що кластер має саме таку природу;
- інтерпретація кластера завжди потребує перевірки.
3. Експорт таблиці вузлів
Експортуйте таблицю вузлів із Gephi.
У таблиці мають бути:
- назва / ID вузла;
- community або modularity class;
- значення centrality;
- додаткові атрибути, які допомагають пояснити вузол;
- для патентного датасету — ознаки, які допомагають пов’язати патенти, виріб типу БЕК, кластери та науковий персонал.
Файл потрібно зберегти як:
nodes_with_communities.csv
4. Опис 3–5 найбільших кластерів
Оберіть 3–5 найбільших кластерів.
Для кожного кластера створіть короткий markdown-блок.
У кожному блоці має бути:
- список вузлів;
- топ-вузли за centrality;
- можливе пояснення кластера;
- питання для перевірки;
- позначка, які висновки є попередніми і потребують валідації.
Рекомендована структура опису кластера:
## Cluster [номер / назва]
### Список вузлів
- [вузол 1]
- [вузол 2]
- [вузол 3]
### Топ-вузли за centrality
| Вузол | Centrality score | Чому важливий |
|---|---:|---|
| | | |
| | | |
### Попереднє пояснення кластера
[Короткий опис. Формулювати обережно: “можливо”, “структурно схоже на”, “потребує перевірки”.]
### Питання для перевірки
1. [Що потрібно перевірити?]
2. [Яке джерело може підтвердити або спростувати зв’язок?]
3. [Який ризик хибної інтерпретації?]
5. Використання LLM для чернетки опису
Використайте LLM для створення першої чернетки опису кластерів.
У prompt потрібно передати:
- список вузлів у кластері;
- топ-вузли за centrality;
- короткий контекст датасету;
- чітке обмеження: не вигадувати природу кластерів;
- вимогу формулювати висновки тільки обережними фразами.
Prompt потрібно зберегти у файл:
prompt.md
Обов’язкова вимога до LLM:
LLM не має вигадувати природу кластерів. Вона може писати тільки в режимі:
- “можливо”;
- “потребує перевірки”;
- “структурно схоже на”;
- “на підставі лише графа не можна стверджувати”.
6. Ручна перевірка та виправлення
Після генерації описів вручну перевірте результат.
Що потрібно зробити:
- прибрати твердження, які LLM не може довести на основі графа;
- виправити перебільшення;
- позначити слабкі або неперевірені висновки;
- залишити тільки ті формулювання, які відповідають даним;
- додати короткі нотатки рев’юера.
Файл із нотатками потрібно зберегти як:
reviewer_notes.md
7. Секція “LLM hallucination risks”
У файлі cluster_summaries.md додайте окрему секцію:
## LLM hallucination risks
- Які твердження LLM могла вигадати або перебільшити?
- Де LLM могла помилково пояснити природу кластера?
- Які зв’язки потребують додаткової перевірки?
- Які висновки не можна робити лише на підставі графа?
На що звернути увагу:
- LLM може красиво пояснити навіть те, чого в даних немає;
- граф показує структуру зв’язків, але не завжди пояснює їхню причину;
- доказовий OSINT починається там, де ви перевіряєте припущення, а не закохуєтесь у гарну відповідь AI.
ФОРМАТ ВИКОНАННЯ
Здайте домашнє завдання у вигляді папки або архіву з такою структурою:
homework_cluster_summaries/
├── nodes_with_communities.csv
├── cluster_summaries.md
├── prompt.md
└── reviewer_notes.md
ЩО САМЕ ПОТРІБНО ЗДАТИ
nodes_with_communities.csv— таблиця вузлів із community / modularity class;cluster_summaries.md— описи 3–5 найбільших кластерів;prompt.md— prompt, який використовувався для LLM;reviewer_notes.md— ручні правки, зауваження та перевірка AI-висновків.
ACCEPTANCE CRITERIA
Обов’язкові вимоги
- граф побудований на основі готового датасету або власного knowledge graph;
- для датасету
patents_full_enrichment_0304.xlsxвстановлено зв’язки між групами патентів, виробом типу БЕК та науковим персоналом; - граф очищений від зайвих або нерелевантних даних;
- у Gephi запущено modularity;
- експортовано таблицю вузлів із community / modularity class;
- описано 3–5 найбільших кластерів;
- для кожного кластера є список вузлів;
- для кожного кластера вказані топ-вузли за centrality;
- для кожного кластера додано можливе пояснення;
- для кожного кластера сформульовано питання для перевірки;
- додано секцію LLM hallucination risks;
- prompt збережено окремим файлом;
- є ручна перевірка та виправлення AI-опису.
ВАЖЛИВО
- LLM не має робити категоричні висновки про природу кластерів.
- Формулювання мають бути обережними: “можливо”, “потребує перевірки”, “структурно схоже на”.
- На підставі лише графа не можна стверджувати причинно-наслідкові зв’язки.
- Якщо зв’язок не підтверджений джерелом або додатковими даними — його потрібно позначити як гіпотезу.
- Завдання має показати не лише вміння автоматизувати аналіз, а й уміння не повірити AI на слово. Це той випадок, коли “гарно написано” ще не означає “правда”.
Додаткові матеріали
- GephiDatasets — освітні датасети для Gephi (готові графи для практики візуалізації та аналізу мереж)
- patents_full_enrichment_0304.xlsx — основний датасет для кейсу з патентами