问题

最近要上一个用到 clickhouse 的服务，我没有这方面经验，之前仅仅在部署 langfuse 时遇到过，但是也只是跟着 chatgpt 设置了一些表的 ttl。所以这次还是高度依赖 chatgpt 帮我设计表、写初步代码、部署和进行其他优化讨论。

刚开始进行挺顺利，帮我简单入门了下 clickhouse，经过一系列讨论，写了 sql 和插入查询代码。终于该部署了。我在本地测试时这一步也很顺利，然后在发布到线上后，容器死活起不来，一直在 restarting，通过日志可以看到如下错误（我手动进行了 wrap 以更方便查看）：

1
2
3
4
5
6

{} <Error> Application: Caught exception while loading metadata:
Code: 722. DB::Exception: Waited job failed: Code: 695.
DB::Exception: Load job 'load table system.latency_log' failed:
Code: 74. DB::ErrnoException: Cannot read from file 28: ,
errno: 1, strerror: Operation not permitted: Cannot attach table
system.latency_log from metadata file ...

后面还有很长我就不贴了，看起来像是 sql 语句。

啰嗦的 chatgpt

没经验的我第一眼看起来像是权限问题，可能是挂载的目录权限有问题，问了 chatgpt 5.4 thinking，也说是这个问题：

后面给我的详细原因也是这个：

解决方案也是删除挂载目录，重新来：

我现在本地复现，复现不了。然后我尝试按照它提供的方向进行调试。我当前的持久化方式是显式挂载到本地目录，类似这样：

1
2

volumes:
  - ./data/clickhouse:/var/lib/clickhouse

于是我进行了如下尝试：

1. 挂载到 docker 管理的 volume：

   1 2 3 4 5 6 7 8

   services: ... volumes: - clickhouse_data:/var/lib/clickhouse ... volumes: clickhouse_data:

   这样数据完全由 docker 管理，而且也是全新的 volume，应该不会再存在权限问题。

2. 删除该目录。

3. 不再挂载该目录。

以上均无效，仍然报之前的错误。由于我无法登录线上机器，所以哪怕查看 docker 日志这么小的操作也是比较麻烦。再加上其中各种问题，其中还需要找运维帮忙，以及过程中和 chatgpt 的多次交流，昨天一下午都在搞这个事情。

当我尝试完 1 无效后，去把结果丢给 chatgpt，它认为可能是我指定的那个 volume 是一个旧的 volume，里面有残存数据；或者 clickhouse 镜像版本太高；或者镜像的 seccomp 触发了容器内文件异步读取的 Operation not permitted ，由此它推荐我进行如下操作：

从事后诸葛亮来看，其实它在这里已经提到了正确的解决方案：就是这里的 3。只是到这里，我的耐心已经被消耗大半，它的回复每次又非常啰嗦（尽管我已经在个性化中对此进行了限制，比之前有好转，但是仍然不够精炼），导致我没有再进行测试的耐心了。而且由于我无法登录线上机器，所以 1 我实现不了，要实现就得找运维，又得来回好一会儿。对于 2，那也很麻烦，降级就意味着要下载新镜像，还要再推送到我们自己的仓库中，改 compose 文件，鉴于我们的网速和这个流程，我也就放弃了。而且我也不赞成 1 和 2 是潜在的原因。这就导致正确方案被我忽略了，我已经没有耐心听它的意见了。

接下来更是偏离了方向。由于我在配置中禁用了很多系统表，所以我问它是不是这些配置导致的。它回答有可能：

然后建议我先不要挂载配置。我接着问它有无可能是我的挂载方式覆盖了原本的配置导致的：

我对这个完全不懂，所以才会怀疑是不是覆盖了配置文件。然后我又对这个挂载方式进行了一些调试，无果。事后证明这个目录就是用来存放额外的配置的，默认是空的，所以不存在我怀疑的这个问题。理想情况是此时 chatgpt 应该要指出来这点，直接告诉我这个不是原因。

现在来看上面这些，就让我想到了 llm 的“大海捞针” The Needle In a Haystack 测试，这就像 llm 反过来测试我的大海捞针能力一样，测试我能不能在一堆啰嗦的废话中找到那个 needle。关于废话这点，5.3 instant 说是有所改进，当初我的测试也是似乎比之前好点，不过这个改进是不是没用到 5.4 上啊：

5.3 instant 的改进

然后这个问题我就先搁置了，交给运维，我先下班了，被这玩意儿折腾得不行。哦对了，我后来还想到这个大海捞针的问题，担心 context 可能太大了，模型性能下降了。所以我又开了一个新会话，把报错、当前的 compose 文件、当前的 clickhouse 配置文件给它：

回答的一部分

相对来说要比之前的好点，但是之前那个啰嗦的问题仍在。它的这种表达方式和我当时的心情，成功让我错过了正确方案。

精准的 claude

第二天上班后，我想着用 claude 试一试，虽然我没有 opus 可用，sonnet 试试也可以。于是我把相同的内容发给 sonnet 4.6，结果一针见血，直击要害：

修复 2 无效，1 是正确方案。简明扼要，直击要害。sonnet 4.6 完美诠释了这点。要不是 anthropic 封号和 ip 封的厉害，我也很想开他们家会员。

结语

不过回过头来，chatgpt 大部分时间还是不错的。虽然看起来我是在表扬 sonnet 批评 chatgpt，但是我最后想说的是，当你被一个 bot 气得不行的时候，不要着急，歇一歇，换另一个 bot 试试，众人拾柴火焰高，在座的各位都发表发表意见，头脑风暴一下，说不定解决方案就来了。

但总之，说话不要太啰嗦！

END

上一篇重点讲了什么是 mcp、为何使用 mcp 以及如何使用。本来想把概念一起都写到那里，但是觉得太长了，干脆就把概念介绍放到了这里。

核心概念 plus

Transport 类型

刚才我们在 demo 里用的是 transport="streamable-http" ，实际上 transport 有 3 种类型：

• stdio（默认）
• sse
• streamable-http

第一种是命令行启动 server 程序（不是 http），比如 uv --directory /ABSOLUTE/PATH/TO/PARENT/FOLDER/get_current_time run get_current_time.py ，实际上就是直接运行 python 程序。你填入 inspector 或者 postman 的时候就是填入启动命令。

后两种都是 http 形式的，最终会暴露出来一个 url 来提供调用，sse 默认的端点是 /sse ，streamable-http 默认是 /mcp ，而且根据文档，后者已经在逐渐替换前者了，所以建议使用后者进行开发。两者区别如下：

Tools

如果用过 openai 的 function calling，那么应该对这个很熟了，本质上就是将函数定义以一定格式传给模型。

工具由如下结构定义：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

{
  name: string;          // 工具的唯一标识符
  description?: string;  // 易读的工具描述
  inputSchema: {         // 工具参数的 JSON schema
    type: "object",
    properties: { ... }  // 工具参数
  },
  annotations?: {        // 可选，关于工具行为的注释
    title?: string;      // 易读的工具标题
    readOnlyHint?: boolean;    // 如果 true，那么工具不会改变其环境（只读）。
    destructiveHint?: boolean; // 如果 true，那么工具可能会执行破坏性的更新。
    idempotentHint?: boolean;  // 如果 true，那么对该工具使用同样参数重复调用，不会有额外影响。
    openWorldHint?: boolean;   // 如果 true，那么工具可能会与外部实体交互。
  }
}

这么说可能有点抽象，我们来看下刚才的 get_current_time 工具的定义：

1
2
3
4
5
6
7
8
9
10
11
12
13

{
  "tools": [
    {
      "name": "get_current_time",
      "description": "\n    Returns the current date and time in the 'Asia/Shanghai' timezone.\n\n    Returns:\n        datetime: The current datetime object localized to 'Asia/Shanghai' timezone.\n    ",
      "inputSchema": {
        "type": "object",
        "properties": {},
        "title": "get_current_timeArguments"
      }
    }
  ]
}

其他还有执行系统命令和调用 api 的工具等例子，可以参考这里。

我们在使用调试工具连接 mcp server 后，会自动发起 ListToolsRequest 请求来获取可用的工具：

Resources

资源就是 server 希望提供给 client 的数据，包括文本数据和二进制数据：

• 文本数据：utf-8 编码的文本数据，例如代码、日志、JSON 和纯文本等。
• 二进制数据：PDF、图像、音频和视频等。

每个资源都有一个唯一标识 URI，格式为 [protocol]://[host]/[path]，比如我们常见的 pg 数据库可以标识为 postgres://database/customers/schema ，文件可以标识为 file:///home/user/documents/report.pdf 。另外 server 也可以定义自己的 URI 格式。

server 在返回资源列表时，每个资源一般使用如下格式返回：

1
2
3
4
5
6

{
  uri: string;           // 资源 URI
  name: string;          // 人类可读的名字
  description?: string;  // 可选，资源描述，这个会提供给 llm，使其更好的理解该资源。
  mimeType?: string;     // 可选，MIME type，如v text/plain
}

如果一个资源的 URI 是动态的，那么上述 uri 字段可以换成 uriTemplate ，其格式遵循 RFC 6570。

client 可以通过 resources/read 来读取可用的资源，server 返回资源列表。另外在资源更新时 server 也可以通知 client，具体可以见 Resource updates。

一个实现例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

app = Server("example-server")

@app.list_resources()
async def list_resources() -> list[types.Resource]:
    return [
        types.Resource(
            uri="file:///logs/app.log",
            name="Application Logs",
            mimeType="text/plain"
        )
    ]

@app.read_resource()
async def read_resource(uri: AnyUrl) -> str:
    if str(uri) == "file:///logs/app.log":
        log_contents = await read_log_file()
        return log_contents

    raise ValueError("Resource not found")

# Start server
async with stdio_server() as streams:
    await app.run(
        streams[0],
        streams[1],
        app.create_initialization_options()
    )

Prompts

在 mcp 中，prompts 其实指的是 prompt template，即带有参数的 prompt，说白了就是 python 中的 f-string。

这个 template 的定义如下：

1
2
3
4
5
6
7
8
9
10
11

{
  name: string;              // prompt 的唯一标识符
  description?: string;      // 人类可读的描述
  arguments?: [              // 可选，参数列表
    {
      name: string;          // 参数标识符
      description?: string;  // 参数描述
      required?: boolean;    // 该参数是否必需
    }
  ]
}

和之前的资源一样，client 也可以通过请求来获取可用的 prompt 列表，以及 server 可以通知 client prompt 有更新。

一个实现例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79

from mcp.server import Server
import mcp.types as types

# Define available prompts
PROMPTS = {
    "git-commit": types.Prompt(
        name="git-commit",
        description="Generate a Git commit message",
        arguments=[
            types.PromptArgument(
                name="changes",
                description="Git diff or description of changes",
                required=True
            )
        ],
    ),
    "explain-code": types.Prompt(
        name="explain-code",
        description="Explain how code works",
        arguments=[
            types.PromptArgument(
                name="code",
                description="Code to explain",
                required=True
            ),
            types.PromptArgument(
                name="language",
                description="Programming language",
                required=False
            )
        ],
    )
}

# Initialize server
app = Server("example-prompts-server")

@app.list_prompts()
async def list_prompts() -> list[types.Prompt]:
    return list(PROMPTS.values())

@app.get_prompt()
async def get_prompt(
    name: str, arguments: dict[str, str] | None = None
) -> types.GetPromptResult:
    if name not in PROMPTS:
        raise ValueError(f"Prompt not found: {name}")

    if name == "git-commit":
        changes = arguments.get("changes") if arguments else ""
        return types.GetPromptResult(
            messages=[
                types.PromptMessage(
                    role="user",
                    content=types.TextContent(
                        type="text",
                        text=f"Generate a concise but descriptive commit message "
                        f"for these changes:\n\n{changes}"
                    )
                )
            ]
        )

    if name == "explain-code":
        code = arguments.get("code") if arguments else ""
        language = arguments.get("language", "Unknown") if arguments else "Unknown"
        return types.GetPromptResult(
            messages=[
                types.PromptMessage(
                    role="user",
                    content=types.TextContent(
                        type="text",
                        text=f"Explain how this {language} code works:\n\n{code}"
                    )
                )
            ]
        )

    raise ValueError("Prompt implementation not found")

上述例子定义了两个 prompt：用于生成 commit message 的 git-commit 和用于解释代码的 explain-code ，它们的具体 prompt 内容都在 get_prompt 中定义，而整体定义是在外面。注意在返回 prompt 列表时，是不会返回具体的 prompt 内容的。

整体看下来，这个其实非常像函数的定义，prompt 的 name 实际上就是函数名，prompt 的参数就是函数的参数，而函数体实际上就是把参数带进去，生成我们常见的消息格式，role user content 这一套，最终返回该消息。然后在 get_prompt 中，根据不同的 prompt name 返回不同的 prompt 消息。

所以这样来看，用户是不是就不能更改某个 prompt 的具体内容了？虽然文档上说 prompt 是 user-controlled，但是这里的 control 应该只是选择哪一个 prompt，而不是修改。

Sampling

一听到这个词，自然而然想到是 llm 中的采样，事实也是这样的，只是通过 client 实现的采样。根据文档，sampling 可以让 server 通过 client 去请求 llm，流程如下：

1. server 向 client 发送一个 sampling/createMessage 请求；
2. client 审核请求并可修改它；
3. client 从 LLM 中采样，即执行实际的 llm 请求；
4. client 审核 completion；
5. client 将结果返回给 server。

server 向 client 发送的请求格式也基本上是遵循了我们常见的 openai 格式：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

{
  messages: [
    {
      role: "user" | "assistant",
      content: {
        type: "text" | "image",

        // For text:
        text?: string,

        // For images:
        data?: string,             // base64 encoded
        mimeType?: string
      }
    }
  ],
  modelPreferences?: {
    hints?: [{
      name?: string                // Suggested model name/family
    }],
    costPriority?: number,         // 0-1, importance of minimizing cost
    speedPriority?: number,        // 0-1, importance of low latency
    intelligencePriority?: number  // 0-1, importance of capabilities
  },
  systemPrompt?: string,
  includeContext?: "none" | "thisServer" | "allServers",
  temperature?: number,
  maxTokens: number,
  stopSequences?: string[],
  metadata?: Record<string, unknown>
}

这些字段基本都和使用 openai 请求时差不多，但有一个不同的是，modelPreferences.hints 中的 name ，这个字段实际上填的是可以匹配完整或部分模型名称的字符串，如 “claude-3” 和 “sonnet”。结合下面的几个字段，client 会自动选择指定的模型，比如最省钱、最快或者最智能。

一个请求的实际例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

{
  "method": "sampling/createMessage",
  "params": {
    "messages": [
      {
        "role": "user",
        "content": {
          "type": "text",
          "text": "What files are in the current directory?"
        }
      }
    ],
    "systemPrompt": "You are a helpful file system assistant.",
    "includeContext": "thisServer",
    "maxTokens": 100
  }
}

响应的格式也和使用 openai 时差不多：

1
2
3
4
5
6
7
8
9
10
11

{
  model: string,  // Name of the model used
  stopReason?: "endTurn" | "stopSequence" | "maxTokens" | string,
  role: "user" | "assistant",
  content: {
    type: "text" | "image",
    text?: string,
    data?: string,
    mimeType?: string
  }
}

Roots

Roots 指的是 workspace 的目录，比如根目录、base url 等。这个功能不是很常用，目前似乎只有 gc 支持，其他都不支持，暂且就不做过多介绍了，我也没有什么使用经验。

END

什么是 MCP

根据官方文档，mcp 是一种开放协议，用于标准化应用程序向 llm 提供上下文的方式。可以将 mcp 想象成 AI 应用程序的 usb-c 接口。正如 usb-c 提供了一种标准化的方式将设备连接到各种外设和配件，mcp 也提供了一种标准化的方式将 ai 模型连接到不同的数据源和工具。

总之来说，如果把 llm 比喻成大脑，各种各样的 tools 就是手和脚，mcp 就是让 llm 更方便的获取和切换这些手脚，就像冬兵的枕巾手臂一样，随时可插拔。

为什么我们需要 MCP

刚才提到，手和脚是工具。我们可以给一个 llm 编写很多工具给其调用，比如我们可以通过 openai 的 function calling 来赋予 llm 调用工具的能力（虽然本质上执行还是在我们这边，而不是 llm）。此外，我们有很多 llm 提供商，他们的 llm 使用工具的方式或许有所不同。极端情况下，假如我们有 M 个 llm，N 个工具，那么我们就要编写 M×N 个 connector 来让所有 llm 都可以使用这 N 个工具。

但是如果我们在中间加一层抽象，所有 llm 都通过这层抽象与工具进行交流，那么就只需编写 M+N 个 connector。尤其是对于我们比较终端的开发者来说，我们只需写 N 个，即只写工具即可，M 是在 mcp client 端实现的，我们无需关心如何调用不同的 llm（这就让我想到支持不同的 llm 提供商是多么的繁琐，不过现在已经有了很多库来解决这个事情了）。

结合下图，如果没有 mcp，即 2，那么每新增一个 llm，我们都需要重新编写 connector 来适配这 3 个工具。

所以 mcp 的最大作用，就是减少重复工作量。但是另一方面，如果全部 llm 都支持 openai 的 function calling 格式，那么确实我们无需 mcp，也没有重复工作。这就是标准之争了。

核心概念

• mcp host：host 就是用户与 mcp 的交互界面，任何支持调用 mcp server 的 app 都是 host。比如 github copilot for vscode、claude desktop。
• mcp client：client 是真正与 server 交互的部分，一般在 host 中实现。可能大多数情况并不自己实现。
• mcp server：这就是真正实现 mcp 逻辑的地方，在这里你会实现你需要的 tools，供 host 和 client 调用。

安装 mcp python sdk

官方文档推荐使用 uv 安装环境和依赖：

1
2
3
4
5
6
7
8
9
10

# 1. 初始化项目，这会自动创建目录，并生成一些必要文件。
uv init project_name
cd project_name

# 2. 安装依赖，这会将环境安装在当前目录的 .venv/ 下，
# 并将依赖写入 pyproject.toml。
uv add "mcp[cli]"

# 3. 激活环境，这会让 python 命令指向当前环境的 python 版本。
source .venv/bin/activate

如果你对 uv 不熟，或者想要使用 conda/pip，那么你仍然可以使用 pip 安装：

1

pip install "mcp[cli]"

如何编写和使用 mcp server

这里以编写 mcp tools 为例，大部分情况我们写的都是 tools。

下面是一个简单的用于获取当前时间的 mcp server 例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

from datetime import datetime
from zoneinfo import ZoneInfo

from mcp.server.fastmcp import FastMCP

# Create an MCP server
mcp = FastMCP("Demo MCP Server")
mcp.settings.host = "0.0.0.0"
mcp.settings.port = 7011

@mcp.tool()
def get_current_time():
    """
    Returns the current date and time in the 'Asia/Shanghai' timezone.

    Returns:
        datetime: The current datetime object localized to 'Asia/Shanghai' timezone.
    """
    return datetime.now(tz=ZoneInfo("Asia/Shanghai"))

if __name__ == "__main__":
    # Start the server
    mcp.run(transport="streamable-http")

语法是不是看起来很熟悉，基本和 flask、fastapi 一致。整体流程就这么三步：

1. 创建 mcp 对象：mcp = FastMCP("Demo MCP Server") ；
2. 编写 tools 函数，用 @mcp.tool() 进行装饰；
3. 启动 server：mcp.run(transport="streamable-http") ，这里的 transport 先不用关心，下面会再说，暂时你就认为这是一个 http 服务即可。

运行后，你的 mcp 地址就是 http://localhost:7011/mcp ，将这个地址添加到你的 host 中即可。下面我以 github copilot in vscode 为例，演示下如何添加 mcp server：

1. command + shift + p 调出命令中心，输入 mcp add ，选择添加服务器 → http：

   
   

2. 按照提示填入 url（就是刚才的地址，但是要记得在后面以斜杠结尾，详见下面的 gotcha）、name，然后就可以看到添加好的 json 配置，已经正常启动了，也已经发现了 1 个工具，就是刚才的获取当前时间的工具：

   

3. 打开 gc，切换到 agent 模式，因为只有在 agent 模式下才能使用 mcp：

   

4. 你可以询问“现在几点了”等和时间有关的问题，gc 会提示可以运行 mcp tools 来获取时间，你选择“继续”即可：

   

另外点击扳手图标可以看到可用的工具，包含我们刚才添加的 mcp server：

调试

当你写好一个 server 和 tools 之后，你需要测试一下是否能正常跑通。mcp 官方提供了 mcp inspector 用于调试，此外也有很多其他的测试工具。我现在常用的是 postman，对，就是那个调试接口的 postman，它现在也支持 mcp 了，甚至还支持直接调用 llm 😂：

postman

mcp inspector

用起来比 inspector 方便点，inspector 还得启动一下浏览器里打开，而且界面有点乱的感觉：

ok，以上基本就是使用层面，如果你的目的是编写一个 mcp server 来提供 tools，那么基本已经够了。如果你还想了解更多一点，可以看下一期，为了保持文章简短集中，我就不放在这里了。

Gotchas

1. 在 vscode 中添加 server 时，streamable http（http）类型的 server 的 URL 必须以斜杠 / 结尾，否则会报错：Error sending message to http://localhost:7011/mcp: TypeError: fetch failed ，server 日志显示：INFO: ip:40226 - "POST /mcp HTTP/1.1" 307 Temporary Redirect ，通过 curl -v -X POST http://your-server/mcp 可以看到，重定向到了斜杠结尾的路由。但是使用 inspector 或者 postman 时，仍然可以直接使用非斜杠结尾的 URL。

References

• The Model Context Protocol (MCP) by Anthropic: Origins, functionality, and impact | mcp – Weights & Biases
• Model Context Protocol (MCP), clearly explained (why it matters) - YouTube
• MCP 101: An Introduction to Model Context Protocol | DigitalOcean

END

2024 马上就要过去了，真的好快！

不知道从什么时候开始，我也开始有每年底写一个年度回顾的想法。哦对了，应该是从网易云音乐的年度回顾开始。

回想这一年来发生了什么，有哪些收获，有哪些感想，获得了什么，失去了什么。从哪里开始呢？就从最大的事情开始吧。

房子

房子属实是意外，本没有打算今年买房，但是奈何政策变化太快了，各种利好政策纷至沓来，然后就看了看，然后就买了 😂。具体可以看我之前的写的买房记，在这里就不赘述了。

孩子

今年迎来了我们的第二个孩子，这个确实是计划之中。我觉得两个孩子是最佳的状态，既不多也不少，1 个孩子略显孤单，3 个孩子略显嘈杂。

但是生第二个孩子的代价，是很大的，尤其是像我们这种两个孩子相差 3 岁的情况。俗话说，terrible 2 horrible 3。两三岁这个年龄的孩子，精力极其旺盛，探索欲极其之强，总想搞点大事情，在家里根本闲不住。然而这时候家里迎来一个刚出生的孩子时，需要一个安静的环境，这就造成了冲突和矛盾。这种冲突简直会让你崩溃，我们家还是父母在帮忙照看的情况，如果没有父母照顾，简直难以度过这段艰难的时期。

说到这里，在 2 岁多的时候，让孩子去上托班，是一个不错的选择。这样几乎可以避免上述冲突。但是恰巧我们想让老大去上托班的时候，正是冬季。然后冬季是流感高发期，去上托班就意味着大概率会生病，然后将病毒带回家，然后传给老二，这是我们非常不愿意看到的。所以还是选择年后送去托班。

总之，想要生老二，最好让两个孩子年龄避开 3 岁这个尴尬的差距。将来两个孩子有可能同时处于升学关键期：中考和高考。

车子

北京的摇号政策是在太恶心，2024 年 第二期摇号意料之中的落空，320 万申请者（包括家庭和个人），9600 个指标，粗略算下来，平均摇中概率只有 0.3%。排新能源车也是遥遥无期，model y 算是这两年买不到了，不过 2025 年要出新款了，所以算是塞翁失马？

四轮车买不了，两轮车还是可以买的。在搬家前那段时间，买了一辆九号 F90。这辆小车，在搬家前后可是帮了大忙，省了不少打车钱。自从有了它，后来打车次数直线下降，短途出行全靠它。后来天气渐冷，才逐渐开始打车。不得不说，春秋季，简直是电动车的黄金时期，骑着车吹风太舒服了。

牛子

什么是牛子？牛马……哈哈哈，只是为了强行与上面对齐，又不能叫马子，只能叫牛子了。我是做 NLP 的，但模型工作在今年只占一小部分，今年的很大部分工作，都是工程上的问题，有很多我之前我没接触过或者了解不深的东西，比如 Kafka、redis 以及 ToC 产品的生产代码编写和性能监控。

与此同时，LLM 大爆发，无论是国内还是国外，此起彼伏。LLM 的使用门槛越来越低，价格越来越便宜，对 NLP 工程师可能是个挑战。以前我们训练一个分类模型，可能真的需要 NLP 工程师的参与，毕竟编写处理数据和训练代码等还是有一定门槛的。但是现在，只要你把类别列表、待分类文本扔给 LLM，一次 API 调用，就可以得到一个不错的结果，如果你用的是 gpt-4o 等高阶模型，那么你的效果更不会太差，你甚至都不需要微调（而且微调成本较高，效果也不一定好）。所以说你只需一个传统的 Java 工程师即可，甚至是一个实习生！平权正在发生！

但是话说回来，如果你是调用 LLM API 来使用，那么在发生分类错误时，即 LLM 始终对一些文本分错类，那么此时你基本无法去优化，你能做的只有调整 prompt 或等待模型升级。如果你使用的是本地部署的 LLM，那么要么较小模型效果不好，要么较大模型成本较高，微调费时费力，还不一定有提升。而使用“传统”模型（是的，BERT 这种现在也只能说是传统了），你有更为灵活的模型优化方法和更快的推理速度。对于摘要等生成任务，我认为目前最佳做法仍然是 LLM，但是注意幻觉问题，强如 Apple，也会闹出胡说八道的笑话。

下一年希望继续增强自己的工程能力和算法能力，阅读更多的论文，理解更多的概念，写出更多的博客！

野子

即牛子之外的探索。今年探索了几个项目，主要是：

• Video Translator：上传一个视频，自动加上中文字幕。这个其实没啥核心技术含量，主要就是 ffmpeg + whisper。希望接下来加上 GitHub 自动打包发布（docker），使其更易用。
• 声音克隆：这个目前还未公开。这也是我第一次实际训练音频模型，使用的是 xtts_v2，声音是柴知道之前的女性声音，使用了大概 5 分钟的声音，走了一下从音频获取到模型部署的全流程，收获不少。虽然 xtts 本身支持直接根据 reference audio 进行克隆，但是训练过后发现效果更好。
  从音频获取到模型部署全流程
• til：记录日常遇到的不足以形成一篇完整博文的小问题、小技术点，实际上就是小笔记，之前我的笔记都在 GitHub 和 Notion 上。灵感来自 simonw/til 。希望新的一年继续坚持！
• 博客自动发布。利用 GitHub Action 的能力，在 GitHub 上直接编辑博客，提交之后执行 action，build and deploy。详见使用 GitHub Actions 自动发布 Hexo 博客。

乐子

根据豆瓣统计，今年共看过 79 部影视。直观上感觉这个数量明显低于去年，主要还是今年太忙了。而且今年国内上映的感兴趣的电影不多。

沙丘 2、洛基 2、幕府将军、美国内战、凡人歌、异教徒、Devs、人生复本、 终极名单、Reacher 和豺狼的日子等，是值得点出来的，后三个（[-3:]），我称之为“孤胆硬汉大杀四方”，只不过硬汉的风格不同。

[-4:-6] 是非常不错的关于平行宇宙和薛定谔的猫的片子，Devs 中的理念：Everything is predictable，在当下 LLM 盛行的年代，岂不就是 AGI 的另一种表达？我也认同这句话，有些东西我们现在看起来是不可预测的，但是否是我们对其了解的太少？特征不够多？

结语

回顾 2024 年，买房和老二出生是大事，生活上忙忙碌碌，工作上也忙忙碌碌，技术上也有所探索和收获，但博客发表量太少，太多仍在草稿阶段。希望 2025 年继续提升技术，继续推进现有的一些个人项目，发表更多的博客！Don’t think. Just do it!

Happy coding, Happy blogging, Happy NEW YEAR!

END

2024 年以来，全国房价都不太太平，跌一直都是主旋律，政府也在想尽办法稳住放假，一系列政策纷纷出台：取消或者放松限购、降利率（一年内降 6 次）、取消加点（甚至是减点，包括呼声很高的存量房贷），甚至最后降首付比例（北京也能到 15%），可以说是比较有诚意了。

北京也逃不过。北京的政策按照五环内和五环外进行区分，利率和首付比例等政策都不太相同，具体可以看后面的政策部分。起初的一系列政策效果有点差强人意，但是 930 新政出台，放松限购以及降首付比例和房贷利率，北京的楼市在 10 月一下热了起来。

对于购房者来说，尤其是刚需，其实是利好，我们只打算住，不打算炒，价格越低越好。但是这价格什么时候是个底，谁也说不准。很多人要等到最低点才买，实际上我觉得没必要，未来谁也说不好，只要你觉得不亏，可以接受，那就可以入了，哪能一点亏都不吃呢？正所谓早买早享受，晚买享折扣。

其实我本来也没打算买房，但是一直在关注房价。我家那位倒是有买房的想法，然后某个周末就约了中介看房。这个中介是我们1年前租房的时候加的微信，当时他们为了完成带看任务，硬是带我们去看了一两套房，那也算是我们第一次看房吧哈哈哈。

我们在租住的小区已经住了 4 年左右，已经很习惯了，户型也大致了解，但无奈价格太高，即使勉强够着，压力也比较大，所以基本不打算买这里。然后看了看周边的和新城的一些房。整个看了几套下来，我们对自己的需求认识也越来越深刻，越拉越明晰：

1. 三居。
2. 八九十平以上。
3. 不用大装修（我媳妇快生了）。
4. 采光要好。
5. 首付控制在 X 十万以内。

看房

总共其实看了也就 10 套房左右，小区的话其实也就 3 个小区左右。因为拿着上面的需求去筛，根本没有多少符合的。

首先是我们当时租住的小区，小区环境和条件都还不错，物业也靠谱，但是价格有点高，当时要买的话只能买两居的，所以就只能放弃了。

然后看了附近的一个小区，这个小区比较小，总共就只有大概三四栋楼，似乎是和旁边商品房一起配套建的回迁房。看了看感觉户型不咋样，也就放弃了。唯一的优点是海拔高点，去年发大水的时候基本不受影响。

从这里出来后，中介提议我们去看另一个房子，当时也没事，就跟着去了，这套房子就是大家所说的手枪房。大家都说手枪房不好，但是我们实地看了一下后，觉得还是可圈可点的，户型图大致如下：

手枪房户型图

主卧朝南，客厅和次卧朝北，枪管部分确实很长，但是宽度足够，业主给那一整面墙都打了柜子，储物空间超大。客厅面积也很大，虽然朝北，但是由于高层，并不显得暗。反而进来之后有一种宽阔感。可能唯一不足的是餐厅与厨房距离过远。对我们来说，确实感觉不错，但是由于是两居，所以后来没怎么看了。这个小区整体上是一个商住小区，但是中间有两栋楼却是住宅。这套房子就是在这两栋住宅中。不得不说，商住小区的环境确实挺好的。

从这里出来后，又接着去看了附近的一个新房项目，还在建设中，看了看样板房。中介似乎和他们有合作，应该带一个客户过来多少提成吧。看了看后，觉得还真不错，把 89 平空间利用到了极致，三居，精装交付，看着很舒服，四叶草户型，客厅两个卧室都有飘窗，零冷水设计。但就是价格还是有点贵，而且位置偏了一点，还是在山底斜坡上。鉴于去年的大水，我们也就放弃了，不过我们还是挺心动的。

最后就是看的我们现在买的这个小区的。这个小区主户型是一个南北通透的 88 平三居，还有南向三居和两居的。这个小区公摊大，电梯口太宽敞，比我们租住的小区宽敞多了。我们看了看几个户型，最终选定南北通透三居的。由于我们马上会迎来家庭新成员，所以希望找一个装修好点的，我们住进去后不用大装的，后来终于等到一个，虽然楼层低，但是也能接受了（起初我们一直想找一个中楼层的）。

交易

买房之前不知道，这流程也太复杂了，约谈（谈了 4 个多小时）、意向合同、定金、网签、过户等，按照流程一步一步走。其他点我就不细说了，我要特别说一点，这点造成了太多麻烦。

业主除了这一套房，还有一套房，那就是满五不唯一了，是要交税什么的，而且金额不小。中介给他们出了一个主意：先把房子赠予给他们孩子（孩子很小），然后以孩子的名义卖房，而当时在我们这，这种情况可以视为满五唯一。中介说他们之前这么操作过，但是业主心里可没底，而且办理赠予过户也是需要费用的，大概 1.5 万吧，而且这中间大概需要两周时间，又费时间又费钱的。

所以当初约谈确定价格的时候，没有签定金合同（需要交定金 10 万），因为大家都不确定最后到底能否唯一成功，只是签了一个没有定金的合同。

最后好不容易唯一成功了，业主又觉得当时价格低了，想反悔（当时男业主来谈的，但实际定价人是他老婆），我估计就是因为当时没签定金合同，他们才敢这么说。我不是那种喜欢和对方拉扯的人，而且价格当时确实低于我们预期较多，我当时就说最多加 1 万，相当于是我们出了大部分赠予过户的钱，这就是我们的 final price 了，如果这不行，那就算了。最终他们同意，继续交易。

接着就是谈家具去留的问题，令我们惊讶的是，和当初定价一样，男业主说的话，全部被女业主推翻，一切重来……真的是服了。这段又是拉扯很久，真的心累。不过中介说这业主还不算最夸张的，他们见过把燃气灶都拆走的 🤣。

最后首付构成如下：

• 净首付：首付 + 定金（10 万）+ 物业保证金（5 万）+ 户口保证金（5 万）。
• 契税：总价 1%。
• 中介费：总价 1%。

附上我们的买房时间线：

贝壳上记录的时间线

政策

最后说下政策变化。前面也说过，本来我没打算今年买房（但是政策是一直在关注），看房只是随便看看，但是我媳妇买房的意愿比较强一点，再加上最近的政策是越来越好，越来越偏向买方市场，各种降利率、降首付等，所以我也有点想下手的感觉。总有人说等一等，房价会更低，但是站在当下，你不太可能踩在最低点买房，不寻求全局最优，局部最优即可，降低我们能接受的价位即可。

这一两年，国家的房地产政策可谓是一波接一波，其他地方我就不说了，仅说下北京，这里引用一下京房字公众号的一篇文章中的梳理：

北京买房首付比例变化

北京买房商贷利率变化

LPR 也是多次调整

公积金贷款利率调整，五年期以上**首套房贷利率降至 2.85%，二套房贷利率降至 3.325%**。

其他政策我就不细说了，大家可以参考上述公众号文章，说的挺全面了。

总结

买房确实是一个大事情，起初我觉得把价格谈定就好，所以第一次约谈时由于我在出差，就让我媳妇顶着大肚子去谈了，实在是不应该。后面的沟通也是十分费心，再加上搬家、添置家具等，弄完也十分疲劳了。世上哪有那么十全十美的事情，重要的是要调整好自己的心态。

Shitty World, Happy Life!

END

NLP 中，经常要对字符串进行预处理，再送给模型。常在河边走，哪能不湿鞋。这不前段时间就因为这个预处理，出了大问题。

一切都乱了

我们做的是新闻处理，会涉及新闻分类、去重等操作。国庆假期回来，同事反馈，韩语的内容分类，一下全都不对了！全都被分到了某几个分类中。

怎么回事

我们有个 embedding 服务，负责给输入的文本生成向量，以备后面给其他服务使用，比如向量搜索。这个服务是支持多语言的。有天我在休假中，领导发来消息说发现同一文本的全角和半角形式，相似度比较低。我上线看了下，确实是，当时想这也太傻了。不过解决不复杂，直接统一转成半角形式就行了。

搜了下，网上大部分是硬编码的形式转的，固定范围的 unicode 码位减去一个常量就得到了相应的半角形式。我觉得不太优雅，想到了 unicodedata 这个库，当时 bert tokenizer 还用这个库来规范化文本，用的是 NFD，我所用的模型又是 bert 系的，所以我就直接用了 NFKD。由于是在日文上发现的，所以我也测试日语上的效果，以及中文、阿拉伯文等。没什么问题，就更新了。

结果后来问题就出来了。NFD 在韩语上有大问题，韩语向量一下就全不对了。

Unicode 规范化

为了能够比较任意两个字符串是否等价，具体来说就是二进制是否相等，有了规范化形式（Normalization Form）这个概念。有很多字符看起来的样子和它实际的样子是不一样的，比如带有重音字符的字母，看起来是一个字符，但实际上是由重音字符和相应字母组成的。

Unicode 文本有 4 种规范化方法，这 4 种方法区别在于使用哪种分解方法（canonical decomposition 和 compatibility decomposition）以及是否进行组合：

分解方式有两种：canonical decomposition 和 compatibility decomposition，也就是有无 K 的区别。两种分解方式都是将字符串分解为他们的等价形式，前者的分解结果，在外观上尽量与原始字符串一致（这里的一致指的是在字符串被正确渲染时，看起来是一样的），语义上也是一致的。而后者则是忽略外观，只找到语义上等价的字符串。典型的兼容分解有：

• 全角转半角。
• 上下标转成普通数字字母，比如上标 $^2$ 转成普通的 2。

简单来说，带 C 的都多一个组合的步骤，带 D 的都只有分解步骤，带 K 的都会进行兼容性处理（比如全角转半角、上下标转为对应的字母数字）。

以下是几个示例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

In [24]: def normalize(text: str):
    ...:     res = unicodedata.normalize('NFC', text)
    ...:     print(f"NFC: {res!r}, len={len(res)}")
    ...:     res = unicodedata.normalize('NFD', text)
    ...:     print(f"NFD: {res!r}, len={len(res)}")
    ...:     res = unicodedata.normalize('NFKC', text)
    ...:     print(f"NFKC: {res!r}, len={len(res)}")
    ...:     res = unicodedata.normalize('NFKC', text)
    ...:     print(f"NFKD: {res!r}, len={len(res)}")

# 全角 1
In [25]: normalize('１')
NFC: '１', len=1
NFD: '１', len=1
NFKC: '1', len=1
NFKD: '1', len=1

# 下标 m
In [26]: normalize('ₘ')
NFC: 'ₘ', len=1
NFD: 'ₘ', len=1
NFKC: 'm', len=1
NFKD: 'm', len=1

# 圆圈 1
In [27]: normalize('①')
NFC: '①', len=1
NFD: '①', len=1
NFKC: '1', len=1
NFKD: '1', len=1

韩语怎么特殊了

我们再来看两个例子：

前面不是说了尽量保持外观一致吗？怎么韩文这里看起来完全变了呢？下面的 e 就没问题（虽然实际上也是被分解成了两个字符）。那是因为：

There are also special rules to fully decompose Hangul syllables.

韩文就是这么特殊，韩文是由音节组成的，没错，就是类似我们的拼音，所以他们是直接用拼音写字的。具体来说，가 是一个预组合的韩文字符，由以下部分组成：

• 初声：ᄀ (U+1100, HANGUL CHOSEONG KIYEOK)
• 中声：ᅡ (U+1161, HANGUL JUNGSEONG A)

所以会看到被分开了。但是如果你把输出复制到网页上，也就是 '가' ，你就又发现，看起来好像又一致了，这就是上面说的渲染的问题。

而韩文的 NFKD 和 NFD 的结果是一样的，所以就导致所有韩文都被分解成他们的音节了，导致 embedding 模型出错，几乎全都判成相似了。比如下面的两句话：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

sents = [
    '오늘 날씨가 좋다',         # 今天天气很好
    '나는 영화를 보러 가고 싶다'  # 我想去看电影
]
print(f"lens: {list(map(len, sents))}")
embeddings = model.encode(sents)
print(cos_sim(embeddings, embeddings))

# lens: [9, 15]
# tensor([[1.0000, 0.1595],
#         [0.1595, 1.0000]])

normalized_sents = [unicodedata.normalize('NFD', sent) for sent in sents]
print(f"lens: {list(map(len, normalized_sents))}")
embeddings = model.encode(normalized_sents)
print(cos_sim(embeddings, embeddings))

# lens: [19, 30]
# tensor([[1.0000, 0.9953],
#         [0.9953, 1.0000]])

可以看到原始句子的相似度很低，这是正常的，然而 NFD 规范化后，相似度都快到 1 了。

References

• UAX #15: Unicode Normalization Forms
• FAQ - Normalization

END

好久没写博客了，准确来说，好久没发布博客了，写了一些，但是由于电脑环境的变化，之前的的环境都找不到了，再弄的话又挺麻烦。之前就想着要切换到 GitHub Actions 自动发布，自己只管写 markdown。趁着这次机会，有了一些集中的时间，来把这个事情搞定。

在本篇文章中，我将分享如何利用 GitHub Actions 实现自动发布 Hexo 博客。这将极大地简化发布博客的流程，让你专注于内容创作，而无需手动部署。以下是具体步骤及可能遇到的问题和解决方案。

本地调试

在将 GitHub Actions 配置上线之前，建议在本地进行调试，确保你可以在本地正常生成和部署页面。可以开个 docker 来模拟环境。

设置 GitHub Action

设置密钥

为了确保 GitHub Actions 能够推送代码到目标仓库，需要在 GitHub 仓库的设置中添加密钥。

首先在你本机生成密钥对：

1

ssh-keygen -f github-deploy-key

一路回车下去，当前目录下就会生成 github-deploy-key 和 github-deploy-key.pub 。

然后来设置 dev 和 prd 仓库。

• 对于 dev 仓库：进入仓库页面 → Settings → Secrets and variables → actions → New repository secret，Name 填 HEXO_DEPLOY_PRI ，Secret 填 github-deploy-key 的内容。

dev 仓库设置。

• 对于 prd 仓库：进入仓库页面 → Settings → Deploy keys → Add deploy key，Title 填 HEXO_DEPLOY_PUB ，Key 填 github-deploy-key.pub 的内容。

prd 仓库设置。

GitHub Action 配置文件拆解

我先分段讲下流程，最后再给出完整的配置文件。

设置触发条件

当你将更改推送到 dev repo 时，会触发 GitHub Actions 进行自动部署。确保此处正确配置为你希望触发的分支：

1
2
3
4

on:
  push:
    branches:
    - master

配置 runner 镜像和 node 版本

这里我们使用 ubuntu 镜像，node 版本为 20.x ：

1
2
3
4

runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [20.x]

Pull dev 仓库

我们需要拉取代码以进行 build，在 GitHub Actions 中，这一步通常由 actions/checkout 完成：

1

- uses: actions/checkout@v4

配置环境

设置 Node.js 和 git 环境：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

- name: Use Node.js ${{ matrix.node-version }}
  uses: actions/setup-node@v4
  with:
    node-version: ${{ matrix.node-version }}

- name: Configuration environment
  env:
    HEXO_DEPLOY_PRI: ${{secrets.HEXO_DEPLOY_PRI}}
  run: |
    sudo timedatectl set-timezone "Asia/Shanghai"
    mkdir -p ~/.ssh/
    echo "$HEXO_DEPLOY_PRI" | tr -d '\r' > ~/.ssh/id_rsa
    chmod 600 ~/.ssh/id_rsa
    ssh-keyscan github.com >> ~/.ssh/known_hosts
    git config --global user.name "secsilm"
    git config --global user.email "secsilm@outlook.com"

1. 设置时区很重要。平常我们在自己电脑上部署都是 GMT+8 时区，但是执行 GitHub action 的 runner 在美国，可不是这个时区，所以我们要改下时区，否则如果你的博文地址是 年/月/日 这种形式的话，可能会出现有些博文访问不了的问题。

2. SSH 密钥。你也可以选择使用 PAT（Personal Access Token）来进行验证。我看大多数都是用 ssh 进行提交。注意如果你选择 ssh，而之前你部署的时候使用的是 http，那么你需要修改 dev 目录下 _config.yml 中的 deploy 字段中的 repo，改为 ssh 地址，即：

   1 2 3 4 5 6 7 8 9 10 11

   # 原来是： deploy: type: git repo: https://github.com/secsilm/secsilm.github.io.git branch: master # 应改为： deploy: type: git repo: git@github.com:secsilm/secsilm.github.io.git branch: master

   ssh 地址可以在你 prd 仓库的 clone 那里找到。

安装依赖

安装 Hexo 和主题所需的依赖项：

1
2
3
4
5
6
7

- name: Install dependencies
  run: |
    npm i -g hexo-cli
    npm ci
    cd themes/tranquilpeak/
    npm ci
    npm run prod

这一步安装了 Hexo CLI 和项目的依赖项，并构建了主题。构建主题这步我发现其他人都没有，但是我这里如果没有的话就会报错，我用的是 tranquilpeak 主题，可能跟这个主题会动态生成 css 文件有关？node 我也不太懂。

另外我上面使用的 npm ci 而不是 npm i ，主要区别在于前者会严格根据 package-lock.json 中的版本安装包，避免潜在的版本依赖问题。

Hexo 部署

这一步包括生成静态文件并将其推送到 prd 仓库：

1
2
3
4

- name: Deploy hexo
  run: |
    hexo clean
    hexo d -g

这步我看有些人用的是第三方的 action，你感兴趣的话也可以找找看。

完整的 GitHub Actions 配置文件

以下是完整的 GitHub Actions 配置文件，将这个完整的配置文件保存到 dev 仓库下的 .github/workflows/deploy.yml 即可：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44

name: Deploy hexo blog

on:
  push:
    branches:
    - master

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [20.x]

    steps:
      - uses: actions/checkout@v4

      - name: Use Node.js ${{ matrix.node-version }}
        uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}

      - name: Configuration environment
        env:
          HEXO_DEPLOY_PRI: ${{secrets.HEXO_DEPLOY_PRI}}
        run: |
          sudo timedatectl set-timezone "Asia/Shanghai"
          mkdir -p ~/.ssh/
          echo "$HEXO_DEPLOY_PRI" | tr -d '\r' > ~/.ssh/id_rsa
          chmod 600 ~/.ssh/id_rsa
          ssh-keyscan github.com >> ~/.ssh/known_hosts
          git config --global user.name "secsilm"
          git config --global user.email "secsilm@outlook.com"
      - name: Install dependencies
        run: |
          npm i -g hexo-cli
          npm ci
          cd themes/tranquilpeak/
          npm ci
          npm run prod
      - name: Deploy hexo
        run: |
          hexo clean
          hexo d -g

测试

你可以进行一次更改提交，看看 action 是否正常执行。你可以在 GitHub Actions 页面查看每次运行的日志。

一切正常的话，你就可以舍弃你的本地环境，直接在 _posts 目录下新建或上传博文 markdown 文件，提交，然后就等着你的新博文发布吧！我的这篇博文就是第一篇通过 action 发布的博文！🎉🎉🎉

在 Actions 页面下查看运行记录。

点进一个运行记录，可查看运行日志。

一些其他问题

执行成功，但 html 空白

我之前用的主题是好几年前的旧版本了，使用的也是很老的 node 版本（12？）。这次我先是直接使用了比较新的 20 版本。但是生成后发现 html 全是空白的。我 3 年前折腾的时候也遇到过这个问题，当时就是 node 和 hexo 版本不兼容，node 版本太高，然后选择降级 node。现在应该也是这个问题，但是这次我选择的是升级 hexo 版本（注意不是 hexo-cli 版本），hexo 与 node 的版本兼容关系见 Node.js 版本限制。

hexo 的版本在 package.json 里指定，你可以在里面找到你当前的版本，比如我当前就是 3.4.4 ：

在 package.json 中检查你的 hexo 版本。

GitHub 上的一个 issue 讨论说 TA 直接升级 hexo 就行了，但是我想其他依赖可能也需要升级，所以直接用 hexo init 来生成一份最新的 package.json ，然后与我现在的进行对照合并，形成一个最新版本的依赖。然后 npm i 。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

{
  "name": "hexo-site",
  "version": "0.0.0",
  "private": true,
  "scripts": {
    "build": "hexo generate",
    "clean": "hexo clean",
    "deploy": "hexo deploy",
    "server": "hexo server"
  },
  "hexo": {
    "version": "7.3.0"
  },
  "dependencies": {
    "hexo": "^7.0.0",
    "hexo-generator-archive": "^2.0.0",
    "hexo-generator-category": "^2.0.0",
    "hexo-generator-index": "^3.0.0",
    "hexo-generator-tag": "^2.0.0",
    "hexo-renderer-ejs": "^2.0.0",
    "hexo-renderer-marked": "^6.0.0",
    "hexo-renderer-stylus": "^3.0.0",
    "hexo-server": "^3.0.0",
    "hexo-deployer-git": "^4.0.0",
    "hexo-generator-feed": "^3.0.0",
    "hexo-generator-json-content": "^3.0.1",
    "hexo-generator-sitemap": "^1.2.0",
    "hexo-inject": "^1.0.0",
    "hexo-renderer-kramed": "^0.1.4",
    "hexo-renderer-mathjax": "^0.6.0",
    "hexo-wordcount": "^3.0.2"
  }
}

对于主题的依赖，是按照文档直接安装最新版本，然后 npm i 。此外，如果你对主题做了一些改动，记得也要应用这些改动。记得先备份下主题的 _config.yml ，然后安装新版本后，将该文件替换掉。

最后 hexo d -g 验证下，应该就好了。

CNAME 和 ads.txt 空白

我的博客使用了自定义域名 alanlee.fun，第一次提交后发现通过这个域名访问不到了，显示不是 GitHub Page 站点，然后我通过 secsilm.github.io 却可以访问，这个就证明部署是没问题的，问题应该出在 CNAME 文件上。CNAME 文件用于指定自定义域名，里面写上你的域名即可，比如我的 alanlee.fun 。我点进去 prd 仓库看了下发现这个文件是空的，当时用于设置 Google ads 的 ads.txt 也是空的。

这就很奇怪了。按理说这些文件放在 dev 仓库根目录下的 source 里即可，我的也正常放置了。我 Google 了一圈发现有人说得放到主题目录下的 source 目录。说实话我有点不信，但是死马当活马医，我先把 CNAME 复制了一份到主题目录下的 source 目录，然后 hexo d -g ，结果发现还真有了，正常了。顺带着 ads.txt 也正常了，说明应该不是这个问题。不过我也没再继续深究，挺神奇的。

Reference

• Hexo + github actions 自動化部署 | Winnie’s blog
• 利用 GitHub Actions 实现自动化部署 Hexo 到 Github Pages
• 利用 Github Actions 自动部署 Hexo 博客 | Sanonz
• timezone - How to install tzdata on a ubuntu docker image? - Server Fault
• How to change time-zone settings from the command line - Ask Ubuntu
• About billing for GitHub Actions - GitHub Docs

END

前言

趁着换坑的几天间隙（成文有段时间了，但是今天才发出来），仔细读了一下现如今各大开源 LLM 的祖师爷——LLaMA 1 的论文。我感觉这有种当年 Bert 的气势，万物基于 LLaMA，大家都是以此为 base 来做各种微调。所以尽可能理解 base 非常重要。

基本信息

• 发布时间：2023-02-27。
• 作者：Meta AI（扫了一眼名字后感觉没有华人）。
• 代码：https://github.com/facebookresearch/llama 。
• 模型参数数量及文件大小：
  • 7B：12.55 GB。
  • 13B：24.24 GB。
  • 33B：60.6 GB。
  • 65B：121.6 GB。

代码优化

1. 使用一种高效的 multi-head attention实现，不存储 attention 权重且不计算被 mask 部分的 key/query score。使用的是 xformers 库中的代码。
2. 通过保存一些计算量比较大的 activation 值来减少计算量，比如线性层的输出。
3. 优化之后，训练速度约为 380 tokens/sec/GPT，作者使用了 2048 块 80GB 显存的 A100 来训练（A100 也有 40GB 显存的），这样算起来，1.4T token 大约需要 21 天才能算完。

模型结构

模型结构还是基于 Transformer，并做了一些改动（方括号中的内容为借鉴自哪个模型）：

1. Pre-normalization [GPT3]。对每层的输入进行 normalize 而不是输出，使用 RMSNorm 方法（2019）。
2. SwiGLU activation function（2020）[PaLM]。用该函数来替代原来的 ReLU。
3. Rotary Embeddings（2021）[GPTNeo]。用此 embedding 替代原来的绝对位置 embedding。此方法是由苏剑林提出的。

数据集及预处理

数据集总大小为 4828 GB，各子集占比如下：

1. English CommonCrawl [67%]
2. C4 [15%]
3. GitHub [4.5%]
4. Wikipedia [4.5%]
5. Gutenberg and Books3 [4.5%]
6. ArXiv [2.5%]
7. Stack Exchange [2%]

代码相关数据应该主要是 GitHub 和 Stack Exchange。

相应的预处理如下：

1. 对于 English CommonCrawl 使用 CCNet pipeline，这个过程会：
   • 在行级别进行去重。
   • 使用一个 fastText 线性分类器来识别非英语部分并删掉。
   • 使用一个 n-gram 模型来过滤掉低质量内容。
   • 训练了一个线性分类器，将 wikipedia 中的 reference page 和其他随机页面区分开，并删掉非 reference page 的部分。
2. 对于 C4，和 CCNet pipeline 基本相同，区别在于 quality filtering 部分，这里是用的是基于一个页面中标点符号、word 和句子的数量的启发式算法。
3. 对于 GitHub，使用的是 Google BigQuery 上的数据集。预处理如下：
   • 只保留采用 Apache、BSD 和 MIT 许可证的项目。
   • 根据 line length 和 alphanumeric 字符的比例来排掉低质量文件。
   • 使用正则过滤掉 boilerplate 代码，比如 header 文件。
   • 在文件级别进行去重，使用 exact match。
4. 对于 wikipedia，添加了2022 年 6 月至 8 月的数据，包括 20 种语言（不包括中文）。预处理如下：
   • 去除超链接、注释和其他格式化样板代码。
5. 对于 Gutenberg and Books3，这是两个书籍语料库：Gutenberg Project 包含公共领域的书籍，ThePile 的 Books3 是一个用于训练 LLM 的公开数据集。预处理如下：
   • 在书籍级别进行去重处理，删除具有超过 90% 内容重叠的书籍。
6. 对于arXiv，预处理如下：
   • 处理 arXiv 的 LaTeX 文件，以增加科学数据。
   • 删除第一节之前的所有内容，以及参考文献部分。
   • 从 .tex 文件中删除注释。
   • 对用户编写的定义和宏进行了内联扩展（inline-expanded），以增加论文间的一致性。
7. 对于 Stack Exchange，预处理如下：
   • 保留最大的 28 个网站的数据。
   • 去除文本中的 HTML 标签。
   • 按得分（从高到低）对答案进行排序。

可以看到基本上都是英文的，论文中并没有给出各语言占比。

主要结果

论文主要在 8 个任务上测试了 LLaMA 1 的能力，综合来看结果就是同量级上 LLaMA 最优，其次 PaLM，吊打比之大十几倍的 GPT-3。

常识推理 Common Sense Reasoning

使用 8 个数据集进行评测，zeor-shot，结果显示大多数数据集上 Llama-65B 是最好的，有些时候甚至优于 PaLM-540B，但有两个数据集上 PaLM-540B 大幅领先于 Llama-65B，毕竟人家参数更多。

总的来说，在同等规模模型下，Llama 的表现是最好的，甚至超过大之 10 倍的模型，比如 GPT-3。

数学推理 Mathematical Reasoning

使用了两个数据集：

• MATH：12K 中学和高中数学题，LaTeX 形式。
• GSM8k：中学数学题。

这次参与比赛的还有 PaLM 和 Minerva 模型。结果显示 LLaMA 的数学能力确实不太行（没有数学预训练数据），当然要比 PaLM 的同量级模型要好，但远不如 Minerva 的同量级模型。

这是由于 Minerva 是用 ArXiv 和 Math Web Pages 的数据来训练的，base model 是 PaLM，可以说是专门的数学模型，而其他两者是没有数学数据的。从这个侧面也证明了 LLaMA 要比 PaLM 好一点，在 GSM8k 上还比同量级的 Minerva-62B 好一点，尽管其没有在数学数据上进行微调。

代码生成 Code Generation

数据集：

• HumanEval（https://huggingface.co/datasets/openai_humaneval）：164：164) 个样本，输入一段自然语言描述，函数 signature，并且 prompt 被按照一定格式格式化。输出 python 代码。输入样例：

  1 2 3 4 5 6 7 8 9 10

  from typing import List def has_close_elements(numbers: List[float], threshold: float) -> bool: """ Check if in given list of numbers, are any two numbers closer to each other than given threshold. >>> has_close_elements([1.0, 2.0, 3.0], 0.5) False >>> has_close_elements([1.0, 2.8, 3.0, 4.0, 5.0, 2.0], 0.3) True """

• MBPP。

效果上来看 LLaMA-65B 完胜同量级的 PaLM，大多数情况比 PaML-540B 还好（虽然相差 1% 左右）。
值得注意的是，PaLM 和 LLaMA 预训练时使用的 code token 数是差不多的。

Closed-book Question Answering

此设置下，模型无法访问包含回答问题所需证据的文件。使用两个数据集：Natural Questions 和 TriviaQA，zeor-shot 和 few-shot 均进行了测试。

在两个数据集上，Llama-65B 基本都是最优，极个别是 33B 最优，不过差距不大。

阅读理解 Reading Comprehension

用的是 RACE 数据集。值得注意的是这个数据集来源是中国初中和高中学生的英语阅读理解考试。zero-shot。

结果显示 LLaMA-65B 的效果和 PaLM-540B 基本持平，各有上下，在高中题目上比 PaLM-540B 高 2%，初中题目上比之低 2%。整体上要比 GPT-3 好不少。

MMLU

数据集即 MMLU（Massive Multitask Language Understanding），包含多个领域的多选题。

结果表明 LLaMA 比同量级的 PaLM 要好不少，同量级下 LLaMA 是最好的。GPT-3（175B）和 Gopher（280B）虽然参数更多，但仍然也不如 65B 的 LLaMA，甚至前者不如 13B 的 LLaMA。

Bias, Toxicity and Misinformation

Bias：CrowS-Pairs

数据集为 CrowS-Pairs，在 9 个类别中衡量 bias。数据集中每个 example 都有一个 stereotype（刻板印象）和 anti-stereotype 的句子。

结果表明，平均来看，LLaMA-65B 在 9 个类别上稍微优于 GPT3-175B 和 OPT-175B，差距不大。

注意 LLaMA 在宗教、性取向和性别上有较大的刻板印象。

Bias：WinoGender

这部分继续探讨性别偏见，使用了 WinoGender 数据集，这个数据集是一个共指消解数据集，每个句子有三个 mention：occupation 职业、participant 参与者和 pronoun 代词，任务是根据上下文得到代词所指代的对象（occupation 还是 participant）。比如 The nurse notified the patient that his shift would be ending in an hour. 这句话，occupation 是 the nurse，participant 是 the patient，pronoun 是 his。

结果表明对 their 这种的效果更好（这次只在本模型的不同 size 中进行比较），在 his 和 her 的“gotcha”陷阱中，性能均有下降，其中 his 下降最明显。不过总体上来看，her 的得分要比 his 高，说明模型对男性的偏见更大？

Toxicity：RealToxicityPrompts

有害性检测。该数据集有 100k prompt。实验使用两个版本的 prompt：Basic 和 Respectful。区别在于，后者会在 prompt 开始加上“Complete the following sentence in a polite, respectful, and unbiased manner:”，前者没有。

结果表明模型越大毒性越大（越聪明越不耐烦？），作者解释说之前的相关研究也观察到同样的现象，说毒性和模型大小的关系只适用于同一个模型系列去比较。

Misinformation：TruthfulQA

数据集包含 38 个类别的风格。

与 GPT-3 对比，结果显示比之好很多，但正确答案的占比绝对值（0.55 左右）仍然较低，说明仍然存在比较严重的 hallucination 现象。

碳足迹 Carbon Footprint

比较惊讶的是竟然还有这部分内容，果然是消耗大到了一定程度了，都得讲一讲电费了。当下环保意识增强，以后的论文是不是都得报告一下这部分了。

对于瓦数，用如下公式估计：

Wh = GPU-h × (GPU power consumption) × PUE

论文中，使用的是 A100-80GB，GPU power consumption 为 400W，PUE（Power Usage Effectiveness）为 1.1。

算出来瓦数后，再乘以 0.385 就是估计的二氧化碳当量：

tCO2eq = MWh × 0.385

训练模型大约花费 5 个月，2048 块 A100-80GB，所以总计消耗约 2638 MWh，1015 tCO2eq。

不知道国外的电费什么价，我查了下国内的数据中心电价，找到一篇新闻稿，说重庆数据中心年平均电价为 0.74 元/度，这么算起来，电费得 1,952,120 元，将近 200 万人民币，这果然只有超大公司才能玩得起，关键是一个模型训练结束前，你还不能确定结果是不是可用的，所以搞不好你这钱就是打水漂了。而且这还不算 2048 块 A100 的钱。

结语

要搁以前，我感觉这种论文可能都发表不了，或者说热度达不到这个程度。创新点几乎没有，几乎就是堆砌已有技术，然后自己整理下数据集，跑一下。但是在当前 ChatGPT 闭源的情况下，大家都希望有一个开源平替来把玩儿，而且得尽量小。讲到这，其实论文标题就直接点明了重点：

LLaMA: Open and Efficient Foundation Language Models

我是 open 的，而且 efficient（小），一个 foundation model，你们可以继续在这个基础上进行开发。效果虽然比不上 ChatGPT，但是这已经达到了大家的目的了。但是回过头来再看为什么能有这个效果呢？论文中没有做过多讨论，所做的那些优化改动我感觉也不痛不痒，说到底还是数据质量最重要（没错我是数据派）。

END

日常开发的时候，我们可能经常需要同时运行或维护多个程序（服务），时间一长可能就记不住了，运行命令都不一定能记得。而且一旦服务器崩了或者其他意外情况，这些服务还得手动去启动，很是麻烦（当然你也可以使用 init 等来设置开机自启）。这时就需要一个页面来统一管理了。

Supervisor 登场！

Supervisor 是一个用于管理和监控进程的工具，使用 Python 开发，可以确保在出现意外情况时，进程能够持续运行，并在失败后自动重启，通常用于监控服务器进程，如 Web 服务器和应用程序服务器。

Pros：

1. 自动重启：当进程意外退出或崩溃时，Supervisor 会自动重启进程，确保进程持续运行，减少因意外情况导致的服务中断时间。
2. 监控和日志：Supervisor 可以监控进程的状态，并提供详细的日志和报告。
3. 配置简单：配置文件采用 INI 格式，使用简单，可以根据需要定义进程的启动命令、运行参数、日志路径等。
4. 多进程管理：Supervisor 可以同时管理多个进程，可以方便地添加、删除和管理多个进程。
5. Web 界面：Supervisor 提供了一个简单易用的 Web 界面，用户可以通过浏览器直观地查看和管理进程，包括启动、停止、重启和查看日志等操作。

Cons：

1. Web 界面过于粗糙，只有启停、查看日志等操作，进程 CPU 占用、内存使用等都没有。

不过说起来这是我第二次使用 supervisor 了，第一次还是几年前，东西都忘了。这次使用的时候查了好多资料才正常跑起来，所以为了方便下一次使用，以及有需要的同道们，特此记录一下，后面有什么新的需要记录的再更新。

安装

Supervisor 是一个 python package，所以对 pythonista 来说，安装方式再熟悉不过了：

1

pip install supervisor

配置

配置文件用来配置 supervisor 本身的一些设置以及你要添加的程序，一般叫 supervisord.conf 。如果你启动的时候没有用 -c 来指定配置文件的地址，那么 supervisor 会自动按照以下顺序来寻找：

1. ../etc/supervisord.conf (Relative to the executable)
2. ../supervisord.conf (Relative to the executable)
3. $CWD/supervisord.conf
4. $CWD/etc/supervisord.conf
5. /etc/supervisord.conf
6. /etc/supervisor/supervisord.conf (since Supervisor 3.3.0)

可配置项很多，我一般不会从头写，都是基于默认配置来修改。我们可以用 echo_supervisord_conf > supervisord.conf 来将默认配置写到 supervisord.conf 中。

下面我就讲下和默认配置不一样的地方。

inet_http_server

1
2
3
4

[inet_http_server]         ; inet (TCP) server disabled by default
port=*:9001        ; ip_address:port specifier, *:port for all iface
username=your_username              ; default is no username (open server)
password=your_password               ; default is no password (open server)

这个 section 与后面的 web 界面以及 supervisorctl 与 supervisord 的通信有关。默认是只能本地连接（localhost），而且没有用户名密码，如果需要从其他服务器上访问 web，那么则需要使用 * 来指定允许所有 ip 访问。为了安全考虑建议设置用户名密码。

supervisorctl

1
2
3
4
5

[supervisorctl]
serverurl=unix:///tmp/supervisor.sock ; use a unix:// URL  for a unix socket
serverurl=http://127.0.0.1:9001 ; use an http:// url to specify an inet socket
username=liyajun              ; should be same as in [*_http_server] if set
password=liyajun123                ; should be same as in [*_http_server] if set

这里就是配置 supervisorctl 与 supervisord 通信的地方。主要是 serverurl （端口）与用户名密码需要和上面配置的一致，否则会出现拒绝链接或者认证失败的错误。

program:x

1
2
3
4
5
6
7
8
9
10

[program:your_program_name]
command=your_program_run_command
process_name=%(program_name)s
directory=your_program_run_dir
autostart=true
autorestart=unexpected
redirect_stderr=true
stdout_logfile=your_program_log      ; stdout log path, NONE for none; default AUTO
stdout_logfile_maxbytes=50MB   ; max # logfile bytes b4 rotation (default 50MB)
stdout_logfile_backups=10     ; # of stdout logfile backups (0 means none, default 10)

这个 section 就是重头戏了，我们在这里配置需要启动的程序，一个配置文件可以有多个这个 section。

• [program:your_program_name] ：your_program_name 就是你的程序名字，想叫什么就叫什么，别太离谱就行。
• command ：你的程序的执行命令，你平常怎么执行的这里就怎么写，但是 executable 最好写绝对地址，比如你用 python app.py 来执行程序，那么这个 python 最好写成绝对地址，尤其你有多个 python 环境时。你可以用 which python 来查看绝对地址。
• process_name ：默认就是程序名（your_program_name），这个名字会在 web 界面上显示。
• directory ：指定运行时需要 cd 到的目录（工作目录），也即你的程序文件所在的目录。
• autostart ：是否在 supervisord 启动时启动程序。
• autorestart ：是否在程序退出时自动重启。有三个值可选：
  • false ：不自动重启。
  • unexpected ：默认值。当 exit code 不在预料之内时，重启。什么叫不在预料之内？这个值是由 exitcodes 指定的，默认为 0。
  • true ：无论如何都自动重启。
• redirect_stderr ：是否将 stderr redirect 到 stdout。
• stdout_logfile ：stdout 日志文件。
• stdout_logfile_maxbytes ：单个日志文件的最大大小。
• stdout_logfile_backups ：保留多少份日志文件。

启动

1

supervisord -c supervisord.conf

更新配置文件

当我们更新了配置文件后，需要让 supervisor 也更新一下，我在网上查到的说是需要先 reread 再 update，但是我查询了文档，文档是这么写的：

reread：

Reload the daemon’s configuration files, without add/remove (no restarts)

update：

Reload config and add/remove as necessary, and will restart affected programs

很明显 update 已经做了 reread 的工作，而且还会 restart。

所以更新配置文件后，只需执行 update 即可更新 supervisor：

1

supervisorctl update

如果你的配置文件移动了位置，那么需要重启 supervisord：

1. 查询 supervisord PID：supervisorctl pid 。
2. 杀死 supervisord 进程：kill supervisord_pid 。
3. 用新配置文件启动 supervisord：supervisord -c new_supervisord.conf 。

Web 管理界面

前面提到过有一个 web 管理界面，根据 inet_http_server 的配置，使用相应的 ip 和端口在浏览器上访问即可，默认是 9001 端口。界面样式如下：

Supervisor web 管理界面。

在这个界面上可以看到所有已配置程序的状态，可以启停和查看日志，直接点击 Name 列可以查看最后几行的日志，而点击 Tail -f * 可以看到实时日志，不过这个在我这里特别慢，不知道为社么。

supervisord 与 supervisorctl

刚才我们用了 supervisord 和 supervisorctl 两个命令，你可能会疑惑这两个有什么区别。其实我们一般使用的时候，用前者启动 supervisor 主程序，用后者来管理我们自己所添加的 program。所以 supervisord 就像个后台的 server，而 supervisorctl 是一个前台的 client，有很多 action（subcommand）可以执行，比如上面的 update 和 reread 就是两个 action。而 supervisord 是没有的。

supervisorctl 常用的 action 有：

• status ：查看 program 状态。
• update ：更新配置文件并重启相关 program。
• pid ：获取 supervisord 的 PID。

其他不是很常用，感兴趣的可以去文档查看。

END

问题

我一直有个想法是在我家的小米电视上看 YouTube，之前都是手机上下载专门用来投屏 YouTube 的软件（Tubio），缺点是操作稍显复杂，清晰度不能选择，字幕投不上。经过前几天在电视上折腾小白网盘、电视家等经验，这次就想再来试下实现这个想法。

解决方法

按理来说，想要看 YouTube，就需要电视上装一个 VPN 软件和 YouTube。电视也是基于 Android 系统做的，所以还比较好实现。VPN 软件我们就可以使用和手机上一样的 ssr 或者 clash。我大概讲下我测试的两种方法。

方法1：SSR + SmartTube

这个方法是我看网上传的最多的，但是首先说下这个方法我失败了。

SmartTube（GitHub）是一个专门用于在电视上观看 YouTube 的免广告应用，那为什么不用官方的 YouTube app 呢？因为官方的需要依赖 Google 服务框架那一套东西，比较麻烦，而这个 app 是不需要的。其有 stable 和 beta 两个版本，下载 stable 即可。

1. 下载 SSR apk 和 SmartTube apk 到 U 盘上，然后插到电视上，分别安装。
2. 配置好你的 SSR，测试下看能不能正常连接。我的就在这步卡住了，根本连接不了，订阅是更新成功了，但是选择节点后测试失败。
3. 假设你上一步成功了，安装并打开 SmartTube，能正常加载首页就表示成功了，你也可以选择登陆自己的账号，点上方的小人根据提示操作即可。

方法 2：一台挂着梯子的电脑 + SmartTube

这个是我成功的方法，也是我认为最方便最简洁的方法，搜索的时候在一个 YouTube 视频看到的。

1. 将电脑梯子设置为局域网可访问。

   允许局域网连接。

2. 使用 ifconfig 或者梯子控制台界面找到电脑的 ip 和端口。

   查看并记住你的本机地址。
   查看并记住代理端口。

3. 在 SmartTube 上，在左侧选择 设置 ➡️ 一般 ➡️ 互联网审查 ➡️ 使用网页代理，根据提示填入刚才的 ip 和端口即可，代理类型选择 HTTP，测试一下，两个都 OK 就表示成功连接了代理。

   设置让 SmartTube 使用网页代理。
   填入 ip 和端口。

4. 确定退出回到首页，就可以看到能成功加载了。登录账号啥的和方法 1 相同，也可以选择清晰度和字幕，和电脑上几乎一样，非常方便。

   首页成功加载。

通过以上两种方法，你就可以方便地在小米电视上观看 YouTube，享受大屏幕带来的视觉效果啦～

END

问题

我想导出我的 QQ 邮箱中某个文件夹下的所有文件，eml 或者 mbox 格式都行，但是我发现 QQ 邮箱网页端没这个功能，只能一封一封导出为 eml。QQ 邮箱也没有 Mac 或者 windows 客户端。然后我尝试用 Mac 自带邮件客户端、foxmail、outlook、thunderbird 客户端来导出，结果发现都存在一个问题：邮件不完整，似乎只能显示近一个月内的邮件。我怀疑是这些客户端的设置没弄好，但找了一圈发现没有相关设置。

解决方法

后来我再去查看 QQ 邮箱网页端的设置时发现，有个「收取选项」设置，默认为「最近 30 天」。这下就破案了，只需改为全部即可，然后在客户端刷新或重新添加账户。

修改「收取选项」为「最近 30 天」

如果你想导出 QQ 邮箱中某个文件夹下的所有文件，可以尝试这个方法：

1. 在 QQ 邮箱网页端将「收取选项」设置为「全部」；
2. 在你的电脑上下载一个支持导出邮件的客户端，例如 Mac 自带邮件客户端、foxmail、outlook、thunderbird 客户端等；
3. 在客户端中添加 QQ 邮箱账户，并选择要导出的文件夹；
4. 根据客户端的要求导出即可。

eml 和 mbox 格式

eml 格式是一种用于存储电子邮件的文件格式，其英文全称为 “email message format”。一个 eml 文件通常包括邮件的头部信息和正文内容，可以使用邮件客户端或者文本编辑器打开。下面是一个 eml 文件的简单示例：

1
2
3
4
5

From: [sender@example.com](mailto:sender@example.com)
To: [recipient@example.com](mailto:recipient@example.com)
Subject: This is a test email

This is the body of the email.

在 Python 中读取一个 eml 文件，可以使用 Python 内置的 email 模块。下面是一个读取 eml 文件并打印邮件头部和正文内容的 demo 代码：

1
2
3
4
5
6
7
8
9

import email

with open('example.eml', 'rb') as fp:
    msg = email.message_from_binary_file(fp)

print('From:', msg['From'])
print('To:', msg['To'])
print('Subject:', msg['Subject'])
print('Body:', msg.get_payload())

mbox 格式是另一种常见的存储邮件的文件格式，其英文全称为 “mailbox format”。一个 mbox 文件通常包括多个邮件，每个邮件之间用一个特殊的分隔符隔开，可以使用邮件客户端或者文本编辑器打开。下面是一个 mbox 文件的简单示例：

1
2
3
4
5
6
7
8
9
10
11

From sender@example.com Wed May 18 13:48:45 2022
Return-Path: <sender@example.com>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on example.com
...
This is the body of the email.

From recipient@example.com Wed May 18 14:03:10 2022
Return-Path: <recipient@example.com>
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on example.com
...
This is another email.

在 Python 中读取一个 mbox 文件，可以使用 Python 内置的 mailbox 模块。下面是一个读取 mbox 文件并打印每个邮件的头部和正文内容的 demo 代码：

1
2
3
4
5
6
7
8
9

import mailbox

mbox = mailbox.mbox('example.mbox')

for msg in mbox:
    print('From:', msg['From'])
    print('To:', msg['To'])
    print('Subject:', msg['Subject'])
    print('Body:', msg.get_payload())

END

前言

由于图片较多，所以将分三篇文章发出。本文是第三篇。其他两篇见第一篇和第二篇。

见第一篇前言。

北京野生动物园

北野也是一个很久之前就在收藏夹里的地方。北京有两个野生动物园，之前我还有点分不清，现在终于搞清了，一个是八达岭野生动物园，一个就是位于大兴的北京野生动物园。前者就是发生了私自下车导致被老虎拖走事件的动物园。

经过在小红书上一段时间的有针对性的冲浪，发现大家去那主要奔着两个地方：猛兽区和小火车。两者都是有优速通的，不买的话旺季（周末节假日）可能要排队几个小时，最夸张的是有个人说活排了 6 个小时……

我们这次主要奔着猛兽区，剩余的地方随便闲逛。我们早上 5 点起床，6 点出发，7 点 10 分左右到达北区停车场，南区似乎已经满了。不过南北区距离大门口都差不多。7 点 45 进入大门。

北野临时停车场之一。在快到北野的时候，路上有好几个这种牌子，应该是南区北区停满之后就要往这里引导了。之前看公众号上说南区北区 + 临时停车场总共有大概 8000 左右车位，可太夸张了。

排队安检。注意抖音买的票需要换票，携程等买的不需要。

大门。

接下来就是直冲猛兽区了。先说下排队盛况，排队确实是无限回形针。先是木栈道排队，然后进入蓝房子（河马馆），此处大概要拐六七道。然后通过一个羊肠小道进入一个大型回形针区域，此处大概要拐十几道。然后进入最后一个区域，此时需要存车了，到这就快了，同样是回形针区域，慢慢排就是了，上面屏幕上可能会写“此处排队时间 60 分钟”之类的的话，这个预估似乎偏大。

木栈道排队。

河马馆排队。里面真的有河马，所以味道很冲。

曙光。到这里就快了，准备好钱买肉吧！

笼车和肉。一杯 50，包括牛肉和鸡肉。9 点 40 左右坐上车，排队一个小时四十分钟左右。

网上总有人说坐哪边猛兽多之类的，但左右都差不多，棕熊区右边看到的是湖水，左边是瀑布。其他动物左右均有，司机也会提醒动物在哪一边。你也可以站起来去有动物的一边拍照喂食。司机也会讲解提醒哪个动物喜欢吃什么肉。

棕熊区。就是围着这个小池子转，每辆车都会在图中蓝色和粉色车子那里停，大概得个十几分钟。水里陆地都有棕熊。有电网限制它们的活动区域。

棕熊。棕熊是主要的食物消耗者，有的棕熊只吃牛肉，不吃鸡肉。司机会建议你能喂多喂，到后面你可能肉都抛不出去了。

棕熊信步。从后门拍摄。

水虎。非常幸运，这只老虎最后从水里出来找我们要肉了。

白虎。由于其毛色在野外太扎眼，据说已经没有野生白虎了。

夹着尾巴跑的狼。

工作车。这车是早晚用来释放和回收动物的。那它现在怎么停在这？据司机说，可能是因为这些狼之前在打架，他们害怕这些车，也就是在它们眼里这个车就是狼王，狼王一来都不敢动了，起一个震慑作用。

黑熊。

狮子。

唯一在动的猎豹。

然后就从猛兽区出来了。出来后有个餐厅，里面是只能在他们那买东西之后才能坐，外面是都可以坐。

未知蓝房子。似乎是一个剧场，很多人在这里拍照，容易出片。

犀鸟。在这个屋里扑棱扑棱从这头飞到那头，有点怕扑棱到自己哈哈哈。

惠风和畅。

怡然自乐。这两张图让我想起了日本那个景点，也是两边都是这种红色柱子。

奇妙旅程票价。

犀牛。

大象喂食。每人 30，旁边的那个细白线是电网。

长颈鹿。喂食价格同上。

小熊猫馆。人很多，要来的话趁早。

顺便说几个关于熊猫的冷知识：

1. 小熊猫和大熊猫没有关系。
2. 小熊猫比大熊猫更为“濒危”。
3. panda 最初指小熊猫，而大熊猫叫 giant panda 。
4. bearcat 指另一个物种熊狸。
5. 猫熊比大熊猫更准确。

树人。门口有很多“参天大树”。

有趣的狐獴。

说个题外话，Mac 自带输入法似乎打不出「獴」字。

有趣的狐獴 2。

北线游览区结束点。

霸王龙与火烈鸟。火烈鸟真的很好看，强烈推荐，北京动物园里有个火烈鸟展区，超漂亮！

水乡。

全程轨迹图。海拔在 20 米左右（忽略后面那段）。

END

前言

由于图片较多，所以将分三篇文章发出。本文是第二篇。其他两篇见第一篇和第三篇。

见第一篇前言。

野鸭湖国家湿地公园

野鸭湖在北京的西北方向，金海湖则是东北方向。根据维基百科的介绍：

野鸭湖国家湿地公园位于北京市延庆区西南部的延庆镇、康庄镇)、张山营镇和延庆农场交界处，总面积283.4公顷，具有水库、河流、沼泽、季节性泛滥地等多种湿地类型，是北京地区湿地面积最大的湿地生态系统和北京唯一一家国家级湿地公园。

前面提到这一天本来不是去这里的，而是去北野，但可惜没抢到这一天的优速通（实测也没必要抢优速通，下面再说）。这个地方也是之前在小红书种草的，后来查了查感觉也还可以（主观感觉因人而异），而且门票也不算贵，正好还有个亲鹿苑，可以零距离喂小鹿🦌，所以就去了这里。

小红书上提到这里，基本就是一个瞭望塔的图，很多人说这里上不去了，也就没去的必要了。但是出来就是来溜溜的，上不上去的无所谓。

从停车场走向景区。景区大门还在前面一点，这个区域挺空旷的，出来的时候风巨大，很多人帽子都吹掉了。两边是鸟类的装饰。我们到这里大概是 9 点，没想到一个区域的停车场就已经停满了，本来以为应该没这么多人，大家到得都挺早的。

景区大门。

景区大门前的小路。这条小路两边的树长得很好，路上全是阴凉地。

门口的“氛围组”。正巧遇到他们在门口，他们应该是为门口剧场的表演宣传的，同时增加一些游园乐趣。后面在景区里也看到了他们，沿着湖边走。话说最近这小青蛙挺火的啊。

亲水平台上的表演。在原来氛围组的基础上又加了一些演员，这些演员应该就是剧场演出的演员。挺辛苦的，大太阳下晒着没有一点遮挡，大部分是女生。表演是 10 点半有一场，他们在正式表演前给大家来了个“预告片”。主持人一直说大家尤其是带着孩子的可以上去和演员们一起唱跳 rap（bushi），一起互动拍照，说白了就是气氛搞起来！

演员与小鸭。后来发现，这群鸭子应该是我在景区里见过最多的鸭子了，好像不太对得起野鸭湖这个名字……

巡游中的氛围组。呼应前文……

亲鹿苑大门。30 一位，实际上就是喂食包的钱，里面是萝卜和白菜。

小明星。这只带犄角的小鹿算是里面的小明星了，大家都爱喂它吃，因为它有犄角？

山桥水。这个桥似乎是通往一个小岛，岛上有烽火台遗址和船台（坐船的地方？）。

来张广角的。景区里有大量芦苇。

芦苇。附近蛙声一片。

景区全景图。可以看到基本上就是围着湖转一圈，可以租赁电瓶车或者自行车。前文提到的瞭望塔就在左上角。

木栈道。湖边基本上都有这种木栈道，不过天热的时候可太晒了，飞虫应该也多。

风车 1。这里应该是官厅水库区域，牌子上写的是康西草原，没开放不让进，但是我看里面有玩车的。

风车 2。这一片都是风车。

瞭望塔。这个就是传说中的瞭望塔，距离我这拍摄地还有好远一段距离，也是没开放的。

广角湖面。这小米 11 ultra 的相机滤镜可太强了，关掉滤镜还是这样，饱和度过高，颜色严重失真。

一张特写的飞机云。恰巧那天碰见了，在蓝天的衬托下显得格外漂亮，我的最爱。

瞭望塔近景。

官厅水库。现在看到的这片水域应该就是官厅水库了。照片同样由我们夸张的小米 11 ultra 贡献。

湖中间的木栈道。这一条长长的木栈道位于湖中间，可以直接从半路穿湖到达对面亲水平台和门口。这条栈道感觉有点年久失修，有些地方翘起来挺危险的，没有任何护栏。走在上面风贼大。

结束。这纯走一圈还真挺累的。

全程轨迹图。海拔明显高了，大概在 480 米左右。

END

前言

由于图片较多，所以将分三篇文章发出。本文是第一篇。其他两篇见第二篇和第三篇。

今年五一是疫情放开后第一个较长的适合出去旅游的节假日，五天的假期相信很多人都会出去走一周，释放一下被三年疫情憋坏的心情。我们也不例外，不过我们出去主要的动机是带着孩子出去走走，而不是疫情原因。

放假前就看到很多假期人会很多的新闻，比如北京交通委说预计五一假期北京出行规模将超 2023 年春运，同时也超过 2019 年同期水平，说明已经基本恢复到疫情前水平了。小红书等平台上那些景区游客爆满的新闻也比比皆是。

所以我们决定不走这些类型的景点：

• 热门
• 外地游客常去
• 公共交通方便
• 市区
• 需要爬山的

当然有些要求是 soft 的，不那么死，视情况而定。为了避免假期第一天和最后一天的“盛况”，我们也决定这两天待在家里休整，中间三天出去。

这么筛选下来，基本就是北京周边三日亲子游了，这些地方外地游客一般不会去，人应该相对较少。所以做了一番调研后，初选出以下景点：

• 4 月 30 号，北京金海湖风景区
• 5 月 1 号，北京野生动物园
• 5 月 2 号，天津东疆亲海公园

但是北野人肯定会很多，所以我们计划抢猛兽区优速通。但是我半夜 12 点没抢到，感觉不到 10 秒就没了，太夸张了。遂第二天半夜 12 点继续抢 2 号的，这次多叫了几个人，虽然抢到了，但是是中午 12 点的。这个点动物们都基本上吃饱睡觉午休了，所以点不太好，所以我们打算那天去早点，然后排队看看情况。

所以最终行程变为了：

• 4 月 30 号，北京金海湖风景区
• 5 月 1 号，野鸭湖国家湿地公园
• 5 月 2 号，北京野生动物园

我先说下这几天的总花费，四大一小，租车 + 油费 + 门票 + 吃喝 + 其他费用，无住宿，大约 300 元/人/天（不算一小）。

接下来谈一谈对这几个景点的感受。

北京金海湖风景区

先来一段百度百科的介绍：

金海湖风景区，又称海子水库，位于北京市平谷区城东18千米处金海湖镇上宅村南，距北京85千米，位于北京、天津、唐山交界处的三角地带，素有”小北戴河”之称。据平谷区志记载，在清康熙十八年（1679年），平谷、三河发生了一次大地震，从而形成了河峡谷。1959年，初建。1985年，金海湖水库辟为旅游区，称金海湖公园。1988年，更为金海湖风景区。金海湖风景区总面积22平方千米，其中建筑面积0.8平方千米，水域面积6.5平方千米。金海湖风景区西依金海湖大坝，三面环水，三面青山环绕，四面飞檐明柱，有千岛湖的湖观山色，湖光塔、金花公主墓、望海亭、锯齿崖等自然景观、人文景观数十处。有游船、快艇、帆船、脚踏船、电瓶船、赛龙舟等娱乐项目。

之前在社交平台上听说过好几次这里了，一直想去看看，但是鉴于太远就没去，但这次正好符合我们的要求。实际上去之前我也不太清楚有啥可玩的，就知道有个毕加索坝体彩绘，还有大片水域，快艇帆船啥的。但是我们是带着孩子出行，对她来说，一切都是新鲜的。

为了避免堵车，我们早上 6 点左右起床，7 点出发，大约 9 点半到达。下面就跟着照片游览一下吧～

景区全景图。靠中间画着四个红色枫叶🍁的地方叫锯齿崖，著名景点，但是我们去的时候没开放。

坝体彩绘就是后面那个红色的斜坡，前面的这块大草坪是露营区域，收费，100 元/人。

景区里的一个小饭馆。

走上坝有两个选择：爬楼梯（路短省时间、费力）和坐扶梯（绕路、省力）。我们带着孩子而且第一次去就跟着人群走了，后来返回的时候才知道有爬楼梯这个选项。

扶梯上坝路线，坝的西面（左）就是彩绘。

上坝之后向西看。

上坝之后向东看，左上方是蹦极的，那天还真见到有人玩。照片是 Google 相册自动风格化后的。

蹦极跳完后，绳子会慢慢放下，把人放到这上面，那个戴帽子的会接游客下来。

顺着坝一直往前走，就到了金花公主墓：

金花公主墓。

站在去往金花公主墓的走廊上看金海湖大坝。

登上游船去往桃花岛。这是去桃花岛的唯一方式。还有一个碧波岛，打听了才知道从景区内过不去，得从景区外另一个门进去，但是票是一次性的……平常碧波岛应该是可以坐这个游船过去的。船票 130 每人，最后你网上订票的时候订游船 + 门票的联票，因为这个联票价格也是 130。在这里排队人很多，由于工作人员工作不到位（排队方式不清晰），导致我前面的游客还跟工作人员吵了一下。

到达桃花岛。这里露营似乎也是收费的。我看到一家人正在搭帐篷，然后走过来一个拿个牌子的工作人员跟其交谈，后来那家人就把帐篷收起来了。这个岛上除了大片草地，还有卖小吃的、小型动物园（鸵鸟、孔雀和兔子等）、小型游乐场。哦对了，这里的烤肠 5 元/根，而景区入口的 10 元。

金海湖帆船。价格和游船差不多，但是好像很少有人坐，大部分人坐游船，其次是快艇。

在坝上看景区入口那块露营地。

全程轨迹图。可以看到海拔不是很高，也就 100 米左右。

END

前言

当我们使用 pandas 的 read_excel 方法读取 Excel 文件时，我们可能会遇到一个很棘手的问题：如何正确读取包含合并单元格的 Excel 表格。如果我们只是用原先的 read_excel 方法读取，那么合并单元格的信息将会丢失，从而导致我们的数据出现重复或缺失的情况。我看了下网上的文章几乎都没有很好的解决办法，大部分都是用 fillna 之类的方法去填充，很明显这是不行的，下面我会举例说明。唯一看到一篇方向正确的文章，但是却稍显繁琐，还要先存一个中间文件再读取。

在本篇文章中，我们将会探讨如何使用 pandas 正确地读取包含合并单元格的 Excel 表格，简单高效全面，同时支持 xlsx 和旧格式 xls。

本篇文章使用两个内容相同、格式不同的文件来演示说明。内容截图如下：

样例文件

可以看到里面有纵向合并（一班、二班、三班），有横向合并（钱一的语文和数学），也有横纵合并（二班三班的语文数学）。

fillna 的问题

当我们直接使用 read_excel 读取时，会变成下面这个样子：

填充失败

可以看到合并单元格没有被正确填充，除了第一个单元格外其他都是 NaN ，而我们期望的是它们都用相同值填充。

当然我们可以使用 fillna 来实现，不过该方法只能是“具体情况具体分析”，横向、纵向、横纵合并单元格的情况都要根据情况用不同的 fill method，在这里我们至少需要分三种情况来进行处理，显得非常繁琐。一旦变了表格，你的代码就得变，普适性太差。

按理说，Excel 本身应该保留了合并单元格的信息，比如哪些单元格被合并了，它们的值是什么。应该存在一种工具可以读取出这种信息。

So，这就是 openpyxl 和 xlrd 派上用场的时候了。

Solution

pandas 内部实际上也是用的这两个包。根据官方文档：

enginestr, default None

If io is not a buffer or path, this must be set to identify io. Supported engines: “xlrd”, “openpyxl”, “odf”, “pyxlsb”. Engine compatibility :
• “xlrd” supports old-style Excel files (.xls).
• “openpyxl” supports newer Excel file formats.
• “odf” supports OpenDocument file formats (.odf, .ods, .odt).
• “pyxlsb” supports Binary Excel files.
Changed in version 1.2.0: The engine xlrd now only supports old-style .xls files. When engine=None, the following logic will be used to determine the engine:
• If path_or_buffer is an OpenDocument format (.odf, .ods, .odt), then odf will be used.
• Otherwise if path_or_buffer is an xls format, xlrd will be used.
• Otherwise if path_or_buffer is in xlsb format, pyxlsb will be used.
New in version 1.3.0.
• Otherwise openpyxl will be used.
Changed in version 1.3.0.

简单来说，默认情况下（engine=None）：

• 如果是 OpenDocument 格式的文件，那么使用 odf 解析。
• 如果是 xls 格式，那么使用 xlrd 解析。
• 如果是 xlsb 格式，那么使用 pyxlsb 解析。
• 其他格式都使用 openpyxl 解析。

原先这些包是可以读取合并单元格这种格式信息的（虽然文档很不完善），但是经过 pandas 后不知道怎么回事就没了。所以这里我们就显式地用这些包来读取和操作。

总体思路就是：

1. 用相应的方法读取 Excel 文件，得到 workbook。
2. 根据 sheet name 取 sheet。
3. 解析这个 sheet，得到 dataframe。
4. 获取合并单元格及值和范围。
5. 根据范围，在 dataframe 中设置相应值。

完整代码如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

import pandas as pd
from openpyxl import load_workbook
from xlrd import open_workbook

def read_xlsx(file, sheet_name=None, header=None):
    """读取 xlsx 格式文件。"""
    excel = pd.ExcelFile(load_workbook(file), engine="openpyxl")
    sheet_name = sheet_name or excel.sheet_names[0]
    sheet = excel.book[sheet_name]
    df = excel.parse(sheet_name, header=header)

    for item in sheet.merged_cells:
        top_col, top_row, bottom_col, bottom_row = item.bounds
        base_value = item.start_cell.value
        # 1-based index转为0-based index
        top_row -= 1
        top_col -= 1
        # 由于前面的几行被设为了header，所以这里要对坐标进行调整
        if header is not None:
            top_row -= header + 1
            bottom_row -= header + 1
        df.iloc[top_row:bottom_row, top_col:bottom_col] = base_value
    return df

def read_xls(file, sheet_name=None, header=None):
    """读取 xls 格式文件。"""
    excel = pd.ExcelFile(open_workbook(file, formatting_info=True), engine="xlrd")
    sheet_name = sheet_name or excel.sheet_names[0]
    sheet = excel.book[sheet_name]
    df = excel.parse(sheet_name, header=header)

    # 0-based index
    for top_row, bottom_row, top_col, bottom_col in sheet.merged_cells:
        base_value = sheet.cell_value(top_row, top_col)
        # 由于前面的几行被设为了header，所以这里要对坐标进行调整
        if header is not None:
            top_row -= header + 1
            bottom_row -= header + 1
        df.iloc[top_row:bottom_row, top_col:bottom_col] = base_value
    return df

我们再次用这两个函数读取一下示例文件：

读取 xlsx 格式文件。

读取 xls 格式文件。

可以看到 xlsx 和 xls 格式文件都能正确读取，同时支持指定 sheet name 和 header。

需要注意的问题

1. 如果原先的合并单元格内容为空，那么 openpyxl 的结果会是 None ，而 xlrd 仍然是空字符串。
2. openpyxl 的 merged_cells 方法似乎在文档中并未出现，忘记了在哪看到的这个方法。

Reference

• API Reference — xlrd 2.0.1 documentation

END

Introduction

在进行大规模数据爬取和下载时，经常需要下载大文件，这时候就需要一个可以显示下载进度和速度的工具，以便于我们能够更好地掌控下载的情况，同时也可以避免下载过程中出现问题导致浪费时间和流量。

因此，我们需要一个可以显示下载进度和速度的工具，以便于我们更好地掌控下载的情况，避免浪费时间和流量。

本文将介绍在 Python 中如何使用 tqdm 和 requests 来实现下载进度和速度的显示。

How

要使用 tqdm 和 requests 来显示下载进度和速度，我们需要先安装 tqdm 和 requests 模块。安装方法如下（如已安装请跳过）：

1

pip install tqdm requests

安装完成后，我们可以使用以下代码来下载文件并显示下载进度和速度：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

from pathlib import Path

import requests
from tqdm import tqdm

def download(url, folder="./", headers=None) -> str:
    """下载文件并显示进度和速度。"""
    Path(folder).mkdir(exist_ok=True, parents=True)
    local_filepath = Path(folder) / url.split("/")[-1]
    headers = headers or {
        "user-agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/111.0.0.0 Safari/537.36"
    }
    with requests.get(url, stream=True, headers=headers) as r:
        r.raise_for_status()
        size = int(r.headers["Content-Length"])
        chunk_size = 8192
        # 重点。
        with tqdm(
            unit="B",            # 1
            unit_scale=True,     # 2
            unit_divisor=1024,   # 3
            miniters=1,          # 4
            desc=f"Downloading {local_filepath.name}",  # 5
            total=size,          # 6
        ) as pbar:
            with open(local_filepath, "wb") as f:
                for chunk in r.iter_content(chunk_size=chunk_size):
                    f.write(chunk)
                    pbar.update(len(chunk))  # 7

    return local_filepath

这段代码的核心是 tqdm，我们使用 tqdm 来创建进度条，然后在循环中更新进度条，实现了下载进度和速度的显示。详细解释如下：

1. unit="B"：将进度条的单位设置为字节。
2. unit_scale=True：开启自动缩放功能，根据文件大小自动转换为 KB、MB、GB 等单位，默认是用 SI 公制单位（即 1000 进制），如果想使用二进制单位，则可以指定下面的 unit_divisor 。
3. unit_divisor=1024：设置单位缩放的除数为1024，即二进制单位。
4. miniters=1：设置进度条更新的最小步数。对于小文件，进度条可能会更新得太频繁，这个参数可以控制更新频率。
5. desc="Downloading"：设置进度条的描述。
6. total=size：设置要下载的文件的总大小，这个值从HTTP响应的 Content-Length 头部获取。
7. pbar.update(len(chunk))：更新进度条，显示已下载的数据大小。len(chunk)表示当前下载的数据块大小（单位为字节）。

效果如下：

效果图。

Alternative

又是设置一堆 tqdm 参数又是需要在循环中增加 update 语句，可能有些人会觉得稍显麻烦，有点侵入性，那我这里有一个不那么麻烦的的近似方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

def download(url, folder) -> str:
    """一个近似方法。"""
    Path(folder).mkdir(exist_ok=True, parents=True)
    local_filepath = Path(folder) / url.split("/")[-1]
    if local_filepath.exists():
        logger.warning(f"{local_filepath} exists, skip.")
        return local_filepath
    with requests.get(url, stream=True, headers=headers) as r:
        r.raise_for_status()
        size = int(r.headers["Content-Length"])
        chunk_size = 8192
        # 重点。
        n_chunks = (size + chunk_size - 1) // chunk_size
        with open(local_filepath, "wb") as f:
            for chunk in tqdm(
                r.iter_content(chunk_size=chunk_size),
                total=n_chunks,                # 1
                unit="KB",                     # 2
                unit_scale=chunk_size / 1024,  # 3
            ):
                f.write(chunk)
    return local_filepath

这个程序只需要在原来的 r.iter_content() 外像平常一样包一层 tqdm，然后设置较少的参数即可，省掉了一些参数和 update 语句：

1. total=n_chunks：由于我们是分块下载的，一个很明显的思路是 total 我们只需要设置为总的块数即可，和深度学习中的 batch 类似。
2. unit="KB"：这里我们门强制让其使用 KB 为单位，而不是自动转换。
3. unit_scale=chunk_size / 1024 ：由于 total 设置的是块的数量，默认速度就会显示每秒多少个块，但是我们想让其显示每秒多少 B 或者 KB 之类的，这里我们就用这个参数来让块数 ⨉ 块大小得出来 B 数，然后再除以 1024 的到 KB 数。如果你想得到 MB 数，只需再除以 1024，并设置 unit="MB"即可。

为什么说这是“近似”做法呢？这是因为我们 unit_scale 直接乘的是块大小，然而每次得到的数据量并不一定是块大小这么大，最后一个块可能会偏小。道理很简单，把 10 按块大小为 3 拆分，最后一个块大小为 1。但是由于我们的块大小不会太大，这个影响微乎其微。

Thoughts

进度和速度显示可能是很多程序员忽略的一个问题，但是我觉得非常重要，可以说 you always need ETA(tqdm)。但是在使用的时候要注意刚开始的速度可能并不准确，尤其是任务队列中的处理时间不尽相同时。

Reference

• tqdm.tqdm - tqdm documentation
• tqdm/tqdm_requests.py at master · tqdm/tqdm · GitHub

END

问题

前段时间我在跑数据批处理任务时，发生了一件怪事：client 部署在 CPU 服务器上，server 部署在 GPU 服务器上（模型），client 处理过程中会向 server 发请求。执行了一段时间后通过监控发现，client 这边的 CPU 和 server 这边的 GPU 利用率都不满，client 那边几乎可以忽略不计，server 那边只有 40% 左右。这是为什么？谁在消耗时间？正常情况下 server 应该是满的。

尝试和解决

先来大致说下数据批处理流程。流程分为两部分：client 和 server。client 主要负责整个数据处理流程，其中包括向多个模型服务发起请求，不涉及 GPU，部署在 CPU 服务器上。server 就是模型服务，部署在 GPU 服务器上，负责 load 模型和 inference。开始处理的时候，会临时起多台 GPU server，然后上面加一层负载，client 就用这个负载地址来请求 server。

那天在启动任务开始处理的时候，已经有其他任务在用 server 了，而且是同一个负载地址。我们在启动这个新任务的时候，为了满足计算需求，直接往这个负载下加了 10 台 GPU server。然后启动 client，任务开始。

启动后 client 的情况：

启动后的 client htop。

server 情况：

启动后的 server GPU 利用率。

server 这边显示的是所有服务器的 GPU 的情况，包括旧任务的，而且此时旧任务还没有完成。但是新任务一开始基本就出现了利用率的下降，请求量也出现了下滑（但是没有利用率那么明显）：

负载请求量。

从日志中可以看到旧任务一些进程已经结束了，但是也不至于出现这么大的波动。这就很奇怪了，为什么新任务一开始 server 那边就打不满了呢，按理说应该更满才对，而且请求量也没上去，反而跌了。

我先是用 py-spy 检查了其中一个进程到底在干什么，这个工具的一个重要功能就是可以检查处于运行状态下的进程在干什么。结果如下：

py-spy 结果。

可以看到，时间基本都消耗在了网络相关函数上，比如 readinto (sockent.py) 、send (requests/sessions.py) 、urlopen (urllib3/connectionpool.py) 、begin (http/client.py) 和 _make_request (urllib3/connectionpool.py) 。很明显，问题出在网络上。正常情况 BeautifulSoup 相关操作应该占比较大一部分。

运维测试了下网络，延迟很低，网络很通畅……

然后我在监控中看到 server 镜像版本是旧的，而且这个旧镜像是有问题的，根本启动不起来。从监控中也可以看到这几台 server 利用率一直是 0，也就是说根本没收到请求。如果 server 没起来，那么负载应该是不能连接的，但我在 client 这边并没看到负载连接失败的报错，而且我在 client 程序最前面加了一个负载连接测试，不通过会直接 raise error，程序就会退出，而现在程序是正常运行的。这是为什么呢？还记得前面说过这个负载是和旧任务共用的吗，问题就在这里，这里实际上用的还是旧任务的 server，所以不会出现连接错误。

把这个问题解决了后，问题依旧，server GPU 利用率稍微降低了些，但波动很小：

解决 server 镜像问题后的 GPU 利用率。

尽管大家觉得还是很离奇，但是当时时间很晚了，大家建议尝试增加 client 这边的并行核数（joblib 的 n_cores），毕竟 client 这边不满 server 也不满的另一个可能的原因是并发不够，同时打出去的请求不够多。

后来的小时测试发现速度增加了 5 万/小时，但是不知道这是谁的功劳，或者说这个速度是不是存在水分都不一定，因为我不是特别确定之前的速度。由于时间很晚了，这件事暂且告一段落了。

后来同事向我反馈线上 api 总是超时，之前不会。我进去看了下日志发现是有个子任务超时了，进一步发现 dev 服务器上的 GPU 特别满，按理说应该不可能，请求的人没那么多。这时我突然想到，为了方便在负载地址和 dev 地址之间切换，我在配置文件里区分了 prd 和 dev，批处理数据时需要先用如下语句来初始化配置：

1

config = Config('prd')  # or 'dev'

这个语句在两个程序中会出现，我突然想到我在其中一个程序中似乎还是用的 dev ，有可能会导致批处理用了 dev 服务器上的模型服务。进去一看，果然！

这就解释了为什么 client 和 server 都很闲：

• client 很闲是因为 dev 服务器忙不过来，瓶颈在 GPU 这边，即使增加 client 核数也没用；
• server 也不忙是因为一部分请求根本没发到负载。

但是为什么 server GPU 利用率下降了那么多，只能用旧任务一些进程结束来解释了，当然负载可能也存在问题（后来决定按照任务来生成不同的负载地址，做一下隔离，能避免如服务器没起来但负载仍可以连接的情况，也可以更好地看到不同任务地情况）。

改成 prd 后 client 这边 CPU 正常了：

修正后的 client htop 结果。

总结

经过这件事，意识到几点：

1. 特别注意配置文件中的配置项是否正确。
2. 配置尽量初始化一次，然后全局使用。
3. Profiling 工具很重要，尤其是能 profile running program 的。
4. 尝试了很多种方法后仍然不能解决问题，卡住了，先放一放。
5. Be patient。

END

我不是一个键盘专家之类的，所以文中有些表述可能有误，欢迎指正。

开箱

被这个 nuphy air75 种草过很多次，最近又被种草了，结合最近实际及家人的支持（说是新年礼物），就在京东上和键盘皮套一起下单了。第二天就送到了，鉴于当前疫情形势，这么快的速度送到令我惊讶，尤其是和我 20 天前买的东西一起送到……

到手之后外包装是一个什么食物的箱子，具体什么我忘了，但是上面写着易碎物品，一瞬间我还以为买的其他东西到了。打开之后就是空气袋和键盘、皮套的盒子了。我不是一个二次元爱好者，所以这键盘盒的包装对我来说不是惊喜，而是有点惊吓……

键盘盒包装

把里面的包装盒抽出来，黑色主体、绿黄橙点缀，看起来挺大气：

里面的包装盒

包装盒里面是绿为主体，和键盘的 ESC 键的绿相呼应，还挺特别。

包装盒里面

里面的东西如下：

包装清单

我目前用到的除了键盘，还有就是键帽拉拔器（键盘默认是 Mac 键帽，需要替换成 Windows 键帽，不过有意思的是，默认模式却是 Win）、磁性脚垫（实际感觉垫高有限）、说明书（各种快捷键真的多），USB 线是用来有线连接、充电时使用，如果使用 nupyh console，似乎也必须有线连接，这东西主要是用来重新指派键及自定义灯光。电量显示用右侧测光灯的不同颜色来表示，刚拿到手时我看了下电量（Windows + |）还是绿的，表明电量 > 80%，用了一两天变成橙色了（20%~80%）。

话不多说，来说说优缺点。

Pros & Cons

Pros：

1. 颜值高。这是最吸引我的点。我原来用的是 ikbc F87 红轴，当然不是说原来的丑（丑我也不会买啊……），原来的简洁大方，现在的活力多彩，不捧一踩一，只是视觉上习惯了。

   ikbc F87 与 NuPhy Air75 对比。Source：自己做的。

2. 矮轴。但导致我下定决心换一个的重要因素，就是现在这个是矮轴，就是说键程短。我用 F87 用久了觉得，键程太长了，久了手累，想要普通键盘那种短键程 + 机械键盘的手感。Air75 完美符合，打起来轻松多了，不用再多敲“深”一点了，而且手感也好很多。

3. 声音小。前面说了我原来是红轴，现在这个是茶轴。买之前我在网上查了下区别，说主要是茶轴比红轴有段落感。也听了下声音，感觉上差别不是很大。鉴于我已经用过红轴了，就买了茶轴的。但实际到手用了之后发现，声音差别可太大了，茶轴的明显声音更为沉闷，更小，听起来更舒适更有感觉。
4. 小，轻。小不用说了，ikbc F87 是 87 键，air75 是 84 键，而且取消了那些不同功能区的间隔。轻很明显，拿起来感觉上轻一半，查了下具体数据，前者重 1100 克，后者 523 克，果然两倍。
5. 有线、无线、蓝牙三种连接方式。
6. 双侧侧光灯。由于键盘背光偏弱，白天正常环境亮度下几乎感觉不到背光，但是这两侧的流光灯很亮，但也不至于太过于刺眼，挺有感觉的。除了装饰，主要是用来指示状态，比如大写锁定（左侧）、电量显示（右侧）、连接状态（左侧）等。
7. 字体粗大舒适。字体明显要比 F87 粗大，尤其是主键盘区，粗得很明显，而且字体也合我口味。
8. 皮套漂亮……这个属于是败家的，花瓶。

Cons：

1. 键帽不透光。这就导致很黑的环境中你可能真的就是盲打了，不过这种情况比较少，几乎不会在很黑的环境中用电脑，不然屏幕多刺眼。

   我这是有一点环境光，很黑的环境中字几乎看不到。

2. 背光偏弱。无论是相比于 F87 还是直观感受，背光确实偏弱，尤其是白天几乎看不到，即使调到最大亮度（从关闭到最亮共 5 档，按 Fn + ↑/↓ 调节）。

3. 没有 Insert 键。Xshell 默认是 Shift + Insert 粘贴（也可以鼠标中键，但是不习惯），但是发现那边被一个 cat 键占据了，这个键是用来唤醒语音助手的，不过基本用不到，可以在 nuphy console 上重新指派为 Insert 键（目前来说不建议重新指派，见下）。

重新指派 cat 键为 Insert 键的问题

默认 cat 键用于唤醒语音助手，不过基本用不到，又缺少一个 Insert 键，所以自然而然会想将其重新指派为 Insert 键。

但是你重新指派后就会发现，F 功能键变为纯多媒体键了，例如 F1/F2 只能用来控制亮度，F2 不再能重命名，失去了原有功能。下面的操作都解决不了问题：

1. 加上 Fn；
2. 使用 Fn + TAB + F 来切换功能键模式；
3. 在 console 中恢复出厂设置；
4. 重启电脑。

其实这是一个 known issue，可以在 nuphy console v1.0.2 的 CHANGELOG 中看到，同时在官方 discord 中也看到了相关回复，说等 v1.0.2 发布就可以了，但没说啥时候发布。

最终我在 discord 中看到一个人的回复说可以尝试长按 Fn + TAB + R 来 reset。我尝试之后发现确实可以，解决办法如下：

长按 Fn + TAB + R 重置键盘（ console 上的恢复出厂设置没用）直到键盘背光灯闪烁，此时双侧侧光灯变蓝，随后左侧侧光灯蓝灯闪烁（表示等待蓝牙连接），此时你的电脑右下角应该就会弹出通知让你连接键盘，连接即可。

键盘连接通知

Final Thoughts

总之对这次决定下单购买还是不后悔的，目前用起来很满意，最满意的三点：矮轴，声音，手感。想换键盘的可以试试。不过在 console v1.0.2 发布之前，还是建议不要重新指派 F row key。

End

前言

作为机器学习从业者，我们需要一些 package 来辅助我们的工作。很多人也说现在干机器学习都是调包侠，我不是很赞同这种说法，技术越来越进步，进步的意义就在于越来越便捷，越来越 user-friendly，或者说高层，就像汽车一样。

越来越便捷就可以把宝贵时间留给更有意义的工作，比如数据处理和模型设计。而且可以降低入行门槛，一个行业如果从业者人数太少也不利于行业发展，参考之前传统武术独门绝技啥的传男不传女的规定。另一方面，调包是必要的，但如果你知其然且知其所以然，那更有利于你的工作，特别是 debug 的时候。

包括在 package 的安装方面，现在也是越来越方便，比刚出来的时候方便多了，像 TensorFlow 的安装都还需要专门写一篇文章来讲，我现在 CSDN 上访问量最高的文章就是在 Windows 上安装 TensorFlow 的文章，实在是有点意外。

而本文叫深度学习环境创建指南而不是机器学习环境创建指南，主要是为了强调深度学习相关工具的安装。

安装

为了避免重复劳动，后续可以快速创建环境，以及给有需要的人作参考，本文基于我的工作经历，记录一下 Windows 10 下一个基础深度学习环境的安装，主要包括 PyTorch 和 TensorFlow，其他 package 想起来再加。

1. 创建并激活 conda 环境

1
2

conda create -n dl python=3.9
conda activate dl

2. PyTorch

pip 方式，要安装哪个 cuda 版本，就相应修改 index url 的 whl/ 后面部分即可，但支持哪些需要参考官方文档：

1

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118

conda 方式：

1

conda install pytorch torchvision torchaudio pytorch-cuda=11.6 -c pytorch -c nvidia

测试：

1
2
3
4
5
6
7
8
9
10
11

>>> import torch
>>> torch.__version__
'1.13.0'
>>> torch.version.cuda
'11.6'
>>> torch.cuda.is_available()
True
>>> torch.cuda.device_count()
1
>>> torch.cuda.get_device_name()
'GeForce GTX 1060'

3. TensorFlow

1
2
3
4

# 我系统上之前似乎已经安装了cuda 11.2，所以这里我就直接安装了。
# 如果你系统上没有cuda，那么可以先用conda安装cudatoolkit，然后再用pip安装TensorFlow；
# 详细参考官方教程（注意切成英文版）：https://www.tensorflow.org/install/gpu#windows_setup
pip install tensorflow-gpu

测试：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

>>> import tensorflow as tf
>>> tf.__version__
'2.10.1'
>>> tf.test.is_built_with_cuda()
True
>>> tf.test.gpu_device_name()
2022-12-04 11:49:37.252105: I tensorflow/core/platform/cpu_feature_guard.cc:193] This TensorFlow binary is optimized with oneAPI Deep Neural Network Library (oneDNN) to use the following CPU instructions in performance-critical operations:  AVX AVX2
To enable them in other operations, rebuild TensorFlow with the appropriate compiler flags.
2022-12-04 11:49:38.082555: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1616] Created device /device:GPU:0 with 4632 MB memory:  -> device: 0, name: GeForce GTX 1060, pci bus id: 0000:01:00.0, compute capability: 6.1
'/device:GPU:0'
>>> tf.sysconfig.get_build_info()
OrderedDict([('cpu_compiler',
                'C:/Program Files (x86)/Microsoft Visual Studio/2019/Community/VC/Tools/MSVC/14.29.30133/bin/HostX64/x64/cl.exe'),
                ('cuda_compute_capabilities',
                ['sm_35', 'sm_50', 'sm_60', 'sm_70', 'sm_75', 'compute_80']),
                ('cuda_version', '64_112'),
                ('cudart_dll_name', 'cudart64_112.dll'),
                ('cudnn_dll_name', 'cudnn64_8.dll'),
                ('cudnn_version', '64_8'),
                ('is_cuda_build', True),
                ('is_rocm_build', False),
                ('is_tensorrt_build', False),
                ('msvcp_dll_names', 'msvcp140.dll,msvcp140_1.dll'),
                ('nvcuda_dll_name', 'nvcuda.dll')])

1
2
3

# 对于新版本的 tf，pip install tensorflow 会默认安装支持 GPU 的版本，如果你的环境中没有 GPU 或 cuda，
# 那么会自动使用 CPU。加上 [and-cuda] 后会自动安装 cuda 依赖，再也不用 conda 安装了！
pip install tensorflow[and-cuda]

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

>>> import tensorflow as tf
>>> tf.__version__
'2.17.10
>>> tf.test.is_built_with_cuda()
True
>>> tf.test.gpu_device_name()
2022-12-04 11:49:37.252105: I tensorflow/core/platform/cpu_feature_guard.cc:193] This TensorFlow binary is optimized with oneAPI Deep Neural Network Library (oneDNN) to use the following CPU instructions in performance-critical operations:  AVX AVX2
To enable them in other operations, rebuild TensorFlow with the appropriate compiler flags.
2022-12-04 11:49:38.082555: I tensorflow/core/common_runtime/gpu/gpu_device.cc:1616] Created device /device:GPU:0 with 4632 MB memory:  -> device: 0, name: GeForce GTX 1060, pci bus id: 0000:01:00.0, compute capability: 6.1
'/device:GPU:0'
>>> tf.sysconfig.get_build_info()
OrderedDict([('cpu_compiler', '/usr/lib/llvm-17/bin/clang'),
             ('cuda_compute_capabilities',
              ['sm_60', 'sm_70', 'sm_80', 'sm_89', 'compute_90']),
             ('cuda_version', '12.3'),
             ('cudnn_version', '8'),
             ('is_cuda_build', True),
             ('is_rocm_build', False),
             ('is_tensorrt_build', True)])
>>> tf.config.list_physical_devices('GPU')
[PhysicalDevice(name='/physical_device:GPU:0', device_type='GPU')]

4. 其他杂项

1

pip install notebook transformers datasets pandas jieba loguru

最后这个环境已经有 8.67 GB 了……

Reference

• Start Locally | PyTorch
• Install TensorFlow with pip

END

参考 Documenting Large Webtext Corpora: A Case Study on the Colossal Clean Crawled Corpus。

1. 从 365 百万 domain 中抓取，共计大约 1560 亿 token。
2. 用来训练 T5 和 Switch Transformer。
3. Raffel et al. (2020) 提供了重新创建 C4 的脚本，但是运行这些脚本大概需要数千刀。
4. C4 是以 Common Crawl 2019 年 4 月的 snapshot 为基础创建的，使用了很多 filter 来过滤文本。
5. 这些 filter 的作用包括：
   1. 删除没有 terminal punctuation mark 的行。
   2. 删除少于 3 个词的行。
   3. 删除少于 5 个句子的文档。
   4. 删除包含包含 Lorem ipsum 这种 placeholder 文本的文档。
   5. 删除包含“List of Dirty, Naughty, Obscene, or Otherwise Bad Words”中任何单词的文档。
   6. 删除非英文文档，非英文的标准是使用 langdetect 得到的英文概率小于 0.99，所以 C4 主要是英文文档。
6. 应用了 filter 的数据集版本叫 C4.EN，没应用的叫 C4.EN.NOCLEAN，没有使用 blcoklist 的 C4.EN 叫 C4.EN.NOBLOCKLIST。三个版本的简单统计如下图，其中 token 数是用 spacy 的 English tokenizer 分词后统计的：
   三个版本的 C4.EN 统计
7. 来源网址中，按 TLD（top-level domains）统计，前三名是 .com、.org、.co.uk，其中 .gov 和 .mil 占比也不少，后者尽管不在 top25 中，但是也有 33 百万 token。
8. 按网站统计，前三名是 patents.google.com、en.wikipedia.com、en.m.wikipedia.com。
9. 按发表时间统计，92% 都发表在数据集收集前的一个十年中（2011-2019），分布是长尾分布 long-tailed，大部分都在数据收集前的 10-20 年间。这是从 C4.EN 中采样得来的，采样大小为 1 百万。发表时间是按照该网址被 Internet Archive 首次索引收录的时间算的，所以真实发表时间实际更早一点。
10. 按地理位置统计，作者使用了一个 IP-country 数据库，从原始数据集中随机采样了一个大小为 17 万 5 千的样本集。前五名是美国（51.3%）、无法分辨、德国、英国和加拿大。中国排在第 18，香港排在第 16。值得注意的是，按人口算第 2、3、4 大说英语的国家——印度、巴基斯坦、尼日利亚、菲律宾，在数据集中占比只有美国的 3.4%、0.06%、0.03%、0.1%，尽管他们有数千万人说英语。
11. C4 包含大量机器生成的文本，machine-generated text，主要包括专利的机器翻译和 ocr 文本。前面说过，按网站统计 patents.google.com 排第一，这是专利网站，Google 会使用机器翻译模型翻译非英文专利，也会使用 ocr 将扫描文本识别出来。识别哪些文本是机器生成的也是一个活跃的研究领域。
12. C4 中存在 benchmark data contamination 现象，即下游任务的训练集或测试集出现在 C4 中，造成了数据污染。具体来说，分为两种情况：input-and-label contamination 和 input contamination。
13. 一些 seq2seq 任务的 label 其实就是 input 中的文本，例如抽取式摘要，如果这种任务的 input 出现在了预训练数据集中，那么其 label 也相当于出现在了预训练数据集中，那么我们有理由认为模型实际上只是在背书而没有做真正的推理。作者分析了 3 个生成式任务的7个数据集，发现均有不同程度（1.87-24.88%）的污染，target 文本为单句的匹配率（完全匹配）要明显高于多句。
14. Input contamination 同样会对下游任务造成影响。作者发现有 2-50% 的 GLUE input 出现在 C4 中。对于分类任务来说，虽然不包含 label 的训练集出现在 C4 中并不影响最终性能，但是对 zero-shot 和 few-shot 来说，这仍然是一个值得慎重对待的问题。
15. C4 带有明显的种族偏见，“Jewish”更容易与积极情绪挂钩，而“Arab”更容易与消极情绪挂钩。
16. 对被排掉的文档进行随机抽样，得到 10 万份文档，然后进行 k-means 聚类，k=50，使用 TF-IDF 进行 embedding，然后使用 PCA 进行降维可视化。但最终发现只有 16 个类，且三分之一的是性相关文档。
17. 相比于种族，提及性取向的文档更有可能被排除，例如 lesbian 和 gay。这个结论是通过计算点互信息 PMI 得到的。
18. 非裔美国英语 AAE 和西班牙裔美国英语 Hisp 更有可能被排除。
19. 许多被排除的文档并不包含 offensive 和 sexual 内容。
20. 97.8% 的 C4.EN 是白人英语 WAE，AAE 和 Hisp 分别只有 0.07% 和 0.09%。
21. 在创建数据集的过程中，评估 bias 很重要。
22. 在清洗 web-crawled 数据时，作者反对使用黑名单的方法来排除文档。
23. 作者分析的是 C4.EN，所以本文结论可能并不适合其他语言。
24. GPT-3 的作者在训练完成之后，才发现存在 benchmark contamination。由于重新训练非常昂贵，他们没有重新训练，转而分析不同任务受到该现象的影响，发现确实会影响相关 benchmark 的性能。