AI智能总结
大模型在日志运维场景的应用实践 饶 琛 琳日 志 易 产 品 副 总 裁 截屏扫码,领取网络研讨会资料合集(含本期) 目 录Contents 02. 大模型在金融企业应用案例 实践运用大模型的路径 大模型在日志场景的应用方向 背景:某金融企业大量业务日志难点:关键字复杂多变方案:实现知识库增强的自然语言查询效果:故障排查时间缩短40% 构建高质量的训练数据模型的评估和迭代优化产品设计“扬长避短” 更快捷的分析海量日志更智能的解读和预测故障理想vs现实:估算资源 0大模型在日志场景的应用方向 Ø更快捷的分析海量日志Ø更智能的解读和预测故障Ø理想vs现实:估算资源 谷歌Sec-PaLM的日志概要效果 日志问答方案(1):超大窗口 问题1:窗口不会无限大,日志却无限多。 问题2:对于长文本中部的内容,LLM不太敏感。 日志问答方案(2):AgentChain 问题1:运维知识理解的要求较高 问题2:agent/function call能力要求较高 日志问答方案(3):模式提问+分段选择 资源消耗估算 场景看起来很美好,但实际部署时存在一定成本压力。我们进行了一些简单的资源估算: •1000条SSH日志大概包含5-6万个tokens。对于这个长度,LLM推理速度较慢,需要10多秒。•使用最新的Yi-6b-200k模型测试,24GB显存仅能处理约3ktokens,相当于50行日志。•按ChatGLM规模预估,80G显存的单卡最多只能处理200行SSH日志。•并行计算时,8块80G卡也只能同时处理约1600行。 结论: •直接进行日志问答,在理论上可行,但算力需求巨大。•该方案实际成本过高,目前的硬件条件难以支撑实际应用。•生成和调用现有分析工具相对更现实。 0实践运用大模型的路径 Ø构建高质量的训练数据Ø模型的评估和迭代优化Ø产品设计“扬长避短” Text2SPL场景介绍/背景 •SPL对比SQL的差异:没有预知的tableschema。要自行判断prompt里哪些名词疑似字段名。•无法直接套用ChatGPT,SPL目前只是概念通用,语法层无标准:•日志易SPL语法和splunk/kusto/esql/ppl/humio有差别。•日志易内置字段也和CIM/ECS有差别。 •Text to SQL任务是NLP领域的经典课题之一。常见的数 据集有: •WikiSQL,维基百科数据集主要是单表查询,语句比较简单。•Spider,数据集包含join等多表和嵌套,语句比较复杂。在seq2seq之前,模板技术一般评分20+;bert/T5之前,一般评分60+;ChatGPT将评分提升到85+。•CoSQL,在Spider的基础上添加了模糊语义多轮对话。目前评分在50+。•BIRD:新一代数据集,不光考虑表结构,还要考虑脏数据、执行效率。目前ChatGPT评分为40。 通用大模型的表现(2):提示工程不是万能的 问题1:基础模型较差时,复杂逻辑完全无法处理问题2:模型的预训练知识在细节处有严重干扰 训练数据筹备(1):内外网数据搜集 原始数据来源 n指令说明文档n手动编写,含多轮对话n内部应用配置:图表标题及SPL语句ngithub上公开的常用日志关键字ngithub上公开的es/splunk/kusto安全分析规则 训练数据筹备(2):问答类数据增强 ChatGPT⾃⽣成 nalpaca式的self_instruct方案:通过GPT-3.5接口,自动生成部分微调数据。n添加prompt声明圈定问答范围:Act as a Splunk Expertto write SPL。n然后人工复核,调整数据。 训练数据筹备(3):丰富提问方式 StarChat⻆⾊扮演 nstarcoder是开源LLM中编码能力最强的。实验发现他甚至能给出具体的splunk文档url。n通过A/B角色扮演,让starcoder说出对应SPL语句的提问。n效果一般,清洗后去掉了三分之二的数据。 训练数据筹备(4):加入其他产品知识 ⽂档⾃问答 n利用pandoc工具将word文档转为markdown纯文本。n来自北交大transGPT交通大模型的LLMforDialogDataGenerate方法,基于文本生成问答。 模型的评估与迭代 •尝试不同基础模型的效果:•baichuan2的loss长期不收敛 •尝试不同数据配比的效果:•1:2 > 1:5 > 1:1 •尝试构建除文本匹配以外的验证方案:•引入SPLparserAPI语法校验•对比索引实际响应内容 •有趣的是:和Splunk得到了相似的结论。 扬长避短的产品设计 0大模型在金融企业应用案例 Ø背景:金融企业大量业务日志Ø难点:关键字复杂多变Ø方案:实现知识库增强的自然语言查询Ø效果:故障排查时间缩短40% 案例背景 ②.业务系统上千个返回码,人只记得住最常见的10来个。其他的中文含义对应啥返回码? ①.金融企业通常有200-600个业务系统,口头叫法大同小异,但开发商输出到日志里,实际用的是什么标识符? ChatSPL效果 •在“争分夺秒”的故障定位过程中,相比复杂的向量数据库召回方案,ChatSPL场景设计简单易行。查找错误类的用时下降40%。 •业务线运维均可通过ChatSPL进行关键字查询、分组统计、趋势分析,极大的解放了维护平台的高级运维人员。将人力投入到可观测性等高阶能力建设中。 •后续版本的功能计划 •英文版本•查询结果可视化•针对日志/告警的解读•主动推荐可选提问:5W1H•针对日志生成grok正则 •期待开源大模型的成长!! 截屏扫码,领取网络研讨会资料合集(含本期)




