Разработка Датасетов

      Подготовка Датасетов для тренинга локальной модели ИИ Qwen.
      
      Для дообучения (fine tuning) компактной локальной моделии ИИ (например, Qwen) необходимо около 2-3 тысяч специализированных примеров в JSON формате.
      Если нет готового набора данных для тренировки ИИ, можно его сгенерировать с помощью другого, более "продвинутого" ИИ.
      Для примера, подготовим JSON Dataset для тренировки ИИ Qwen2.5 для анализа таблиц маршрутизации ("show ip route") реального сетевого оборудования в локальной сети предприятия.
      
      Dataset Development (Удаленная работа)
      

      
      Удаленная работа >>
      
      AI Qwen Dataset
      
      Для генерирования тренингового Датасета напишем хорошо структурированный Prompt
      

Детальный PROMPT для генерации JSON-датасета для fine-tuning моделей анализа таблиц 
маршрутизации Cisco

РОЛЬ И ЗАДАЧА

Ты — эксперт по генерации синтетических обучающих данных для fine-tuning компактных 
LLM (7B-14B параметров). Твоя задача — генерировать высококачественные JSON-примеры 
для обучения модели анализу таблиц маршрутизации Cisco (`show ip route`).

СТРУКТУРА КАЖДОГО ПРИМЕРА

Каждый пример должен строго соответствовать формату:

 json
{
  "messages": [
    {
      "role": "system",
      "content": "You are a network routing expert. Analyze the routing table, detect issues, 
       and provide step-by-step reasoning. Use the format: ...step-by-step 
       analysis......concise answer..."
    },
    {
      "role": "user",
      "content": "Routing table:\n\n\nQuestion: "
    },
    {
      "role": "assistant",
      "content": "\n1. [First observation]\n2. [Second observation]\n...\n[N]. [Final 
       observation]\n\n\n[Clear, actionable conclusion with severity level: 
       CRITICAL/WARNING/INFO]\n"
    }
  ]
}
 
КАТЕГОРИИ ОШИБОК ДЛЯ ГЕНЕРАЦИИ

Генерируй примеры, равномерно распределяя по следующим категориям (минимум 3-5 
примеров на каждую):

 1. Маршрутные петли (Routing Loops)
- Два или более маршрута к одной сети с одинаковыми AD и метриками через разные next-hop
- Пример: `S 10.1.1.0/24 [1/0] via 192.168.1.1` и `S 10.1.1.0/24 [1/0] via 192.168.2.1`
- Сценарии: ECMP без корректной конфигурации, перекрестные статические маршруты

 2. Ошибки суммаризации (Summarization Errors)
- Over-summarization: Слишком широкая маска, включающая несуществующие сети
- Under-summarization: Отсутствие суммаризации для последовательных сетей (/24 > /22)
- Overlapping summaries: Пересекающиеся суммарные маршруты с разными next-hop

 3. AD-конфликты (Administrative Distance Conflicts)
- Одна сеть изучается через несколько протоколов с разными AD
- Статика (AD=1) перебивает динамические протоколы (OSPF AD=110, BGP AD=20/200)
- Неправильный выбор активного маршрута

 4. Проблемы с next-hop
- Next-hop недостижим (нет ARP-записи)
- Next-hop находится в несуществующей сети
- Маршрут помечен как `invalid` или `unreachable`

 5. Проблемы балансировки нагрузки (Load Balancing Issues)
- Несинхронное обновление маршрутов (разное время в таблице)
- Неравные метрики для путей, которые должны быть равными
- Асимметричный routing при ECMP

 6. Перекрывающиеся сети (Overlapping Networks)
- Одна сеть полностью вложена в другую с разными next-hop
- Connected маршруты внутри статической/динамической суммаризации

 7. Здоровые таблицы (Healthy Tables)
- Нет ошибок
- Правильная суммаризация
- Корректная балансировка
- Рабочие next-hop

 ТРЕБОВАНИЯ К ГЕНЕРАЦИИ

 A. Разнообразие синтаксиса
Используй реальные форматы вывода `show ip route`:
- Статические: `S    10.1.1.0/24 [1/0] via 192.168.1.1`
- OSPF: `O    10.1.1.0/24 [110/2] via 10.0.0.2, 00:01:23, GigabitEthernet0/0`
- Connected: `C    192.168.1.0/24 is directly connected, GigabitEthernet0/0`
- BGP: `B    10.1.0.0/16 [20/0] via 192.168.1.1`
- EIGRP: `D    10.1.1.0/24 [90/30720] via 10.0.0.2`

 B. Структура рассуждений (Reasoning)
Рассуждения должны содержать:
1. Наблюдение: Что видно в таблице
2. Анализ: Почему это проблема или не проблема
3. Контекст: Как это влияет на сеть
4. Рекомендация: Что нужно сделать

 C. Вариативность сложности
- Простые: Одна явная ошибка (легко обнаружить)
- Средние: 2-3 связанные ошибки
- Сложные: Комбинация ошибок, требующая глубокого анализа (например, петля + AD-конфликт 
   + проблемы суммаризации)

 D. Сбалансированность датасета
- 60% — примеры с ошибками (распределены по категориям)
- 25% — здоровые таблицы (для обучения нормальному поведению)
- 15% — пограничные случаи (предупреждения, не критические проблемы)

 ?? ТЕХНИКИ УЛУЧШЕНИЯ ОБУЧЕНИЯ

 1. Chain-of-Thought (CoT)
Всегда требуй пошаговое рассуждение перед ответом. Это критически важно для 
компактных моделей.

 2. Конкретные вопросы
Вопросы должны быть конкретными, а не общими:
- "Does this routing table contain a routing loop?"
- "Identify any summarization errors in this table."
- "Analyze this routing table."

 3. Маркеры важности
В ответе указывай уровень серьезности:
- `CRITICAL`: Петли, недостижимые next-hop
- `WARNING`: AD-конфликты, проблемы суммаризации
- `INFO`: Рекомендации по оптимизации

 4. Аугментация данных
Генерируй вариации одного сценария:
- Меняй IP-адреса
- Меняй маски подсетей
- Меняй метрики и AD
- Добавляй/убирай временные метки

 5. Детализация
Для каждой ошибки включай:
- Тип ошибки
- Конкретные строки из таблицы
- Причину проблемы
- Шаги по исправлению
- Ожидаемый результат после исправления

 ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ

 Формат вывода:
- Чистый JSON (без комментариев, без Markdown-обертки)
- Каждый пример в отдельной строке (JSONL)
- Кодировка: UTF-8
- Максимальная длина сообщения: не более 2048 токенов

 Распределение длин:
- Короткие таблицы (3-5 маршрутов): 30%
- Средние таблицы (6-10 маршрутов): 50%
- Длинные таблицы (11-15 маршрутов): 20%

 Валидность:
- Все маршруты должны быть синтаксически корректными
- IP-адреса должны быть в правильном формате
- Маски подсетей должны быть действительными
- Метрики должны быть числами

 ПРИМЕРЫ ВОПРОСОВ (для разнообразия)

1. "Does this routing table contain a routing loop?"
2. "Identify any summarization errors in this routing table."
3. "Analyze this routing table for Administrative Distance conflicts."
4. "Does this routing table have any unreachable next-hop addresses?"
5. "Identify any load balancing issues in this routing table."
6. "Are there any overlapping networks in this routing table?"
7. "Does this routing table have any routing inconsistencies?"
8. "Identify all potential issues in this routing table and classify them by severity."
9. "Is this routing table optimized for performance and redundancy?"
10. "What routing issues could cause network instability in this configuration?"

 ПАРАМЕТРЫ ГЕНЕРАЦИИ

 Для генерации используй следующие настройки:
- Температура: 0.7-0.9 (для разнообразия)
- Top-p: 0.9
- Количество примеров: 100-500 для начального датасета
- Пропорции: 80% с ошибками, 20% здоровые

 Дополнительные инструкции:
- Никогда не генерируй одинаковые примеры
- Каждый пример должен быть уникальным
- Используй разные сетевые топологии
- Включай реальные сценарии из практики
- Добавляй комментарии в reasoning о том, КАК именно обнаружена ошибка
- Указывай в answer конкретные действия по исправлению

 ВАЛИДАЦИЯ ГЕНЕРИРУЕМЫХ ПРИМЕРОВ

Перед выдачей проверь каждый пример на:
1. Синтаксическую корректность JSON
2. Наличие всех обязательных полей
3. Правильность формата маршрутов
4. Логическую непротиворечивость (если указана петля, действительно есть петля)
5. Соответствие формату reasoning/answer
6. Отсутствие дубликатов с предыдущими примерами

 ФОРМАТ ВЫВОДА

Генерируй примеры в формате JSONL (каждый пример — отдельная строка):

 jsonl
{"messages": [{"role": "system", "content": "..."}, {"role": "user", "content": "..."}, 
{"role": "assistant", "content": "..."}]}
{"messages": [{"role": "system", "content": "..."}, {"role": "user", "content": "..."}, 
{"role": "assistant", "content": "..."}]}
 

Начни генерацию с категории [УКАЖИ КАТЕГОРИЮ] и создай 
[УКАЖИ КОЛИЧЕСТВО] примеров.