日志AI助手

TLS Copilot是面向日志检索场景提升易用性的的AI agent。包括但不限于，text2sql,语句报错修改,文档问答等。 TLS Copilot采用基于ReAct架构演进的Multi-Agent架构设计，基于Eino框架开发实现。该架构通过一个中心分发者（HostAgent）和多个专业子Agent的组合模式，实现了系统功能的高度模块化和专业化，提高了系统的可维护性，使得功能扩展变得更加灵活。

总体架构

在这个架构中，各组件协同工作，形成了一个完整的智能系统生态：

• HostAgent：作为系统的中枢，负责意图识别和工具调用。它接收用户输入，分析意图，然后将请求分发给相应的专业Agent或调用适当的工具。
• Eino框架：作为系统的骨架，提供了对话流编排、工具调用、切面注入、三方组件集成等基础设施。Eino框架的核心优势在于其高度的可扩展性和灵活性，使用它可以便捷的构造工作流和对话流，在业务流程中集成AI组件。
• 专业子Agent（对话流）：每个子Agent都是特定领域的专家，如Text2SQL、报错修复、产品问题咨询、采集配置推荐等。这些Agent通过定制化的流程编排、prompt优化，能够在各自的领域提供高质量的服务。子Agent本质上就是对话流（Conversation Flow）的具体实现，可以直接与用户交互并流式输出回复。

HostAgent与子Agent的角色与职责

TLS Copilot的Multi-Agent架构设计明确了各个Agent的角色和职责，形成了一个高效协作的智能系统网络： HostAgent的核心职责：

• 意图识别：基于对话上下文，准确识别用户意图采取下一步行动。
• 工具调用管理：根据需求调用TLS MCP、工作流等各类工具。
• Agent分发决策：智能选择最适合的子Agent处理请求。 子Agent（对话流）的专业职责：
• 领域专精：在特定领域提供深度专业服务。
• 直接交互：能够与用户进行流畅的对话交流。
• 工具使用：对话流的编排不受限制，在对话流中也可以给LLM节点挂载mcp工具或者子工作流，调用专业工具完成复杂任务。 这种分层架构设计带来了多重优势：
• 关注点分离，每个Agent只需专注于自己的领域。
• 提高了系统的可扩展性，新增功能只需开发新的子Agent或工作流。

工作流与对话流的概念区分与应用场景

TLS Copilot系统中抽象了两个关键概念：工作流和对话流。这两个概念的明确区分是系统设计的一大创新，使系统能够灵活应对不同类型的任务需求。

系统组件

1. 火山方舟 目前copilot已经不再自建模型推理服务，所有基座模型均采用火山方舟提供的模型服务，充分利用并池带来的成本优势。在在线推理上主要选择 共享部署 方式，模型调用按量付费。对于精调过的模型例如text2sql mini助手，则选择独占部署以获得稳定服务。
2. 数据存储 TLS（对话记录存储底座）和TOS（附件存储底座）是TLS Copilot系统的核心存储组件，它们为系统提供了稳定可靠的数据持久化能力。 TLS 对话记录存储与Trace分析：
3. 对话数据存储：结构化日志形式存储对话历史
4. 反馈数据存储：点赞点踩事件存储
5. Trace数据分析：通过eino切面上传执行轨迹至tls trace
6. 数据飞轮支持：基于TLS实现会话分析、轨迹分析，作为数据飞轮的输入源 TOS 对话附件存储：
7. 附件存储支持：支持对话附件（图片、日志原文）存储。

TLS和TOS之间的数据协同工作，形成了完整的用户交互记录：当用户与系统交互时，文本对话内容存储在TLS中，而相关的文件和多媒体内容则存储在TOS中，两者通过唯一的资源URI关联。 3. 安全风控 为把控llm输出内容的安全风险，copilot接入了火山文本内容风险识别服务，以旁路 、流式 的形式检测内容安全，每50字一个切片检测，检测到风险通知前端撤回已显示的内容。 4. 离线优化 我们在离线阶段大量使用了coze平台来做数据合成、prompt开发与优化、测评集管理等等工作。针对不同场景构建了数个数据合成工作流，充分利用llm完成优质数据生成工作。

关键技术点

Text2SQL功能实现

Text2SQL功能的深度思考模式是TLS Copilot系统中处理复杂SQL查询需求的高级解决方案。该模式基于最新的深度思考模型，通过精心设计的Prompt工程实现。 技术原理： 深度思考模式基于"思维链"（Chain-of-Thought）和"思考后回答"（Think-Then-Answer）等推理技术，大语言模型进行多步骤的结构化思考，从而生成准确的SQL查询语句。 实现细节：

1. 模型选择策略：

• 优先考虑具有强推理能力、强代码能力的模型
• 定期评估新出的模型

2. Prompt工程优化：

• 检索分析背景知识
• 函数元信息rag
• 冲突和歧义场景处理策略
• 常见语法易错点few-shot

3. 输出格式化：

• 提供详细的思考过程，便于用户理解
• 清晰标注最终SQL语句
• 附加功能说明和注意事项
• 可能的优化建议 深度思考模式的一个关键创新是"透明推理过程"，它不仅展示最终的SQL结果，还展示了从需求到SQL的完整推理路径，帮助用户理解和验证查询逻辑。 深度思考模式特别适用于复杂的分析需求，复杂条件组合、高级函数应用等场景，虽然响应时间较长，但能提供更高质量和可靠性的查询结果。

Mini助手模式

Mini助手模式是TLS Copilot系统中的另一种Text2SQL实现方式，它基于doubao-1.5-pro-32k模型进行专项训练，旨在提供快速、精准的SQL生成服务，特别适合自动化场景的查询需求。 技术实现:

1. 基础模型与训练：

• 基于doubao-1.5-pro-32k模型进行微调
• 采用监督微调（SFT）和DPO（Direct Preference Optimization）相结合的训练方法
• 训练数据覆盖常见函数用法和查询模式

2. 模型优化技术：

• 知识蒸馏：从深度思考模型中提取关键知识
• 参数高效微调：使用LoRA等技术降低训练成本

3. 输出控制机制：

• 严格控制输出格式和长度
• 直接生成SQL语句，省略思考过程
• 仅提供必要的注意事项和使用提示 优化方法： 为了确保Mini助手模式的高效和准确性，系统采用了多种优化方法：

  优化方向	具体措施	效果
  函数专精训练	针对常用函数进行专项训练	提高函数使用的准确性
  错误模式识别	分析常见错误，加强相应训练	减少典型错误的发生
  语法强化	增加语法正确性的训练权重	提高SQL语法的正确率
  响应时间优化	模型裁剪和推理优化	将响应时间控制在10秒以内
  部署架构优化	独占资源部署，避免资源竞争	确保服务稳定性
  Mini助手模式的核心价值在于"高效精准"，它通过牺牲详细推理过程，换取极快的响应速度和稳定的输出质量，特别适合需要快速响应的产品集成场景。
  Mini助手模式已成功应用于多个自动化场景，如chat2topic MCP工具、业务知识日志分析机器人等，证明了其在实际应用中的价值和效果。

两种模式的应用场景与选择策略

TLS Copilot系统中的两种Text2SQL模式各有优势，系统需要根据不同的应用场景和需求特点，智能选择最合适的模式。 应用场景对比： 深度思考模式适用场景：

• 复杂分析需求：涉及复杂条件和高级函数
• 探索性分析：用户需要理解查询逻辑和思考过程
• 教学场景：帮助用户学习SQL和日志分析方法
• 交互式分析：用户需要根据思考过程调整需求 Mini助手模式适用场景：
• 自动化集成：作为其他系统的API服务
• 快速生成：用户需要立即获得结果
• 标准操作：处理常见的、结构化的查询需求
• 结果稳定：需要持续的精准生成
• 产品功能集成：如chat2topic、日志分析机器人

基于知识蒸馏的数据合成

函数基本用法数据合成

数据质量是决定Text2SQL模型性能的关键因素。TLS Copilot系统采用了基于官方文档的数据生成技术，确保模型能够准确理解和使用日志服务的各种函数。 技术实现流程：

1. 函数元信息解析与构建： 自动抓取和解析日志服务函数官方文档，识别函数名称、参数、返回值和用法说明，构建函数知识库，包含完整的函数元数据
2. 场景设计（提问+索引结构）： 为每类函数设计典型应用场景，生成针对性的提问和topic索引结构，并且注意设计参数变化策略，覆盖边界条件。
3. 数据生成： 构造了能够基于函数元信息生成训练样本的工作流，每个输入样本包含：提问（用户需求）、索引（数据结构）和函数元信息，使用最强推理模型蒸馏预期的回复（在prompt中特别强调函数的应用场景，引导模型关注这个函数，避免生产了其他等价回复导致此函数用法没有被覆盖）
4. 质量控制： 构造基于执行查询的语法校验工具自动验证生成的SQL语法正确性，人工抽样审核，查看语义一致性是否满足要求。

In-Context-Learning

In Context Learning，指在大型语言模型（LLM）中，模型能够依据给定的上下文（比如对话、文章或其他文本序列）进行自我学习和响应的一种能力。这种学习方式需要模型能理解和运用上下文信息，比如之前的对话或文本内容，来更精确地预测和生成接下来的文本。通过使用ICL，模型可以在没有额外训练数据的情况下，仅依靠上下文信息进行适应和学习，从而提高其响应的准确性和适应性。

随着模型规模和语料库规模的扩大，大型语言模型展示了从由上下文中的几个示例组成的演示中学习的新能力(简称ICL，上下文学习)。许多研究表明，LLMs可以使用ICL执行一系列复杂的任务，如解决数学推理问题。这些强大的能力已经被广泛验证为大型语言模型的新兴能力。

通用大模型基于大规模的语料进行训练，它们在一些通识问答上展现出强大的性能，但是也存在一定的局限性，比如幻觉、私有领域知识理解差。为了克服这种问题，较为流行的方式是利用向量相似度查询，为用户的提问嵌入相关的私域知识上下文，利用大模型的ICL能力，提升问答效果。这种方案叫做RAG（检索增强生成），一个基本的RAG流程如下： 基础RAG（Baseline RAG）依赖用户问题与文档块的语义相似度（向量相似度）来召回可能与用户提问相关的背景知识，它在某些情况下表现的非常差。例如：Baseline RAG很难连点成线，如果问题回答需要通过共用属性（文档块之间的某种联系）关联不同的文档块以提供综合推理回答时，它的效果就不尽如人意了。

GraphRAG知识图谱建模

GraphRAG 是检索增强生成（RAG）的结构化升级形态，它将传统“按相关度截取文档片段”的线性检索，转化为基于实体与关系的图结构检索。通过对原始知识库进行实体抽取、关系发现与图谱构建，GraphRAG 让大模型能够在推理时直接访问显式的知识关联，而非依赖分散的文本匹配结果。这种结构化表示为跨文档、多跳推理和长链依赖场景提供了更高的信息组织效率。

简介

24年7月2日，微软开源了GraphRAG。通过 LLM 构建知识图谱结合图机器学习，GraphRAG 极大增强 LLM 在处理私有数据时的性能，同时具备连点成线的跨大型数据集的复杂语义问题推理能力。微软在其博客上介绍说，他们在大规模播客以及新闻数据集上进行了测试，在全面性、多样性、赋权性方面，结果显示 GraphRAG 都优于朴素 RAG（70~80% 获胜率）。 GraphRAG 是一种基于图的检索增强方法，由微软开发并开源。它通过结合LLM和图机器学习的技术，从非结构化的文本中提取结构化的数据，构建知识图谱，以支持问答、摘要等多种应用场景。GraphRAG的特色在于利用图机器学习算法进行语意聚合和层次化分析，从而能够回答一些高层次的抽象或总结性问题，这是常规RAG系统的短板。 GraphRAG的核心在于其处理流程，包含2个阶段：Indexing和Querying。

• 在Indexing阶段：GraphRAG将输入文本分割为多个可分析单元（称为TextUnits）。使用LLM提取实体、关系和关键声明。然后通过层次聚类技术（例如Leiden算法）对图谱进行社区划分，并生成每个社区的摘要
• 在Querying阶段：这些结构被用来提供材料，以作为LLM的context来回答问题。查询模式包括全局搜索和局部搜索：
  • 全局搜索：通过利用社区的总结来推理关于语料库整体问题的答案
  • 局部搜索：通过扩展到特定实体的邻居和相关概念来推理关于特定实体的问题 相对于传统的RAG方法，在处理私有数据集时展现出显著的性能提升。它通过构建知识图谱和社区分层，以及利用图机器学习技术，增强了对复杂信息的问答性能，尤其是在需要全面理解大型数据集或单一大型文档的语意概念时。

索引流程

1. 文档切片（chunk），做Embedding，生成Text Units 将原始私域知识文档（一系列.txt文档）按一定大小（默认1200token）切分为text unit。生成一个列存文件create_base_text_units.parquet
2. 从文本中提取entities、relationships 循环对所有文档块分析，利用大模型提取组成知识图谱的基本单元：实体Entity、关系（Relationship） Entities & Relationship提取 在第一步Graph Extraction中，我们使用LLM抽取text unit中的实体和关系。输出为每个text unit的sub-graph，包含一组entities及其对应的名称、类型和描述；以及一组relationships及其源、目标和描述。 然后，将这些sub-graph进行合并。任何具有相同名称和类型的entity视为同一个entity，并将对应的描述内容合并为数组。同样，任何具有相同源和目标的relationship视为同一个relationship，并将其描述合并为数组。 Entity & Relationship Summarization 现在我们有了一个实体和关系的图，每个实体和关系都有一个描述列表，我们可以将这些列表总结为每个实体和关系的单个描述（通过 LLM 对所有描述做摘要）。这样，所有的实体和关系都可以有一个简洁的描述。 此步骤执行完毕会生成create_base_extracted_entities.parquet列存文件，存储原始图信息。
3. 在entities中执行community detection（图增强） 为了给知识图谱附加更高层次的信息，以及挖掘潜在的节点之间的联系，图增强阶段采用一定的算法执行“社区检测”以及“图嵌入Graph Embedding”，使得我们能够以显示（社区community）和隐式（embedding）的方式来理解图的拓扑结构。 首先使用Leiden算法对图进行层次化的递归聚类，直到达到某个阈值。社区可以理解为一个子图的聚类描述，将具有相似度的实体聚合起来，描述他们的共同特点。 接着使用Node2Vec算法生成图的向量表示，可能在后续查询过程中提供额外的搜索空间，增强搜索效果（阅读检索源码时没发现此步骤） 图增强完成后，会对实体Entity进一步处理，为实体表增加实体描述的向量表示列（在检索时会以用户提问和此向量列进行相似度查询），最终生成entities表和relationships表（create_final_entities.parquet、create_final_relationships.parquet、create_final_communities.parquet）
4. 在多个粒度级别生成community summaries和reports（使用大模型） 使用大模型为上个步骤获得的每个社区生成摘要，这个是的我们能够理解每个社区所包含的独特信息，由于社区是从低到高分层次聚类获得的，为每个社区生成摘要也能使得我们能够从低层次到高层次对整个知识图谱有不同的理解和认知。接着使用大模型对每个社区摘要再进行总结，最后我们生成CommunityReports表（create_final_comunity_reports.parquet）。

查询流程

启动流程中执行，主要分为两阶段：第一阶段将实体写入向量数据库，第二阶段将知识图谱其他内容构造成DataFrame，便于背景知识检索时的数据分析

local search

Local Search是一种基于Entity的回答模式。它结合知识图谱中的结构化数据和输入文档中的非结构化数据，在查询时通过相关实体信息扩展 LLM 上下文。该方法非常适合回答需要理解输入文档中提到的具体实体的问题（例如，“洋甘菊的治疗属性是什么？”）。流程图如下所示： 给定用户查询（或加上对话历史记录），Local Search会从知识图谱中识别出一组与用户输入在语义上相关的实体。这些实体作为进入知识图谱的入口点，能够提取进一步相关的细节,如相连实体、关系、实体协变量（与实体相关的变量）和社区报告。此外，它还从原始输入文档中提取与已识别实体相关的相关文本chunk。然后对这些候选数据源进行优先级排序和过滤，以适应预定义大小的单个上下文窗口，该窗口用于生成对用户查询的响应。

总体架构