Skip to content

llm_pipeline.md

Latest commit

 

History

History
94 lines (67 loc) · 7.13 KB

llm_pipeline.md

File metadata and controls

94 lines (67 loc) · 7.13 KB

Алгоритм отправки данных в LLM (по шагам)

Ниже — текущий порядок подготовки и отправки данных в LLM при анализе одного юнита кода.

0. Подготовка

  1. Воркер получает задачу анализа (AnalysisTask) с набором файлов, списком норм и пользовательскими настройками.
  2. Код разбивается на единицы анализа (unit) с метаданными: файл, тип (procedure/function), диапазон строк, изменённые строки, признаки (tags), статические находки.
  3. До LLM‑вызовов применяются пользовательские настройки:
    • если disable_patterns = true, паттерн‑этап пропускается полностью.

1. Шаг выбора норм (selection)

Цель: выбрать ограниченный список норм, которые имеют смысл для проверки данного юнита.

  1. Формируется сокращённый список норм: передаются ID + заголовки + секция + категория (без текста нормы и без подсказок).
  2. Если включена настройка «Использовать все нормы», в список добавляются нормы из norms.yaml.
  3. В подсказке для модели строго указан формат ответа: JSON‑массив norm_id.
  4. В LLM отправляется:
    • краткое описание юнита (файл, диапазон строк, изменённые строки, признаки),
    • фрагмент кода (см. п. 3.1 ниже),
    • список норм (ID + title + section + category),
    • инструкция “выбери нормы, потенциально релевантные этому фрагменту”.
  5. Ответ разбирается; остаются только norm_id, которые реально есть в исходном наборе.
  6. Если список выбранных норм пустой — дальнейший код‑этап для этого юнита пропускается.

2. Шаг проверки критических норм (critical)

Цель: проверить только выбранные нормы для текущего юнита.

  1. На вход берутся только нормы, выбранные на шаге 1 из critical_norms.yaml + custom_norms.yaml.
  2. Формируется полный промт:
    • сведения об юните + исходный код;
    • список статических нарушений (если есть), чтобы LLM их не дублировала;
    • подробные тексты выбранных норм (title, norm_text, rationale, detection_hint, scope и т.д.);
    • инструкция: вернуть строго JSON‑массив с находками (norm_id, section, category, evidence...).
  3. LLM возвращает JSON‑массив находок по выбранным нормам.
  4. Результат сохраняется в ai_findings и пишется в артефакты.

3. Шаг проверки паттернов (pattern)

Цель: отдельно проверить архитектурные/паттерновые нормы.

  1. Шаг выполняется только если disable_patterns = false.
  2. Формируется промт со списком паттернов и инструкции искать нарушения только по паттернам.
  3. LLM возвращает JSON‑массив находок по паттернам.
  4. Результат сохраняется в ai_findings и пишется в артефакты.

4. Шаг проверки остальных норм (norms.yaml)

  1. Выполняется только если включена настройка «Использовать все нормы».
  2. На вход берутся нормы, выбранные на шаге 1 из norms.yaml.
  3. Формируется полный промт с текстами выбранных норм и отправляется в LLM.
  4. Результат сохраняется в ai_findings и артефакты.

5. Шаг объединения результатов (merge)

  1. LLM получает три списка: паттерны, критические нормы, обычные нормы.
  2. Возвращает единый список без дублей (JSON‑массив).
  3. Если merge не удался, используются исходные списки.

6. Маскирование перед отправкой в LLM

Перед отправкой промта в LLM код проходит редактирование только для LLM:

  1. Строковые литералы заменяются на <REDACTED>.
  2. Комментарии заменяются на <REDACTED_COMMENT>.
  3. Маскирование применяется только к контенту, отправляемому в LLM.
  4. Для пользователя и UI исходный код не изменяется и показывается полностью.
  5. Отчёт о маскировании сохраняется в артефактах.

4. Артефакты

Для каждого шага сохраняются:

  • {run_id}_{stage}_llm_log_{n}_prompt.txt
  • {run_id}_{stage}_llm_log_{n}_response.txt
  • {run_id}_{stage}_llm_log_{n}.json (полная структура)
  • {run_id}_{stage}_llm_redaction_{n}.json (отчёт маскирования)

Где stage = select | critical | pattern | norms | merge | query.

Важно: *_select_llm_log_*_response.txt — это ответ LLM на этапе отбора применимых норм. Он не является итоговым ответом с нарушениями. Финальные нарушения появляются только после шагов critical / norms / query и попадают в ai_findings.

5. Ограничения на объём

  • На шаге selection суммарный размер списка норм ограничен лимитом MAX_NORM_SELECTION_CHARS (сейчас 100_000).
  • На шаге code ограничения зависят от модели/провайдера (в коде жёсткого лимита нет).

6. Критерии воспроизводимости

  • Выбор норм отделён в отдельный этап, чтобы минимизировать “шум”.
  • Результаты по‑прежнему зависят от LLM (модель/температура/провайдер). Для строгой повторяемости лучше фиксировать модель и параметры.