Skip to content

Latest commit

 

History

History
263 lines (198 loc) · 7.34 KB

readme.md

File metadata and controls

263 lines (198 loc) · 7.34 KB

KFC-Agent Planner模块

本模块提供了一套完整的工具链，用于爬取内核崩溃报告、处理讨论内容、构建向量数据库、实现相似崩溃报告的语义搜索，以及基于搜索结果和用户崩溃信息的智能分析，为KFC-Agent提供解决问题的整体执行计划。

系统架构

下图展示了Planner模块的完整工作流程：

Planner系统架构图

系统功能

  • 爬取syzkaller bug报告和相关讨论内容
  • 提取崩溃报告和补丁信息
  • 构建向量数据库实现语义搜索
  • 基于相似度检索相关崩溃案例
  • 结合搜索结果与用户崩溃信息，智能分析问题根因并生成解决方案

安装依赖

pip install -r requirements.txt
pip install selenium  # 用于绕过反爬机制

技术栈与配置

向量数据库

本项目使用ChromaDB作为向量数据库，具有以下配置：

# 初始化配置
client = chromadb.PersistentClient(path="../vector_db")
collection = client.get_collection("crash_reports")

ChromaDB的主要优势：

  • 高性能的相似性搜索
  • 本地持久化存储
  • 支持元数据过滤
  • 易于集成的Python API

Embedding模型

我们使用Sentence Transformers的all-MiniLM-L6-v2模型进行文本向量化：

# 模型初始化
model = SentenceTransformer('all-MiniLM-L6-v2')

该模型特点：

  • 384维向量输出
  • 适合短到中等长度文本
  • 良好的语义捕获能力
  • 计算效率高，资源消耗低

向量化与检索参数

  • 向量维度：384
  • 相似度计算：余弦相似度
  • 检索结果数：默认返回5个最相似结果
  • 相似度分数：基于距离计算，范围0-1，越大表示越相似

使用流程

1. 爬取内核崩溃报告和讨论

1.1 爬取bug链接

python bugs_link_get.py
# 生成bug_links.txt文件

1.2 爬取讨论内容

python discussion_link_get.py
# 使用Selenium绕过反爬机制，爬取每个bug对应的讨论内容
# 结果保存在../discussion_from_syz_raw目录

2. 处理讨论数据

2.1 单文件处理

python process_discussions.py input_file.json [-o output_file.json] [-v]

2.2 批量处理

python batch_process.py ../discussion_from_syz_raw [-o output_directory] [-j 8] [-v]

3. 构建向量数据库

python build_vector_db.py input_directory [-o ../vector_db]
# 将处理后的JSON文件转换为向量数据库

4. 搜索相似崩溃报告

python search_crashes.py
# 启动交互式搜索界面

也可以在代码中直接使用搜索功能：

from search_crashes import CrashSearcher

# 初始化搜索器
searcher = CrashSearcher("../vector_db")

# 搜索相似崩溃报告
query_crash = """
BUG: TASK stack guard page was hit at ffffc9000d66fff8 (stack is ffffc9000d670000..ffffc9000d678000)
kernel panic at mm/vmalloc.c:2703 vunmap_range_noflush+0x1d3/0x250
"""
results = searcher.search(query_crash, n_results=5)

# 处理搜索结果
for case in results['similar_cases']:
    print(f"相似度: {case['similarity_score']}")
    print(f"文件ID: {case['matched_file']['id']}")
    print("补丁内容:", case['matched_file']['patch'])
    print("LLM分析:", case['matched_file']['llm_analysis'])

5. 智能分析与方案生成

在获得相似崩溃案例的搜索结果后，使用Planner模块进行深度分析，结合用户遇到的具体崩溃信息和搜索到的历史解决案例，生成针对性的问题诊断和解决方案。

5.1 综合分析模式

python process_discussions_llm.py --input_file search_results.json --multi-output --config configs/ds_api_config.yaml
# 分析搜索到的相似案例，结合用户崩溃信息生成解决方案

5.2 方案生成流程

Planner模块会执行以下分析流程：

  1. 问题特征提取：从用户的崩溃报告中提取关键特征（错误类型、调用栈、触发条件等）
  2. 案例对比分析：将用户问题与搜索到的相似历史案例进行对比分析
  3. 根因推理：基于相似案例的解决过程，推理用户问题的可能根本原因
  4. 方案制定：结合历史成功案例，制定适合当前问题的解决策略
  5. 执行计划：生成具体的修复步骤和验证方法

5.3 LLM配置

创建配置文件 configs/ds_api_config.yaml：

api_key: "your-api-key"
base_url: "https://api.your-llm-provider.com/v1"
api_model: "your-model-name"

5.4 分析输出示例

# 使用示例
from process_discussions_llm import LLMAnalyzer

analyzer = LLMAnalyzer("configs/ds_api_config.yaml")

# 输入：用户崩溃信息 + 搜索到的相似案例
user_crash = "您的崩溃报告..."
similar_cases = [{"discussion": "...", "patch": "...", "analysis": "..."}]

# 输出：综合分析结果
plan = analyzer.generate_solution_plan(user_crash, similar_cases)

数据流程

  1. 爬取阶段：获取bug链接 → 爬取讨论内容 → 保存为JSON
  2. 处理阶段：解析HTML → 提取关键信息 → 结构化数据
  3. 向量化阶段：加载处理后数据 → 生成嵌入向量 → 构建向量数据库
  4. 检索阶段：输入崩溃报告 → 向量化查询 → 相似度排序 → 返回相似案例
  5. 智能分析阶段：结合用户崩溃与相似案例 → 分析根本原因 → 生成解决方案

Planner分析输出格式

Planner模块的最终输出包含完整的问题分析和解决方案：

{
  "crash_analysis": {
    "user_crash_summary": "用户崩溃问题的概述",
    "crash_characteristics": "崩溃特征分析",
    "similar_cases_summary": "相似案例总结"
  },
  "root_cause_analysis": {
    "primary_cause": "主要根本原因",
    "contributing_factors": "次要影响因素",
    "affected_components": "受影响的内核组件"
  },
  "solution_plan": {
    "strategy_overview": "解决策略概述",
    "specific_actions": [
      {
        "step": 1,
        "action": "具体执行步骤",
        "files_to_modify": ["需要修改的文件"],
        "expected_outcome": "预期结果"
      }
    ],
    "verification_methods": "验证修复的方法",
    "risk_assessment": "风险评估和注意事项"
  },
  "reference_cases": [
    {
      "case_id": "参考案例ID",
      "similarity_score": 0.95,
      "key_insights": "关键洞察"
    }
  ]
}

输出格式

搜索结果包含以下信息：

{
  "query": "输入的崩溃报告",
  "similar_cases": [
    {
      "similarity_score": 0.95,
      "matched_file": {
        "id": "文件ID",
        "source_type": "类型",
        "patch": ["补丁内容"],
        "llm_analysis": {
          "root_cause": "根本原因",
          "fix_approach": "修复方法"
        }
      }
    }
  ]
}

注意事项

  1. 爬取lore.kernel.org时需要使用Selenium绕过反爬机制
  2. 处理大量文件时建议使用批量处理脚本并调整并行任务数
  3. 向量数据库需要足够的磁盘空间和内存
  4. 搜索时，提供更完整的崩溃报告可获得更准确的结果
  5. Planner分析需要高质量的LLM模型，建议使用支持长文本推理的模型
  6. 分析质量很大程度上依赖于搜索到的相似案例质量，建议确保向量数据库内容丰富
  7. 生成的解决方案应结合具体环境进行验证，避免直接应用于生产系统