Ivorysillegal's Blog

Uthread: switching between threads (moderate) 这个lab的目的是在给定的代码上补充 以和xv6结合 实现线程的上下文切换 假如对代码机理足够熟悉 就可以发现进程上下文切换和线程上下文切换是差不多的 这句话可能有点不严谨 但是其的本质确实是类似的 在xv6中的操作方式也类似 于是这里 可以模仿kernel/swtch.S中的赋值取值 写在uthread_switch.S方法当中 uthread_switch.S 123456789101112131415161718192021222324252627282930313233343536373839404142 .text /* * save the old thread's registers, * restore the new thread's registers. */ .globl thread_switchthread_switch: sd ra, 0(a0) sd sp, 8(a0) ...

Sleep & Wakeup 在实际的使用情况中 我们通过前面所提到的使用锁来保证涉及临界资源时候的不同线程的依次执行 而在其他一些场景中 也会出现不同的线程之间需要交互 或者说是单线程IO等待的情景 课上举的例子包括 假设我们有一个Pipe，并且我正在从Pipe中读数据。但是Pipe当前又没有数据，所以我需要等待一个Pipe非空的事件。 类似的，假设我在读取磁盘，我会告诉磁盘控制器请读取磁盘上的特定块。这或许要花费较长的时间，尤其当磁碟需要旋转时 （通常是毫秒级别），磁盘才能完成读取。而执行读磁盘的进程需要等待读磁盘结束的事件。 类似的，一个Unix进程可以调用wait函数。这个会使得调用进程等待任何一个子进程退出。所以这里父进程有意的在等待另一个进程产生的事件。 而处理这种情况 一种解法是直接通过循环/轮询实现busy-wait 直接暴力读取 但是这样的方法会导致CPU占用急剧升高 在某些情况下 假如知道资源会在什么时候到达 在这样的前提下进行sleep一会 也是一个比较通用的解法 但是还有一种情况是不知道此时的阻塞时长 而在这样的前提下...

Why Do We Need Collectors 收集器组件 这里所讨论的收集器是独立于OpenTelemetry以及服务侧 自己作为一个单独模块运行的“收集器模块” The Benefits of Collectors 什么好处？ 解耦 - 职责分离 - 开发者不需要关心遥测数据生成后的处理流程 将遥测数据的格式等配置 在不修改应用代码的基础上就能修改 同时实现一个集中管理和简化维护工作 而如果不分割开 与SDK一并合并的话 这些配置就会分散在不同的组内 比较混乱 Architecture of a Collector Pipeline 遥测信号处理的过程本质上也是一条责任链（or 流水线） 接收器 接收器是将数据从源头传到OpenTelemetry的方式 包括push和pull两种模式 开箱即用的自带收集器支持TLP 接收器，用于接收 OpenTelemetry 原生格式的追踪、指标和日志 同时这个组件也是可插拔式的 collector-contrib 仓库包含一系列接收器，用于摄取其他采用不同协议编码的遥测数据。例如，有用于追踪的 Zipkin...

L3为基本的docker拉取部署和数据仪表化介绍 不赘述 What is instrumentation? 锚点 是什么玩意？本质上就是在程序的关键运行节点打上遥测数据（日志、追踪、指标三件套） 然后就可以将程序某一部分的运行 清晰的以一个个无状态的形式展现出来 将整个运行流程可视化为一套进行状态迁移的状态机 魂穿os 这些数据提供了应用程序在运行时的行为洞察，帮助开发者监控性能、诊断问题并理解整体系统健康状况。 然而，插桩技术通常高度依赖于所使用的编程语言和框架。这意味着插桩代码往往是专有的，需要针对每个应用的具体工具、库和架构进行定制。因此，开发人员通常需要为他们使用的每种语言或框架实现自定义插桩，这可能导致在系统不同部分之间保持一致性方面面临挑战，尤其是在多语言环境中。 这也意味着，你想从应用程序中提取的信息越具体，你的插桩工作就必须越细致。 意思就是 锚点之类的数据是有点像“侵入式” 虽然不会影响到原来的代码 但是还是会和代码是耦合在一起的 如果需要修改重构的话 也需要在代码层面重新进行加工改造 同时肯定的 这种传统方案也是绑定语言的...

Signal Specification (Language-Agnostic) & Vendor-Agnostic, Language-Specific Instrumentation、 信号规范 语言无关（统一标准的日志信息格式） 定义了不同平台、不同语言间遥测语言数据格式的一致性 此外 定义了统一的API规范与SDK规范（仅提供接口规范 与 提供对应的实现） 而之所以将这 接口和实现分割开 将 API 与 SDK 分离的主要原因是，这使得将原生检测嵌入到开源库代码中变得更加容易。OpenTelemetry 的 API 设计为轻量级且安全可靠。而由 SDK 提供的信号实现则复杂得多，并且可能依赖于其他软件。强制用户依赖这些可能会导致与他们特定的软件栈发生冲突。 Telemetry Processor (Standalone Component) 在通过无耦合的API获取到数据后。Opentelemetry将其管理和摄取到相应的后端。这包括诸如以下任务： gathering data from various sources 从各种来源收集数据 parsing...

新坑 可观测性框架 OpenTelemetry实验课程 Current State 现状 可观测性Observability 名词解释： 通过外部输出信息推断内部状态的能力 即通过系统中的一些锚点信息 推断出当前系统运行的一些状态 而在当前分布式环境的前提下，运行的复杂性提高。纠错的时候，具体的颗粒度会追踪到具体某几个组件的中的某些状态信息。而可观测性的意义就在于出现问题的时候，能够具体聚焦到出错的这些个位置。 而想要实现分布式系统上的可观测性，就需要对他的状态进行建模。根据垂直层次可以分为三个要素： workload 工作负载 系统实际的业务行为，eg:将单个请求分割至多个模块中运行 分割成为多个模块中独自的小任务 software abstractions 软件抽象 构成分布式系统结构的更上层抽象 类似 服务、负载均衡器、网关、Pod一类概念 resources 计算资源 提供计算资源执行工作的物理机器 内存、cpu、磁盘、网络等 在出现排查问题的时候 团队的不同角色会更加关注相关方向上的问题...

评测能力自动化 Warpper 作为通用的评测框架 生产环境中的使用应该是具有普遍性的 其数据可能会具有结构不统一 上下文长度 干预等一些自定义的措施 所以作为一个自建评测框架需要有: 评测集&prompt管理 采用统一格式入库管理评测集及prompt，增加tag和versipn标签，解决数据不统一，接入成本高的问题 预测结果标准化 定义预测base类，限制数据接入格式，统一预测结果输出，便于后续处理。 开放预测服务方法，支持推理服务的定制化接入需求。 评估流程标准化： 采用langchain框架思路，定义chain...

这里或多或少会涉及到RAG 此处会简单介绍 比较详细相关可见此 背景场景1: 知识库 这里所说的RAG是比较狭义且普遍的用法 将原始文档切片后转换成为向量 存储在数据库中 带着input-query查询的时候 来到同一个向量空间 向量化后计算他们的相似度 然后输入LLM生成etc 场景2:function call 使用一段描述性prompt设定模型的能力、背景、人设相关信息，让大模型可以访问数据源，网络搜索等。获取自己拿不到的数据 评测维度这里参考RAG的相关论文设置评测的一些维度和指标 1、噪声鲁棒性（Noise Robustness）模型能从噪声文档中提取有用信息。噪声文档定义为与问题相关但不包含任何相关信息的文档。在与”谁获得了2022年诺贝尔文学奖”问题相关的噪声文档包括有关2021年诺贝尔文学奖的报道。为此，噪声鲁棒性测试根据所需的噪声比，将外部文档包含一定数量噪声文档的实例包含在内。2、否定拒绝（Negative...

这篇输出一些关于RAG的个人理解 引出之后计划的Ragas和相关评测方案分析 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks What?RAG全称 Retrieval-Augmented Generation 即检索增强生成 目前的LLM中存在的主要问题有： 过时知识：不严谨的说 可以将真个LLM看作一个非常高阶的矩阵 矩阵中则是训练时的数据 并且随着时间推移 数据过时 导致模型无法反应最新信息 幻觉：生成不准确或虚构内容 推理过程不透明：训练完毕的模型在进行推理的时候 本质上是一种黑箱的过程 纠错定位难度大 所以在知识密集型（对知识的准确度依赖度高）任务上 不做任何修改或增强的时候效果会比较差 其中一个优化的方法就是RAG 它旨在通过结合外部数据源中的知识 来增强当前信息的可阅读性 也在上方所提到的知识密集型任务中表现尤为突出 （当然了...

本文介绍在实习中接触到的 交通场景下大模型的意图评测 什么是意图本质是讲用户输入的query 在进行规整化 改写等操作之后 高度抽象的 且具有强烈倾向性的问题 换句话来说 就是将用户输入的query改写为大模型更易接受的形式 这一过程需保证不修改用户的问题原意 且改写后询问的效果显著提升（不然改写就没有意义了） 这一效果可以体现在回答的内容倾向性、回答的格式、自然语言的风格等多个方面 那么 意图识别的难点在于？ 输入不规范、输入形式多样化：使用自然语言查询，甚至非标准的自然语言。比如上面提到的“附近的特价酒店” 、“上海到扬州高速怎么走”都是自然语言查询的例子，又如 “披星 ( ) 月”、“吾尝终日而思矣, 下面“ 查询词表现出多意图：单个词在不同领域有多个意思 此时意图无法准确识别到用户的需求 eg:mac是指macbook还是mac地址 意图强度：和上一点类似 同义词表现出多个意图 且在此基础上不同用户的需求不一样 此时需要根据上下文和所有搜索数据进行综合判断 存在时效性变化：随时间推移某些词的意图强度存在变化...