fix

_posts/Kubernetes/Container/2016-12-02-docker_cgroup_namespace.md

@@ -118,6 +118,12 @@ static struct task_struct *copy_process(...){
 
 ### mount namespace
 
+[linux内核中根文件系统的初始化及init程序的运行](https://mp.weixin.qq.com/s/adoQPvWNR1sBwOytjtzoFg)我们在和vfs打交道时，为其提供的最主要的信息就是文件路径，而文件路径有两种格式，一种是绝对路径，即从根目录开始查找文件，一种是相对路径，即从当前目录查找文件。所以，vfs如果想要解析我们提供的路径，就必须还要知道一个信息，即我们当前的根目录和当前目录指向哪里。那这些信息存放在哪里了呢？我们和操作系统交互的方式是通过程序，或者更确切的说，是通过进程，所以当我们要求vfs帮我们解析一个路径时，其实是这个进程在要求vfs解析这个路径，所以vfs获取的根目录或当前目录，其实就是这个进程所属的根目录或当前目录。所以，存放根目录及当前目录的最好位置，就是在进程里。而且，在进程内，我们是可以通过 chdir 这个系统调用来修改当前目录的，也就是说，每个进程都有自己独有的当前目录，这就更说明，根目录和当前目录信息，只能存放在进程里。到这里有些同学可能会有疑问，当前目录存放在进程里比较好理解，但**根目录应该是所有进程共用的吧，为什么也要存放在进程里呢？**这是因为，不仅进程所属的当前目录是可以修改的，进程所属的根目录也是可以修改的，修改的方式就是通过 chroot 这个系统调用。根目录和当前目录，存放在进程的具体位置为：
+
+![](/public/upload/kubernetes/linux_task_fs.jpg)
+
+current指向的是当前进程，进程对应的结构体是struct task_struct，在这个结构体里，有一个fs字段，它又指向struct fs_struct结构体，而在struct fs_struct结构体里面，则存放了当前进程所属的根目录及当前目录，即root和pwd字段。那有了这两个字段，vfs就可以解析我们提供的文件路径，进而找到对应的文件数据了。
+
 ![](/public/upload/linux/pid_namespace.png)
 
 mount 也是有树的，每个namespace 理解的根 不一样, 挂载点目录彼此看不到. task_struct  ==> nsproxy 包括 mnt_namespace。

_posts/MachineLearning/Infra/2022-01-13-distributed_training.md

@@ -281,6 +281,12 @@ struct ncclComm {
 
 ## 资源调度
 
+在千卡集群下训练的难点分为两方面，AI Infra 和 Training Framework。
+1. AI Infra 方面：千卡训练多久挂一次，挂了之后咋弄，有效训练时间是多长。
+  1. 网络通信训练中断 trade off Checkpoint；掉卡，会预留一部分GPU当作 Backup；存储挂载异常。网络、GPU和存储这三方面的问题都会导致训练中断或者出现异常，所以需要结合 K8S 那一套整个自动监控系统，然后自动剔除异常节点等等一些操作。
+2. 对于 Training Framework 方面，可以做的就是怎么更快更节省的训练大模型：提升大模型训练的速度和降低训练大模型需要的GPU个数。要么较少的卡久一点能把模型训起来，或者让训练加速（像 FlashAttention2），比如提前个 10 天训完。
+3. 还有一点很重要的是 Dataset，模型训练参数上来之后，数据量（Token 量）也得跟上才行。
+
 Kubernetes 设计之初目标支撑的主要场景是无状态类工作负载（比如 Web 应用和微服务），后来随着系统稳定性和存储卷管理能力的增强，很多有状态类负载也被跑在 Kubernetes 上，比如数据库、分布式中间件等。到这里，Kubernetes 的核心架构都还没有碰到特别大的挑战。明显的变化发生在 AI 时代，尤其以深度学习为代表的 AI 任务，与以 Spark 批和 Flink 流为代表的大数据处理任务，被大家尝试运行在 Kubernetes 集群上。而在 GPU 管理和推理方面，大家首先要面对的也是最大的一个问题，就是调度和资源管理。
 1. 在资源调度方面，Kubernetes 需要能够针对各类异构设备的体系结构、软硬件协同手段和设备间的约束（共享、隔离、连接等），通过资源调度，最大化集群整体资源利用率。
 2. 任务级调度方面，Kubernetes 需要能够从面向单个 Pod 的调度，扩展到面向一组 Pods 的调度，满足 Pods 间的各种依赖、关联和约束，提升任务整体效率。Scheduler-framework 架构，就是 Kubernetes 调度管理 AI 任务的关键改进之一。本质上，需要 Kubernetes 能够高效支撑一个大规模的任务系统。从架构上，除了调度器（batch scheduler）和任务对象的生命周期控制器（job controller），还缺少重要的一个组件——任务队列（job queue）。

_posts/MachineLearning/LLM/2023-09-25-llm_retrieval.md

@@ -77,7 +77,7 @@ LLM 擅长于一般的语言理解与推理，而不是某个具体的知识点
 
 ![](/public/upload/machine/rag_key_index.jpg)
 
-### 文档处理
+### 文档处理/非结构化数据结构化
 
 如何将文档拆分为文本片段。主要有两种，一种就是基于策略规则，另外一种是基于算法模型。
 1. 如何保证文档切片不会造成相关内容的丢失？一般而言，文本分割如果按照字符长度进行分割，这是最简单的方式，但会带来很多问题。例如，如果文本是一段代码，一个函数被分割到两段之后就成了没有意义的字符。因此，我们也通常会使用特定的分隔符进行切分，如句号，换行符，问号等。可以使用专门的模型去切分文本，尽量保证一个chunk的语义是完整的，且长度不会超过限制。
@@ -99,7 +99,7 @@ LLM 擅长于一般的语言理解与推理，而不是某个具体的知识点
     3. NLP的研究中本来就有关键词提取工作（Keyphrase Extraction）。一个工具是 HanLP ，中文效果好，但是付费，免费版调用次数有限。还有一个开源工具是KeyBERT，英文效果好，但是中文效果差。
     4. 垂直领域建议的方法。以上两个方法在垂直领域都有准确度低的缺陷，垂直领域可以仿照ChatLaw的做法，即：训练一个生成关键词的模型。ChatLaw就是训练了一个KeyLLM。
 3. 对关键信息做embedding
-4. 问题查询时，先query 向量检索到关键信息，再由关键信息找到段落文本
+4. 问题查询时，先query 向量检索到关键信息，再由关键信息找到段落文本/small to big。PS：切碎是不可避免了，但在生成阶段可以避免 llm用碎片化的chunk来回答问题。
 
 [LangChain+LLM大模型问答能力搭建与思考](https://zhuanlan.zhihu.com/p/644740531)一般通用分段方式，是在固定max_length的基础上，对出现`。/；/？/....../\n`等等地方进行切割。但这种方式显然比较武断，面对特殊情况需要进一步优化。比如`1.xxx, 2.xxx, ..., 10.xxx`超长内容的情况，直接按这种方法切割就会导致潜在的内容遗漏。对于这种候选语料”内聚性“很强的情况，容易想到，我们**要么在切割语料时动手脚**（不把连续数字符号所引领的多段文本切开）；**要么在切割时照常切割、但在召回时动手脚**（若命中了带连续数字符号的这种长文本的开头，那么就一并把后面连续数字符号引领的多段文本一起召回）。笔者目前只想到了这两种方法且还没具体做实验，只是凭空想来，前者方案有较明显瑕疵，因为这样会
 
@@ -118,7 +118,7 @@ LLM 擅长于一般的语言理解与推理，而不是某个具体的知识点
 |--|--|--|--|--|--|
 |1|	文本原始段落|	文本摘要|	来源文件|	文本元素类别（主要用于区分图片和文本）|	图片存储位置（在回答中返回这个位置，前端进行渲染）|
 
-### 文档召回
+### 文档召回/大海捞阵
 
 查询本身可能并未提供足够的信息来指导模型找到最相关的文本块，而是需要更多的信息和逻辑推理，于是修改用户输入以改善检索。文档召回过程中如何保证召回内容跟问题是相关的？ 或者说，如何尽可能减少无关信息？  召回数据相关性的影响方面很多，既包括文档的切分，也包括文档query输入的清晰度，因此现在也出现了从多query、多召回策略以及排序修正等多个方案。
 

_posts/MachineLearning/LLM/2023-10-29-llm_finetune.md

@@ -259,6 +259,8 @@ Prompt Tuning 可以看作是 Prefix Tuning 的简化版本，它给每个任务
 
 [NEFT：新的指令微调技术大幅提升大模型性能（LLaMA系增加NEFT性能提升约10%）](https://mp.weixin.qq.com/s/47Gg5FRihnX3w7UqW7lCqQ)
 
+[克服微调垂类领域模型导致的通用领域知识遗忘的好方法——llama_pro](https://mp.weixin.qq.com/s/5V3sw0yvjfQ36XR1DO1PWA)
+
 ## 代码
 
 ### 手写
@@ -420,4 +422,8 @@ PS: 深度学习都得指定features/labels。在llm 场景下，features 和lab
 ## 微调实践
 
 1. 合适的损失曲线：训练过程中可能会有波动，但整体是呈现一个下降的趋势，一般模型微调后，最终的训练集损失降低到1以下是合适的，特别低可能会过拟合，但一般使用特定领域知识做微调的话，建议往先过拟合靠拢，优先保证模型能精准回答知识库中的内容。
-2. 无规律波动且不收敛：一般是learningRate太大导致，无法呈现稳定的下降趋势，如果训练中出现这个趋势持续到3~5轮，可以提前关闭训练任务，尝试将学习率learningRate降低一个数量级。
+2. 无规律波动且不收敛：一般是learningRate太大导致，无法呈现稳定的下降趋势，如果训练中出现这个趋势持续到3~5轮，可以提前关闭训练任务，尝试将学习率learningRate降低一个数量级。
+[LLM is not all you need（大模型领域知识微调实践）](https://zhuanlan.zhihu.com/p/689800667)
+3. 为什么要用SFT （指令微调）而不用RLHF？RLHF的loss主要在优化LLM输出特定分布（风格）的内容，而笔者想要的是让LLM看到某个问题输出非常精确的答案。那能不能用RL来做基于标签反馈的优化呢？这里边有一个很大的问题是目标token序列非常少，这涉及到稀疏空间中的RL优化问题，比较棘手，不如用SFT来得直接有效，而且SFT对于格式输出的学习几乎是无可挑剔的。
+4. 指令微调是全参数微调还是PEFT？首先说PEFT吧，有Lora，P-tuning等很多种。笔者一直用Lora，虽然这些方法各有千秋，但当任务很难时性能差异不是很大。其次说全参数微调，笔者用PEFT微调发现效果比较差之后就采用了全参数微调，但是提升不是很显著（需要的是20+或者30+个点的提升，而不是个位数的提升）。
+5. 能不能将领域知识以continue training的形式注入LLM？尝试过，几乎没有提升。主要是用来continue training的数据不是非常多。所以对SFT没有加成。