自然语言处理（十二）：前沿技术与实战应用

我们用了十一章，从原始文本一路爬到多模态基础模型。这第十二章既站在前沿，也站在跑道上：研究在这里不再是论文，而是一个服务——一个能调用工具、写代码并自我修复、做百步推理、吞下 20 万 token 合同、并以 p95 < 300 ms 的延迟支撑上千并发的 LLM。

能力的扩张带来新的失败模式。模型会自信地胡说，会在被诱导时输出有害内容，会泄露训练数据，会在部署粗糙时烧掉惊人的预算。所以这一章分成两半。前半部分——Agent、代码生成、长上下文、推理模型——是模型能力的前沿。后半部分——安全、评估、部署——是把这些前沿放进生产环境而不烧用户和预算所必须的工程。

你将学到什么

Agent：Function Calling 协议与 ReAct 推理-行动循环，附可运行的 Python 实现。
代码生成：Codex / Code Llama / DeepSeek-Coder 在 HumanEval 上的实际位置，以及自我修复回路是如何工作的。
长上下文：滑动窗口、稀疏 + 全局、Infini-attention 三类注意力掩码，及其取舍。
推理模型：o1 与 DeepSeek-R1 如何用测试时算力换取准确率，CoT 为什么要被策略化。
安全：幻觉分类、RLHF / DPO / Constitutional AI 三种主流对齐路线、护栏的工程做法。
评估：能力 / 安全 / 效率三轴基准，以及它们各自不能告诉你什么。
生产部署：FastAPI + vLLM + Docker 参考栈、可观测性以及具体的延迟目标。

前置知识

本系列前十一章，尤其是第 4 章（Transformer）、第 6 章（GPT）、第 8 章（PEFT）、第 9 章（LLM 内部）和第 10 章（RAG）。
Python、基本的 asyncio、Docker 容器的大致形状。
熟悉一点强化学习对理解对齐部分有帮助；详细版见 RL 第 12 章 — RLHF 与 LLM 应用。

1. Agent 与工具调用

继 instruction tuning 之后，最大的能力跃迁是教模型调用函数。一个普通 LLM 是一个被冻结的近似器：训练时不知道的东西，它就永远不知道。一个具备 Agent 能力的 LLM 是一个控制器，可以向外部世界询问事实、运行代码、查询数据库，然后继续生成。这把系统从"聪明的自动补全"变成了"可编程的执行器"。

1.1 Function Calling — 协议本身

Function Calling 由 OpenAI 在 2023 年中推出，如今已成为 Claude、Gemini、Llama-3、Qwen 的通用能力。它是叠加在 chat completion 之上的一个类型化协议：应用以 JSON Schema 声明工具，模型被训练成"要么直接回答，要么发出一个结构化的工具调用"。五个阶段，没有魔法：

Schema 声明：应用为每个工具注册名称、说明、参数 JSON Schema。
路由：模型读用户消息，决定回答还是调用。
参数生成：约束解码产出符合 schema 的 JSON。
执行：函数由应用而非模型在沙箱中运行。
结果回灌：执行结果作为 tool 消息追加到对话，模型据此组织最终答复。

 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
import json
from openai import OpenAI

client = OpenAI()

TOOLS = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "查询指定城市的当前天气，返回摄氏度温度与简短状态。",
        "parameters": {
            "type": "object",
            "properties": {
                "city": {"type": "string", "description": "城市英文名"},
                "unit": {"type": "string", "enum": ["celsius", "fahrenheit"], "default": "celsius"},
            },
            "required": ["city"],
        },
    },
}]

def get_weather(city: str, unit: str = "celsius") -> dict:
    # 真实实现会调用天气 API。
    return {"city": city, "temp": 25, "unit": unit, "condition": "sunny"}

def chat(user_msg: str) -> str:
    messages = [{"role": "user", "content": user_msg}]
    resp = client.chat.completions.create(
        model="gpt-4o-mini", messages=messages, tools=TOOLS, tool_choice="auto"
    )
    msg = resp.choices[0].message
    messages.append(msg)

    if msg.tool_calls:
        for call in msg.tool_calls:
            args = json.loads(call.function.arguments)
            result = get_weather(**args)
            messages.append({
                "role": "tool",
                "tool_call_id": call.id,
                "content": json.dumps(result, ensure_ascii=False),
            })
        resp = client.chat.completions.create(model="gpt-4o-mini", messages=messages)
        return resp.choices[0].message.content
    return msg.content

三个常见错误。第一，让模型自己决定是否调用（tool_choice="auto"）；强行调用会得到稀奇古怪的参数。第二，永远要沙箱执行——模型完全可能产出 delete_all_users() 调用，只要你的 schema 允许它。第三，工具描述本身就是 prompt：要不断改写直到模型每次都能挑对工具。

1.2 ReAct — 推理与行动的循环

Function Calling 是单轮接口。ReAct（Yao et al., ICLR 2023, arXiv:2210.03629 ）把它推广为 Thought -> Action -> Observation 的迭代循环，让模型可以分解、分支、重新规划。这是 LangChain、AutoGPT、OpenAI Assistants、Claude tool-use 模式以及 2025 年大多数生产级 Agent 的架构骨架。

 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
import re
from dataclasses import dataclass
from typing import Callable

@dataclass
class Tool:
    name: str
    description: str
    fn: Callable[[str], str]

REACT_PROMPT = """你是一个谨慎的推理 Agent，可以使用以下工具：
{tool_block}

每一轮严格按下面的格式输出：
Thought: <一句话推理>
Action: <工具名>
Action Input: <单行参数>

完成时改用：
Thought: <推理>
Action: Final Answer
Action Input: <给用户的最终回答>

Question: {question}
{scratchpad}"""

class ReActAgent:
    def __init__(self, llm: Callable[[str], str], tools: list[Tool], max_steps: int = 8):
        self.llm = llm
        self.tools = {t.name: t for t in tools}
        self.max_steps = max_steps

    def _render_tools(self) -> str:
        return "\n".join(f"- {t.name}: {t.description}" for t in self.tools.values())

    def _parse(self, txt: str):
        m = re.search(r"Action:\s*(.+?)\s*\nAction Input:\s*(.+)", txt, re.S)
        if not m:
            raise ValueError(f"无法解析模型输出:\n{txt}")
        return m.group(1).strip(), m.group(2).strip()

    def run(self, question: str) -> str:
        scratch = ""
        for step in range(self.max_steps):
            prompt = REACT_PROMPT.format(
                tool_block=self._render_tools(),
                question=question,
                scratchpad=scratch,
            )
            out = self.llm(prompt)
            try:
                action, action_input = self._parse(out)
            except ValueError:
                return f"[第 {step} 步格式错误]\n{out}"

            if action == "Final Answer":
                return action_input
            if action not in self.tools:
                obs = f"未知工具 '{action}'，可用：{list(self.tools)}"
            else:
                obs = self.tools[action].fn(action_input)

            scratch += f"\n{out}\nObservation: {obs}"
        return "[到达最大步数] " + scratch[-500:]

什么时候用什么？Function Calling 是默认选择：结构化、prompt 短、单轮往返便宜。ReAct 在需要多步规划、需要在中间观察上分支、或需要从工具失败中恢复时才值得它的开销——研究综述、数据分析、多跳问答、复杂预订都是典型场景。介于两者之间的任务，现代框架允许你把 Function Calling 步骤组织成一张带显式状态的图，这通常是最易维护的折中。

2. 代码生成

代码是 LLM 最明显地从"有趣 demo"变成"必备工具"的领域。GitHub 公开数据显示 Copilot 用户接受约三分之一的建议，在基准任务上提速约 55%。技术配方很直接：在代码上预训练，在指令上微调，用运行结果评估，再加一个自我修复回路。

2.1 流水线

现代代码-LLM 流水线五段：自然语言意图、被增强的上下文（已打开文件、仓库符号、测试桩、检索到的 API 文档）、在代码上训练的解码器、编译并跑单测的执行器、把失败信息回喂给模型的自我修复。修复回路是把 65% pass@1 抬到 85% pass@5 的关键。AlphaCode、Reflexion、Code Llama Instruct 都用了某个版本的它。

2.2 模型与基准

标准基准是 HumanEval（Chen et al., arXiv:2107.03374 , 2021）：164 道手写 Python 题，靠执行打分。pass@k 是 $k$ 个采样中至少一个通过全部单测的概率；$\mathrm{pass}@1$ 是最严格的单次成功率。两点警示：HumanEval 是单文件、纯 Python、题目极短，会高估真实工程性能；它已经被严重数据污染，2024 年以后的分数应交叉对比 MBPP、LiveCodeBench、SWE-bench Verified 或 CRUXEval。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
from transformers import AutoTokenizer, AutoModelForCausalLM
import torch

class CodeLlamaInstruct:
    """Code Llama 7B-Instruct 的极简包装。"""

    def __init__(self, model_name: str = "codellama/CodeLlama-7b-Instruct-hf"):
        self.tok = AutoTokenizer.from_pretrained(model_name)
        self.model = AutoModelForCausalLM.from_pretrained(
            model_name, torch_dtype=torch.float16, device_map="auto"
        )

    def generate(self, instruction: str, max_new_tokens: int = 512) -> str:
        prompt = f"<s>[INST] {instruction.strip()} [/INST]"
        ids = self.tok(prompt, return_tensors="pt").to(self.model.device)
        with torch.no_grad():
            out = self.model.generate(
                **ids, max_new_tokens=max_new_tokens,
                temperature=0.2, top_p=0.95, do_sample=True,
            )
        text = self.tok.decode(out[0], skip_special_tokens=True)
        return text.split("[/INST]")[-1].strip()

2025 年的场景判断：纯 Python 任务，DeepSeek-Coder-V2、Qwen2.5-Coder、GPT-4o 处于第一梯队；要做仓库级 PR 任务，SWE-bench Verified 是比 HumanEval 靠谱得多的代理指标，且榜单完全不同——Claude 3.5/3.7 Sonnet、GPT-4o 与 Devin 类执行 Agent 领先，常常是较弱基模 + 强执行 Agent 的组合。

3. 长上下文建模

标准自注意力在时间和显存上都是 $O(n^2)$。把上下文从 4K 翻到 8K 几乎无感；从 32K 翻到 128K 就是显存悬崖。突破它有几条互补的路子，通常组合使用。

滑动窗口（Longformer，Beltagy et al., 2020 ）— 每个 query 只看最近 $w$ 个 key，开销降到 $O(nw)$。捕捉局部结构，靠堆叠多层把远端信息逐层传播。
稀疏 + 全局 token（BigBird、Longformer-global）— 步长稀疏注意力 + 几个被所有 query 看到的"全局" token。问答场景中，问题 token 必须看到全文时尤其有用。
Infini-attention（Munkhdalai et al., 2024 ）— 用一个小局部窗口保证精度，外加一个压缩记忆汇总更早的内容。显存有界，等效上下文无界。
位置编码外推 — RoPE base scaling、NTK-aware 插值、YaRN、LongRoPE — 通过重参数化旋转频率，把在 4K 训练的模型扩到 128K，几乎不需要微调。
参数高效长上下文微调 — LongLoRA 把 shifted sparse attention 与 LoRA 结合，让 7B 模型在两张 A100 上扩到 100K。

实际工程中，现代长上下文 LLM 通常组合：预训练阶段使用 RoPE 扩展、内核里使用滑动窗口或 GQA、再在长文档混合数据上继续训练。推理时 FlashAttention-2/3 与 PagedAttention（vLLM）控制常数项。

4. 推理模型

2024–2025 年 NLP 的拐点是测试时算力：不再单纯把基模做大，而是让它在回答前想得更久。OpenAI 的 o1（2024-09）和 DeepSeek-R1（arXiv:2501.12948 , 2025-01）都走这条路：先内部生成一段 chain-of-thought，打分、必要时回滚，最终只把答案返回给用户。

驱动收益的两个想法。第一，过程监督：训练一个奖励模型给中间步骤而非最终答案打分（Lightman et al., Let’s Verify Step by Step, 2023）。第二，可验证任务上的结果型 RL：数学和代码这种成功可被自动判定的领域，可以用验证器作为奖励做大规模 RL。DeepSeek-R1 的 “R1-Zero” 配方进一步证明：在足够强的基模上，纯 RL（没有 SFT）就能涌现出推理能力，包括"啊哈时刻"和自我纠错。

代价。推理模型慢、token 贵——一道 AIME 题可以消耗 1 万到 10 万推理 token。它们还隐藏 CoT（o1 对隐藏推理 token 也计费），带来新的评估与信任问题。2025 年正确的设计模式是路由：简单 query 发给快模型（GPT-4o、Claude Haiku），重推理 query 发给 o1 / R1 / Claude Sonnet thinking 模式。代价-质量差距常常是 10–50 倍。

5. 安全、对齐与幻觉

一个有用但不安全的模型无法上线。一个安全但不有用的模型还不如没有。对齐就是工程化地命中这条狭窄走廊的学科。

5.1 幻觉的分类

幻觉不是单一失败模式。一个有用的划分（Huang et al., Survey of Hallucination, 2023）：

事实性：与可验证事实不符（“居里夫人获得过菲尔兹奖”）。
忠实性：与给定上下文不符——RAG 与摘要场景的核心问题（“合同写的是 30 天付款”，但合同其实写的是 60 天）。
逻辑/算术：推理步骤无效，但流畅得像那么回事。
自一致性：同一对话里前后矛盾。

缓解手段是叠加的：RAG 解决事实性（第 10 章）、约束解码 + JSON schema 保证结构忠实、自一致性多采样 + 多数投票对算术、过程监督 + 推理模型对逻辑、强制引用 prompting 提升可核查性、弃权训练（学会说"我不知道"）作为最后防线。

5.2 对齐 — RLHF、DPO、Constitutional AI

主流对齐配方仍是三段：在示范上 SFT，在偏好对上训奖励模型，再用 PPO 对奖励做 RL。DPO（Rafailov et al., 2023）把后两步坍缩成一个有监督损失，简单且便宜，目前是开源生态的事实默认。Constitutional AI（Bai et al., Anthropic, 2022）用一份"宪法"规则让模型自我批判，把大规模安全微调中的人工标注大幅替换成模型生成，让安全调优可扩展。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
class GuardedLLM:
    """用输入 + 输出安全分类器包裹任意 chat 函数。"""

    def __init__(self, llm, in_filter, out_filter, refusal: str = "抱歉，无法协助这一请求。"):
        self.llm, self.inf, self.outf = llm, in_filter, out_filter
        self.refusal = refusal

    def chat(self, user_msg: str) -> str:
        if self.inf(user_msg).get("label") == "unsafe":
            return self.refusal
        reply = self.llm(user_msg)
        if self.outf(reply).get("label") == "unsafe":
            return self.refusal
        return reply

生产环境里，输入过滤器主要拦截越狱与 prompt injection（特别是来自 RAG 上下文的注入，目前是头号攻击向量）；输出过滤器拦截 PII、毒性、违规内容。两个过滤器本身都是小分类器（Llama-Guard-3、ShieldGemma、OpenAI Moderation），比让主模型自己当警察便宜也更可控。

6. 评估

基准是我们最少地骗自己的方式。三个轴都重要，多数团队在其中两个上投入不足。

轴	公开基准	实际衡量的内容
能力	MMLU、GPQA-Diamond、GSM8K、MATH、HumanEval、MBPP、SWE-bench、MT-Bench、Arena-Hard、C-Eval	知识 + 推理 + 生成，普遍存在数据污染
安全	TruthfulQA、ToxiGen、HarmBench、JailbreakBench、BBQ	拒答行为、偏见、越狱鲁棒性
效率	MLPerf-Inference、vLLM bench、MMLU-Pro tokens/answer	吞吐、p50/p95 延迟、每百万 token 成本

三个值得养成的习惯。建立私有评测集：从真实用户中抽 100–500 条，这是和上线效果最相关的数字。用成对比较（CoT-as-judge 加定期人工抽检）——绝对分数会漂移，成对胜率不会。逐版本回归（lm-evaluation-harness、evalplus、inspect_ai）——私有评测掉 2 分应阻塞发布，哪怕 MMLU 涨了。

7. 生产部署

这是漂亮 Notebook 撞上现实的地方。我们要勾勒的参考栈——前端 FastAPI、中段 vLLM、外层 Docker + K8s、全链路 Prometheus 监控——是 2025 年大多数生产团队的同款，剩下的只是 Triton vs. TGI vs. TensorRT-LLM 的口味之争。

7.1 推理层

服务上线就别用 transformers.generate 了。原型可以，生产灾难：没有连续批处理、没有 PagedAttention、KV-cache 管理粗糙。请用 vLLM（开源默认）、TensorRT-LLM（NVIDIA，H100 上最快）或 TGI（Hugging Face，运维最简单）。三者都实现了连续批处理、分页 KV-cache、前缀缓存与投机解码。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
# vLLM 当库使用——生产部署通常直接 `vllm serve`。
from vllm import LLM, SamplingParams

llm = LLM(
    model="meta-llama/Meta-Llama-3.1-8B-Instruct",
    dtype="bfloat16",
    max_model_len=8192,
    gpu_memory_utilization=0.92,
    enable_prefix_caching=True,
)
params = SamplingParams(temperature=0.7, top_p=0.95, max_tokens=512)
out = llm.generate(["用两句话解释 LoRA。"], params)
print(out[0].outputs[0].text)

7.2 API 层

FastAPI 是阻力最小的路径：异步、pydantic 校验、自动 OpenAPI、SSE 流式开箱即用。不那么显然但很重要的部分是请求卫生——严格输入限制、请求 ID、结构化日志，以及 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
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
from fastapi import FastAPI, HTTPException, Request
from fastapi.responses import StreamingResponse
from pydantic import BaseModel, Field
import asyncio, time, uuid, logging

logger = logging.getLogger("nlp-api")
app = FastAPI(title="NLP Service", version="1.0")

class ChatRequest(BaseModel):
    message: str = Field(min_length=1, max_length=8000)
    max_tokens: int = Field(256, ge=1, le=2048)
    temperature: float = Field(0.7, ge=0.0, le=2.0)
    stream: bool = False

async def _stream(prompt: str, max_tokens: int, temperature: float):
    # 替换为真实的 vLLM 异步生成器。
    for tok in prompt.split():
        await asyncio.sleep(0.02)
        yield f"data: {tok} \n\n"
    yield "data: [DONE]\n\n"

@app.post("/v1/chat")
async def chat(req: ChatRequest, request: Request):
    rid = str(uuid.uuid4())
    t0 = time.perf_counter()
    try:
        if req.stream:
            return StreamingResponse(
                _stream(req.message, req.max_tokens, req.temperature),
                media_type="text/event-stream",
                headers={"X-Request-Id": rid},
            )
        # 非流式分支……
        reply = "stub"
        return {"id": rid, "reply": reply}
    except Exception as exc:
        logger.exception("rid=%s failed: %s", rid, exc)
        raise HTTPException(500, "internal error") from exc
    finally:
        logger.info("rid=%s latency_ms=%.1f", rid, (time.perf_counter() - t0) * 1000)

@app.get("/healthz")
async def health(): return {"status": "ok"}

7.3 容器化

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
FROM nvidia/cuda:12.1.1-cudnn8-runtime-ubuntu22.04

ENV PYTHONUNBUFFERED=1 PIP_NO_CACHE_DIR=1
RUN apt-get update && apt-get install -y --no-install-recommends \
        python3.11 python3-pip git \
    && rm -rf /var/lib/apt/lists/*

WORKDIR /app
COPY requirements.txt .
RUN pip3 install --upgrade pip && pip3 install -r requirements.txt

COPY app/ ./app/
EXPOSE 8000
HEALTHCHECK --interval=30s --timeout=5s --start-period=60s --retries=3 \
  CMD curl -fsS http://localhost:8000/healthz || exit 1

CMD ["uvicorn", "app.main:app", "--host", "0.0.0.0", "--port", "8000", "--workers", "1"]

K8s 部署时把 Pod 调度到带 nvidia.com/gpu: 1 的节点，CPU/内存请求收紧，livenessProbe 探 /healthz，readinessProbe 仅在模型加载完成后才转 ready（最常见的部署 bug 是在 30–90 秒预热期间就接流量）。

7.4 可观测性与 SLO

度量不到的就修不好。最小可用埋点：

指标（Prometheus + Grafana）：QPS、p50/p95/p99 延迟、GPU 利用率、显存、队列深度、缓存命中率、tokens/s。
追踪（OpenTelemetry）：每个请求一条 span，子 span 覆盖检索、生成、后处理。
日志（Loki / ELK）：结构化 JSON，每条带请求 ID。
错误（Sentry）：按异常类聚合，速率突增报警。

7-8B 模型在单张 A100 80GB + vLLM + bf16 上的合理上线目标：聚合吞吐 ~1500-2500 tok/s/GPU、p95 首 token < 300 ms、p95 token 间 < 80 ms、~30 并发流。量化到 4-bit AWQ 通常把吞吐再翻一倍，代价是大多数基准上 1–2 分；用私有评测确认是否可接受再切。

8. 常见问题

Function Calling、ReAct、图框架怎么选？ 单工具、确定性调用：Function Calling。多步、需要分支重试与中间检查：ReAct 或 LangGraph 这类图框架。如果你发现自己在 ReAct 的字符串上手写状态机，就该切到图——它把控制流变得显式且可测。

开源模型还是托管 API？ 托管 API 在上线速度、能力上限、低请求量成本上占优。开源自托管在数据主权、微调自由度、高吞吐稳态成本上占优（7-13B 模型在自有硬件上的盈亏平衡点大约是 5000 万–1 亿 tokens/天）。

真的需要推理模型吗？ 日常聊天、摘要、分类、短代码：不需要，快模型便宜 10-50 倍且够用。竞赛数学、复杂代码、多跳调研、任何"系统 2"任务：需要，差距是质的。按 query 路由就好。

我的 Agent 死循环了。 几乎一定是这三种之一：(1) 工具描述歧义，模型反复试错工具；(2) 你忘了 Final Answer 哨兵；(3) 观察过长，把原始目标挤出了上下文。给迭代设上限、给每一步加日志、把观察裁剪到只剩相关字段。

最便宜的扩上下文方式是什么？ 如果能微调：RoPE base scaling + 一次小 LongLoRA。如果不能：分块 + RAG（第 10 章）。真正的 100 万 token 上下文很少是正确答案——检索更便宜、更可调试，通常也更准确。

系列收官

我们从空白符分词开始，最后停在能让推理 Agent 流式吐 token、藏在负载均衡器后面的服务。回头看这张地图，能看到四道弧：

基础（第 1-3 章）——文本变成向量，序列变成隐状态。
Transformer（第 4-6 章）——注意力替代循环，预训练分裂成 BERT 式理解与 GPT 式生成。
适配（第 7-9 章）——prompting、PEFT 与 LLM 内部机制，把预训练模型变成可塑造的工具。
应用（第 10-12 章）——RAG 把模型锚到知识，多模态突破纯文本天花板，Agent + 生产工程把整条链路闭环成可部署系统。

如果整套系列只让你带走三件事，我希望是这三件。架构没有数据和目标重要——Transformer 已是底牌，差异化在预训练数据混合、指令数据与评估上。工程纪律胜过模型规模——一个带 RAG、评测和护栏的精心 8B 部署，会稳定打败一个糙做的 70B 服务。前沿移动很快，但基本功稳定——embedding、注意力、微调、检索、对齐与服务，到 2027 年仍是正确的词汇表，只不过具体模型名字会换一轮。

谢谢你读完十二章。现在去构建些什么吧。

参考文献

Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, ICLR 2023, arXiv:2210.03629 .
Schick et al., Toolformer: Language Models Can Teach Themselves to Use Tools, NeurIPS 2023, arXiv:2302.04761 .
Roziere et al., Code Llama: Open Foundation Models for Code, Meta AI, 2023, arXiv:2308.12950 .
Chen et al., Evaluating Large Language Models Trained on Code (HumanEval / Codex), 2021, arXiv:2107.03374 .
Beltagy et al., Longformer: The Long-Document Transformer, 2020, arXiv:2004.05150 .
Munkhdalai et al., Leave No Context Behind: Efficient Infinite Context Transformers with Infini-attention, 2024, arXiv:2404.07143 .
Chen et al., LongLoRA: Efficient Fine-tuning of Long-Context LLMs, ICLR 2024, arXiv:2309.12307 .
Lightman et al., Let’s Verify Step by Step, 2023, arXiv:2305.20050 .
OpenAI, Learning to Reason with LLMs (o1 system card), 2024.
DeepSeek-AI, DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via RL, 2025, arXiv:2501.12948 .
Rafailov et al., Direct Preference Optimization, NeurIPS 2023, arXiv:2305.18290 .
Bai et al., Constitutional AI: Harmlessness from AI Feedback, Anthropic, 2022, arXiv:2212.08073 .
Kwon et al., Efficient Memory Management for Large Language Model Serving with PagedAttention (vLLM), SOSP 2023, arXiv:2309.06180 .
Dao, FlashAttention-2, 2023, arXiv:2307.08691 .

系列导航

部分	主题	链接
10	RAG 与知识增强系统	<– 阅读
11	多模态大模型	<– 上一篇
12	前沿技术与实战应用（本文）	—

系列完结。感谢一路同行。