Transformer架构详解
为什么现在主流大模型用的都是transformer架构？ 2017年提出的原始transformer架构 他与我们接下来所要学习的现代大模型架构是有一定出入的。 首先，原始transformer使用编码器-解码器架构，而现代大语言模型使用解码器结构。这是因为编码器负责理解，解码器负责生成 天然适合生成： GPT 不使用编码器，主要是因为它的核心任务是自回归生成，也就是根据前面的 token 预测下一个 token。这个任务天然适合 Decoder-only 架构。 训练目标统一： Decoder-only 目标简单，预测下一个token，不像Encoder-Decoder那样要分阶段、分任务，目标越统一，训练越稳定。 易扩展： Decoder-only模型只要在prompt里面多写几句例子，就能快速适应迁移任务。 然后，每个transformer块的结构也不同，原始transformer中是post-norm,而现代大模型是pre-norm 原始 Transformer 用 Post-Norm，是因为当时模型比较浅，只有 6 层 Encoder、6 层 Decoder，Post-...
ThemeKG在构建数据库参数信息这个特定主题的知识图谱上的启发
直接将原始语料输入给LLM进行知识图谱构建的话，还是会因为幻觉产生不准确的实体，以及模糊或者错误关系。《LLMs for Knowledge Graph Construction and Reasoning: Recent Capabilities and Future Opportunities》中指出LLM更适合作为推理工具而不是少样本信息抽取器。 借鉴《Automated Construction of Theme-specific Knowledge Graphs》的思路，可以先定义好参数的顶层骨架，或者说是实体的类型层，比如： InnoDBParameter OptimizerParameter BinlogParameter MemoryParameter IOParameter ThreadParameter 上面这些是参数的子类别，接下来将资源，硬件，指标等也进行实体定义 Metric WorkloadPattern Resource StorageEngine Version Symptom TuningGoal Risk 将实体类别定义好之后，再让模型从文...
知识图谱入门
Neo4j 1. 什么是Neo4j Neo4j是一个基于图形数据库的开源项目，专门用于存储和查询图形数据。它使用图形结构来表示数据，其中节点表示实体，边表示实体之间的关系。这种结构使得Neo4j非常适合处理复杂的关系数据，如社交网络、推荐系统和知识图谱等。 2. Neo4j的存储方式 Neo4j使用节点，关系，属性来存储数据。 节点（Node）： 表示图中的实体，并由标签标记。每个节点可以有一个或多个标签，标签用于分类节点。例如，图中节点标签为"person"和"actor" 节点可以有属性，属性是键值对，用于存储节点的具体信息。例如，一个人的节点可能有属性“name”和“born”。 被索引并受约束 关系（Relationship）： 提供两个节点间的命名链接，必须有起始节点和结束节点。 关系也可以有属性，用于存储关系的具体信息。例如，一个“WORKS_FOR”关系可能有属性“since”，表示某人从什么时候开始在某公司工作。 必须有方向 节点可以拥有多种类型的多个关系。 属性（Property）： 属性是键值对，...
D-Bot：基于LLM的数据库诊断系统
背景 数据库异常种类繁多，不可能用预定义的规则全面覆盖，往往依靠DBA的专业知识进行逐步分析。然而，人类DBA和令人望而生畏的异常问题之间存在巨大差距。 培训一个DBA需要大量的时间， 几乎不可能雇用足够的DBA来管理海量的数据库实例 在紧急情况下，DBA分析问题可能需要较长时间，在这期间会造成巨大的经济损失。 基于此，现在的数据库系统配备了半自动化工具，但是这些工具大多是（1.经验规则和小模型能力太窄)基于经验规则或者小型ML模型进行的，(2.泛化能力差)这些方法不能灵活地应用到变化的场景中。对于经验规则来说，重新根据新文档变换经验规则是很繁琐的，而ML模型需要重新设计输入指标和标签，并针对新场景重新训练模型。（3.缺乏像 DBA 一样的推理和交互能力）真实诊断需要递归地查看不同系统视图、结合工具结果调整下一步动作，而传统方法做不到这种“边诊断边探索”的过程。 因此，作者希望构建出具有以下三个特点的数据库系统： 精确诊断，可以制定诊断计划来准确地找到该优化的参数 节省费用和时间 通用性强，可以自己学习给定的文档，灵活分析未见的异常 即能够读文档学知识、知道当前该调用什么...
自动模式设计综述
《Self-tuning Database Systems: A Systematic Literature Review of Automatic Database Schema Design and Tuning》 探索 SQL 和 NoSQL 数据库自动化模式调优方法的实质性工作，也是首个提出用于评估和比较不同模式调优解决方案的分类体系的工作。本综述有助于探讨当前解决方案的动机与能力之间的差距，并据此确定未来的研究方向。通俗点来讲就是探究数据库内部数据结构设计的自动化方法，使其跑得更快，效果更好。 关系型数据库自动化模式设计 关系型数据库的自动化模式设计主要侧重于物理模型设计。 物理结构设计包括： 辅助加速对象：索引、物化视图 底层数据组织对象：在多维关系型数据库中使用的聚簇键，在无共享并行数据库系统中使用的分区键。 自动化物理设计通常三步走： 生成可能的备选方案 评估备选方案 选择代价最低的最佳方案 基于上述流程，研究人员将自动化物理设计拆解为两个最核心的技术维度： 代价模型 (Cost Model)：它是系统的“评估裁判” 。主要负责评估所有备选设计，并估算出...
LLMOpt——《A Query Optimization Method Utilizing Large Language Models》
背景 查询优化是数据库的关键任务，需要在海量策略中找到最高效的执行计划 。但传统方法依赖启发式搜索和代价预测，往往因为搜索空间太复杂或性能估计不准，导致选出来的计划不是最优的。 下图展示了传统查询优化器“先搜后选”的pipeline: Candidate Searching: 对于n个表的查询，会产生$O(n!)$的复杂度，传统数据库采用动态规划或启发式算法来剪枝搜索空间。如图所示，可以向 DBMS 施加外部的“限制”以影响搜索过程。例如，一些方法会调整特定的数据库控制参数（Knobs），来启用或禁用特定的连接（Join）或扫描（Scan）操作，从而迫使优化器生成不同的候选计划集合。 容易出现的情况是，优化器在搜索过程中可能会错过一些潜在的高效计划，或者由于代价模型的不准确而选择了一个次优计划。这些问题导致了查询性能的下降，尤其是在复杂查询或大规模数据集上。即搜不全 Candidate Selection: 候选计划的结构和数值细节（例如表和过滤条件之间的关联方式，或特定的节点类型）会被编码为特征。图中的“代价模型”会评估这些特征，以近似计算查询执行所需的时间。传统的代价模型依...
参数调优《GPTune》
当前的调优系统通常利用贝叶斯优化（BO）或强化学习（RL）通过试错来探索空间 。然而，这些方法依然会产生高昂的调优成本，通常需要数百到数千次耗时的迭代才能找到理想配置 。 难点 1：参数太多。现有方法要么选择固定的参数子集，牺牲了灵活性；要么需要极其消耗资源的大量运行来识别重要参数 。 难点 2：搜索空间太大。现有方法大多直接使用 DBMS 供应商提供的默认值域，这些值域过于宽泛，不仅使调优过程复杂化，还引入了系统崩溃的风险。 挑战一（C1）：很难在平衡成本与质量的前提下，将异构的自然语言知识统一为机器可读的结构化视图。现有的数据提取和清理工作流复杂且难以满足需求 。 挑战二（C2）：即使有了结构化知识，BO 和 RL 等标准优化算法在设计上并不支持直接集成外部领域知识。而单纯人工提取的静态规则又无法适应多变的工作负载环境 。 GPTUNER 的创新设计： 解决 C1：针对 LLM 容易产生幻觉的脆弱特性，设计了一个包含双重纠错机制的 LLM 管道。该管道涵盖数据摄取、基于 LLM 的数据清洗过滤、冲突处理集成以及事实一致性校对。 解决 C2：在调优前利用 LLM 的文本分析能力...
参数调优《AgentTune》
概述 现有方法通常需要数百次工作负载重放或依赖海量训练数据，导致调优效率低下或准备成本高昂。此外，这些方法还面临生成无效配置的风险，可能导致性能下降甚至数据库崩溃。 调优效率低。基于机器学习（ML）的方法,通常需要数百次迭代才能收敛到理想的配置。每次迭代都涉及在数据库管理系统（DBMS）上执行工作负载（即工作负载重放），导致调优过程可能持续数小时。尽管大语言模型（LLM）辅助的方法实现了更快的收敛，但它们仍受限于基于机器学习的参数调优器固有的低效性。 可靠性低。尽管基于机器学习（ML）的调优通过平衡探索与利用来避免局部最优解，但它经常产生无效配置——即那些导致性能低于默认水平甚至使数据库管理系统（DBMS）崩溃的配置。同样，初步研究表明，直接使用大语言模型（LLMs）进行参数推荐可能会导致不安全的值（例如，过小的缓冲池大小），这源于幻觉和有限的数值推理能力等问题。这些问题可能导致调优过程中的资源耗尽或系统不稳定。 准备工作耗费大量资源。为了提高效率，许多基于机器学习（ML）和大型语言模型（LLM）的方法利用历史调优数据进行模型初始化、缩小配置空间或微调端到端参数调优器。然而，收...
AI4DB综述
本文是对《AI-Driven autonomous database management: Self-tuning, predictive query optimization, and intelligent indexing in enterprise it environments》这篇论文的研读总结。该论文详细介绍了AI在自治数据库管理中的基础知识和应用，重点关注了自调优机制、预测性查询优化和智能索引技术等方面。 自调优机制。self-tuning mechanisms 利用 AI 分析工作负载、优化资源分配并动态调整系统参数，以保持峰值效率。 预测性查询优化。predictive query optimization 利用深度学习算法来增强查询执行计划、降低延迟，并在性能问题影响业务运营之前对其进行预判。 智能索引技术。intelligent indexing techniques 应用机器学习技术来自动化索引的选择、适配和维护，确保最佳的数据检索并缩短查询处理时间。通过整合这些 AI 驱动的机制，企业可以实现更高的运营效率、提高数据库可靠性，并减少性能调优中的人工...
openclaw在安装和应用上的笔记
安装 首先需要安装Node.js 22+ 然后使用npm安装openclaw： 1npm i -g openclaw@latest 然后使用以下命令快速配置： 1openclaw onboard 之后每次使用输入以下命令 1openclaw dashboard 安装问题一 登录网页后显示404，说明gateway没有正确启动，可能是端口被占用或者权限问题. 首先查看有没有这个文件 1dir "$env:USERPROFILE\.openclaw\gateway.cmd" 如果没有，说明安装过程中可能出现了问题，可以尝试重新安装openclaw。如果有这个文件，尝试手动运行它，看看是否有错误提示。 安装问题二 打开页面后，显示: 12⚠️ Agent failed before reply: No API key found for provider "openai-codex". Auth store: C:\Users\86182.openclaw\agents\main\agent\auth-profiles.json (agentDi...