辜毕照拥背景与目标
宽表已包含工单名、工单总结（长文本）和聊天记录。传统 SQL 或关键词搜索无法有效挖掘语义层面的重复模式、根因及最佳实践。
本方案目标：
从月度 2 万条（或百万级）工单文本中自动发现 10--30 个知识主题
生成可读知识卡片（主题名称、典型描述、根因、推荐方案）
每条结论附原始工单 ID，确保可追溯
LLM 调用次数固定，与样本量无关
整体处理时间：2 万条数据小于 5 分钟
核心技术组合
Embedding：BGE-M3（1024 维）
聚类：k-LLMmeans（GitHub: jairoadiazr/k-LLMmeans）
向量存储：ClickHouse 原生 Array(Float32) + HNSW 索引
Agent 框架：LangGraph（封装为 KnowledgeMiningTool）
处理位置
Embedding 与 k-LLMmeans 聚类：全部在 Agent 侧（Python 进程）完成
ClickHouse：仅负责数据拉取、向量持久化存储及 HNSW 索引
向量存储设计（推荐独立表）
CREATE TABLE IF NOT EXISTS work_order_embeddings (
order_id String,
dt Date,
embedding Array(Float32),
cluster_id UInt32 DEFAULT 0,
cluster_summary String
) ENGINE = MergeTree()
ORDER BY (dt, order_id);
ALTER TABLE work_order_embeddings
ADD INDEX embedding_hnsw embedding TYPE hnsw('L2Distance') GRANULARITY 1000;
系统架构图
输出层
Agent 侧 Python + LangGraph
ClickHouse 存储层
1.时间范围查询
2.拉取文本
3.生成向量
4.读取向量
5.LLM 生成质心
6.写入聚类结果
7.生成报告
宽表 wide_work_order_table\n工单名 + 总结 + 聊天记录
向量表 work_order_embeddings\nembedding + HNSW索引
KnowledgeMiningTool
BGE-M3 Embedding\nsentence-transformers
k-LLMmeans 聚类引擎
LLM\nQwen2.5 / DeepSeek / Grok\n仅生成质心总结
知识维度报告\nMarkdown/PDF\n知识卡片 + 可追溯ID
处理流程图
用户输入时间范围
Agent 调用 ClickHouse\n拉取工单文本数据
Agent 侧 BGE-M3\n批量生成 Embedding\n拼接工单名 + 总结 + 聊天记录
向量写入 ClickHouse\nwork_order_embeddings 表\n支持增量
Agent 侧 k-LLMmeans\nn_clusters=15~20\nLLM 仅对质心调用\n与样本量无关
聚类结果写回 ClickHouse\ncluster_id + cluster_summary
LLM 生成知识报告\n每簇包含：\n主题名称\n占比\n根因与方案\nTop5 工单ID
知识维度报告完成\n可存入知识库 RAG
主要优势
聚类结果可解释且 100% 可追溯
支持百万级扩展（分批 Embedding + 子采样）
LLM 调用次数固定，成本可控
可直接集成现有 ClickHouse 宽表
内存占用与百万级扩展性补充
k-LLMmeans 聚类阶段需将 embedding 向量从 ClickHouse 查询到 Agent 侧 Python 内存中处理。
BGE-M3 1024 维向量（Float32）每个占用 4 KB。实际内存占用如下：
2 万条：约 78 MB（含 Pandas 开销 < 200 MB）
10 万条：约 390 MB（普通服务器无压力）
100 万条：约 3.81 GB（需 16 GB 以上内存）
2 万 ~ 10 万条规模下，当前方案可直接运行，无内存风险。
针对百万级扩展，已设计以下增量优化路径（代码改动 < 50 行）：
子采样 + HNSW 分配（推荐）：仅采样 5~10 万条向量运行 k-LLMmeans，其余向量通过 ClickHouse HNSW 索引执行一次相似度查询分配到最近簇，精度损失 < 3%。
分页分批处理：使用 LIMIT/OFFSET 分批拉取，每批独立 MiniBatch 处理后合并质心。
增量处理机制：每次仅处理新增 dt 分区，历史 embedding 与 cluster_id 永久复用。