Daily Study

更新: 5/15/2025 字数: 0 字 时长: 0 分钟

Daily Plan

#todo

• 写博客
• 准备面试 ✅ 2025-05-13
  • 八股 ✅ 2025-05-13
  • 面试问题
  • 代码
• go中unsafe.Pointer ✅ 2025-05-12

面试问题准备

#暑期实习

排查Linux服务器卡顿

1. 查看系统资源使用情况：使用top或htop命令查看系统负载、CPU使用率、内存使用率以及磁盘I/O等情况，确定是否是资源占用过高导致卡顿。

2. 检查进程和服务：使用ps或top命令查看当前运行的进程和后台服务，排查是否有异常进程或服务占用资源过高。

3. 检查磁盘空间：使用df命令检查磁盘空间使用情况，确保磁盘空间充足，避免导致系统卡顿。

4. 检查网络连接：使用netstat命令查看网络连接情况，检查是否有异常连接或网络流量过大导致卡顿。

5. 检查日志文件：查看系统日志文件，如/var/log/messages，/var/log/syslog等，排查是否有错误日志或异常信息。

6. 检查硬件问题：查看硬件设备是否正常运行，如CPU、内存、硬盘以及网卡等，排除硬件故障引起的卡顿。

7. 检查应用程序：检查运行的应用程序，确定是否存在程序bug或者配置问题导致卡顿。

对网络空间的理解

网络空间安全是指通过技术、管理和法律等手段，保护网络空间中的信息、系统及其基础设施，防止其受到非法侵入、破坏和滥用，确保网络空间的稳定和可靠运行。网络空间安全涵盖多个领域，包括数据安全、系统安全、应用安全、网络安全和物理安全等

试过什么模型，对比

一开始用的baichuan2-7b，中文的支持尤为出色，使用FP16半精度运算该模型的显存资源占用较小，为23GB，使其在资源受限的环境下仍能高效运行。 后面用qwen2.5-14b，显存39GB。参数更多，支持处理的上下文长度更多，理解能力更强。

项目中主要的难点和关键技术

难点：分为系统层面和大模型层面

1. 大模型层面中主要的难点在模型的微调上，这里主要使用了Lora进行指令监督微调，关键技术涉及到Lora中参数选择和训练的策略。使用渐进式训练策略，先用1k数据训练1epoch，用来验证loss，快速验证数据-模型匹配度。中数据的rank一般为16-32，这里选择16，α严格为r的2倍，避免比例失调造成过拟合。参照【实战】LoRA 微调数据量需求评估 具体来说：分为三种策略：
   • 数据增强：使用了GPT生产来扩充场景样本
   • 分层训练：分为两个阶段。大部分数据做领域适配，学习率为3e^-5和任务精调（剩下的数据），学习率为1e^-5。
   • 定义了动态调参规则，主要根据验证指标和梯度的变化来调整。
2. 系统层面包括两部分
   • 第一部分是告警过滤和告警研判的交互，主要体现在告警聚合中相应字段的设计，具体来说，首先对于多种网络告警设备的日志，进行标准化为六元组，然后针对日志信息进行过滤和聚合后，聚合后的告警，不仅包括告警的特征信息，还增添了相应的评分字段，从为后面的研判服务。
   • 第二部分是多维度研判的设计，包括信息熵研判、自定义规则研判和大模型语义研判三部分构成，需要设置三部分的研判评分规则和权重。这里的关键技术是使用持续运营反馈和历史数据来校准，同时加入人工审核和反馈机制形成反馈闭环。

不同的微调策略对比

参考大模型微调笔记：对比LoRA、QLoRA、AdaLoRA、LoRA+-CSDN博客

不同的Agent框架对比

框架​​	​​核心架构​​	​​数据流模型​​	​​典型拓扑结构​​
​​LangChain​​	链式结构 (DAG)	线性/分支流程	顺序执行链
​​LangGraph​​	图结构 (StateGraph)	动态循环/条件分支	带反馈环的复杂图
​​AutoGen​​	多智能体对话模型	智能体间消息传递	混合倡议交互网络
​​Eino​​	组件化图编排	类型化数据流	字段映射工作流
LlamaIndex	数据流主导	索引构建与检索	医疗知识库的智能问答系统

• LangChain强调​​模块化组合​​，适合快速搭建标准化流程
• LangGraph通过​​状态驱动​​实现动态流程控制，支持循环迭代
• AutoGen构建​​多智能体协作生态​​，强调对话交互的自然性
• Eino基于GO的大模型应用开发框架，​​除了组件和编排外，还具有完善的流处理​​，擅长复杂数据转换与并发管理
• LlamaIndex解决LLM与私有数据的高效连接问题，更好的与RAG关联

Mysql发生死锁的场景

发生死锁满足的四个必要条件：

• 互斥
• 请求与保持
• 不可剥夺
• 循环等待

典型场景：

• update 全表没有加索引，没有索引的全表扫描，会导致每行加锁，发生冲突导致死锁
• 交叉更新不同的表，事务1持有orders锁等待payments锁，事务2反之

-- 事务1
BEGIN;
UPDATE orders SET status='paid' WHERE id=100;
UPDATE payments SET amount=100 WHERE order_id=100;

-- 事务2
BEGIN;
UPDATE payments SET amount=200 WHERE order_id=100;
UPDATE orders SET status='completed' WHERE id=100;

检测方法：

• 等待图（Wait-for Graph）​：InnoDB 定期扫描事务锁依赖关系，检测是否存在环路
• ​日志分析​：通过 SHOW ENGINE INNODB STATUS 查看 LATEST DETECTED DEADLOCK 信息

数据库三大范式

• 第一范式（1NF）要求数据库表中的每个列都是不可再分的原子值，即每个列都不能包含多个值或值的列表。
• 第二范式（2NF）要求数据库表中的非主键列必须完全依赖于所有主键而非部分主键。换句话说，每个非主键列必须与整个主键相关，而不是只与主键的某个部分相关。
• 第三范式（3NF）要求数据库表中的非主键列之间不能存在传递依赖关系。换句话说，非主键列之间不能相互依赖，而应该直接依赖于主键。