大模型“饥饿”问题解析：上下文窗口、Token成本与RAG检索实战

最近有个挺有意思的消息：士力架（Snickers）推出了一款“数字棒”，对外宣传口径是“喂饱你的 AI”。品牌营销人把糖果的“充能”心智迁移到 AI 场景，原本是一次创意上的借势；但这条消息放到开发者眼里，却意外地戳中了一个长期被讨论的话题——大语言模型确实会“饥饿”。

做 AI 应用的同学应该都有类似经历：模型明明很聪明，但聊天一长就开始“失忆”；回答专业问题时，明明资料就放在文档里，模型却一本正经地编造答案；线上日志里 Token 消耗量逐日攀升，账单被“饿”的模型一步步吃穿。这些现象背后，翻译成技术语言就是三个词：上下文窗口、Token 成本、知识边界。

这篇文章要做的，不是分析营销活动的传播效果，而是借“喂饱 AI”这个比喻，把大模型输入侧的运作机制讲清楚，并给出一套可以落地的 Python 工程方案。内容适合正在做 LLM 应用的开发者，也适合刚接触提示工程、想理解上下文管理的新手。读完你可以掌握：Token 如何计算、上下文窗口如何管理、如何用轻量检索给模型喂知识、以及如何避免常见的“ AI 饥饿”问题。

1. 背景与核心概念

1.1 从“数字棒”说起

先聊几句这次 Snickers 的营销动作。品牌方把一个本来面向人类的零食概念，映射到了 AI 上：AI 也会饿，AI 也需要被喂。具体活动形式我们不展开，因为营销玩法不是本文重点。重点是它把“给 AI 喂东西”这件事从抽象变成了一个具体画面，而这个画面正好对应开发者的日常工作。

在传统软件工程里，程序需要的输入很明确：参数、配置文件、数据库里的记录。但大模型应用不一样，模型是一个黑盒，它既能理解自然语言，也会受到输入内容的强烈影响。输入给模型的每一句话、每一段资料，都会被当作“食物”参与推理。因此，怎么组织这些输入，本质上就是怎么给 AI“做饭”。

现代 LLM 应用不再是“把问题抛给模型”这么简单，而是围绕模型构建一套输入管线：历史对话、业务知识、工具返回结果、用户当前诉求，都需要在有限的空间里排序、裁剪、拼接。这个过程做得越好，模型回答越稳定；做得不好，模型就会表现出“饥饿感”。

1.2 什么是“AI 饥饿”

大语言模型本身不具备持续获取数据的能力。它的“知识”来自训练阶段学到的参数，而不是实时联网搜索。它每一次推理能利用的外部信息，只有当前请求里携带的文本内容。

所以，“AI 饥饿”在技术上可以拆成三个层面：

• 上下文窗口不足：模型一次只能“看”有限数量的 Token，也就是有限长度的文本。超出部分会被截断或丢失。
• Token 成本压力：输入和输出都按 Token 计费。喂得越多，成本越高；喂得不当，很多 Token 都是浪费。
• 知识边界有限：模型不知道训练截止日期之后的新事件，也不知道你私有系统里的业务数据。如果不把知识检索出来拼进提示词，它就只能靠猜测回答。

这三个层面互相影响。上下文管理得好，成本就低，模型也不容易丢失关键信息；知识检索做得好，模型就能回答业务问题，而不是一本正经地胡说。

下面用一个简单的对应关系来理解：

1.3 理解上下文窗口与大模型的关系

上下文窗口（Context Window）是指模型在单次推理中能够接收的最大 Token 数量。不同模型的上限不同，有 8K、32K、128K 等规格，具体以官方文档为准。

可以把它想象成一张临时工作台。工作台面积有限，上面摆了你给的指令、历史对话、参考文档、工具返回结果，还有模型要写的答案。所有输入输出加起来不能超过台面大小。如果你把一堆无关内容堆上去，真正重要的信息就会被挤下去，模型就只能基于剩下的内容作答。

这也是为什么很多人在长对话场景中发现“模型变笨了”。并不是模型退化，而是早期的关键信息已经被截断。比如客服场景里，用户可能在前几轮就提供了订单号，聊了二十分钟后模型却开始询问“你的订单号是多少”。这就是典型的上下文被“挤掉”了。

理解这个概念之后，再去看各种提示词优化技巧、RAG 方案，思路就会清晰很多：它们本质都在做同一件事——在有限的上下文窗口里，尽量放入高质量、高相关度的信息。

2. 环境准备与开发工具

动手之前先把环境准备好。本文代码以 Python 为主，依赖尽量精简，目的是让你在没有 GPU、没有大模型本地推理环境的条件下也能跑通核心逻辑。

2.1 环境要求

• 操作系统：Windows / macOS / Linux 均可
• Python：3.9 及以上版本
• 不需要本地 GPU，不需要部署大型模型
• 如果希望验证真实模型调用，需要准备一个可用的模型 API Key

主要用到的第三方库：

• tiktoken：由 OpenAI 开源的 BPE 分词器，用来估算 Token 数量
• jieba：开源中文分词库，用于演示轻量级知识检索
• openai：可选，用于真实模型调用，也可以替换为你使用的模型服务商 SDK

2.2 创建项目目录

在合适的位置创建项目目录：

bash复制mkdir ai_feeder
cd ai_feeder
python -m venv venv

# Windows
venv\\Scripts\\activate

# macOS / Linux
source venv/bin/activate

然后安装依赖：

bash复制pip install tiktoken jieba openai

如果只是先体验 Token 计算和上下文管理，不打算调用线上模型，openai 这步可以跳过。后面主程序里我会加一个判断逻辑，没有 API Key 时自动进入本地演示模式。

2.3 项目结构

本文示例会包含以下文件：

text复制ai_feeder/
├── token_budget.py      # Token 计量工具
├── memory.py            # 对话记忆管理
├── retriever.py         # 轻量知识检索
├── main.py              # 主程序，组装上下文并调用模型
└── knowledge.py         # 知识库示例数据

为了阅读方便，我会按功能拆分成多个文件，而不是把几千行堆在同一个脚本里。生产项目也建议这样做，职责清晰，便于后续替换底层实现。

3. 核心原理：Token、上下文窗口与输入组装

这一节是重点。弄懂 Token 和上下文窗口之后，你就知道“喂 AI”到底是在喂什么了。

3.1 Token 是什么

Token 是模型处理文本的最小单位。它不是字，也不是词，而是模型分词器（Tokenizer）切分出来的片段。英文一个单词通常切成一个或多个 Token，中文一个汉字在部分模型里可能对应 1 到 2 个 Token，具体取决于模型使用的分词方式。

比如这段英文：

text复制Hello, welcome to AI world.

可能被切成：

text复制["Hello", ",", " welcome", " to", " AI", " world", "."]

中文的切分更特殊。同样是“上下文窗口”这几个字，不同分词器的处理结果可能完全不同。所以我们平时估算消耗时，不能用“字数”直接换算，而要通过模型自带的分词器去精确计算。

tiktoken 提供了一个简便的方式：

python复制# 文件路径：ai_feeder/token_budget.py
import tiktoken


def count_tokens(text: str, model: str = None) -> int:
    """
    估算文本的 Token 数量。
    model 可选，例如 "gpt-4"；不传时使用通用编码。
    """
    if model:
        try:
            encoding = tiktoken.encoding_for_model(model)
        except KeyError:
            # 有些新模型还没被本地 tiktoken 收录，回退到通用编码
            encoding = tiktoken.get_encoding("cl100k_base")
    else:
        encoding = tiktoken.get_encoding("cl100k_base")

    return len(encoding.encode(text))


if __name__ == "__main__":
    sample_text = "你好，欢迎来到 AI 世界。"
    print(f"字符数：{len(sample_text)}")
    print(f"Token 数：{count_tokens(sample_text)}")

运行结果大概会显示字符数和 Token 数并不相等。这就是为什么不能靠 len() 去预算输入长度。

3.2 输入消息的结构

调用大模型接口时，我们传入的通常是一个消息列表，每条消息有角色和内容。常见的角色包括：

• system：系统指令，设置模型的整体行为
• user：用户输入
• assistant：模型历史回复

例如：

python复制messages = [
    {"role": "system", "content": "你是一个专业的技术助手。"},
    {"role": "user", "content": "请解释什么是 RAG？"},
    {"role": "assistant", "content": "RAG 是检索增强生成……"},
    {"role": "user", "content": "那它和大模型微调有什么区别？"}
]

模型在生成最后一轮回复时，会把整串 messages 一起消费。所以 messages 越长，上下文占用越大。

3.3 滑动窗口式的上下文管理

上下文窗口固定，不能无限塞消息。一个简单的策略是滑动窗口：只保留最近的 N 条消息，或者按 Token 预算倒序选择消息，直到接近预算上限。

下面实现一个按 Token 预算裁剪的对话记忆类：

python复制# 文件路径：ai_feeder/memory.py
from token_budget import count_tokens


class ConversationMemory:
    def __init__(self, max_context_tokens: int = 6000, model: str = None):
        # 给输出答案预留一些空间，所以这里不是整个模型上限
        self.max_context_tokens = max_context_tokens
        self.model = model
        self.history = []

    def add_message(self, role: str, content: str):
        self.history.append({"role": role, "content": content})

    def get_messages_within_budget(self):
        """
        从最新消息向前回溯，逐条加入，直到总 Token 数接近预算。
        这样既能保留最近的对话，又不会撑爆上下文窗口。
        """
        selected = []
        total = 0

        for msg in reversed(self.history):
            cost = count_tokens(msg["content"], self.model)
            # 如果再加一条就要超过预算，就停止
            if total + cost > self.max_context_tokens:
                break
            selected.insert(0, msg)
            total += cost

        return selected, total


if __name__ == "__main__":
    memory = ConversationMemory(max_context_tokens=6000)
    memory.add_message("user", "今天天气怎么样？")
    memory.add_message("assistant", "今天晴，气温 25 度。")
    memory.add_message("user", "明天呢？")
    memory.add_message("assistant", "明天多云，可能有小雨。")

    selected, cost = memory.get_messages_within_budget()
    print(f"保留消息数：{len(selected)}")
    print(f"预计 Token 数：{cost}")

这里的逻辑是从后往前选，把最近的消息优先保留。超出预算时，宁可丢弃较早的消息，也不能让模型失去对最新话题的感知。

需要注意，滑动窗口只是一个基础方案。它简单有效，但牺牲了早期全局信息。如果业务场景里早期信息很重要，可以引入“摘要记忆”：把早期对话定期总结成一小段摘要，并入下一次请求。这是后续可以继续升级的方向。

3.4 知识检索：人为扩大模型的“视野”

上下文窗口再大，也装不下整个知识库。而且你也不可能每次请求都把全部文档塞进去。所以需要检索：只把与当前问题最相关的内容提取出来，拼进提示词。

这个思路就是检索增强生成，也就是 RAG。完整的 RAG 通常包含向量化、向量存储、相似度检索等环节，生产环境可以选 Elasticsearch、Milvus、Chroma 等组件。本文为了让你能快速跑通，先用 jieba 分词做关键词重叠打分，演示检索的基本流程。

python复制# 文件路径：ai_feeder/retriever.py
import jieba


def tokenize_for_search(text: str):
    """把文本切分为搜索用 Token 集合。"""
    return set(jieba.cut_for_search(text))


def search_knowledge_base(query: str, knowledge_items: list, top_k: int = 2):
    """
    根据关键词重叠度，从知识库中检索相关文档。
    knowledge_items 是 dict 列表，每个 dict 至少包含 title 和 content。
    """
    query_tokens = tokenize_for_search(query)
    scored = []

    for item in knowledge_items:
        content_tokens = tokenize_for_search(item["content"])
        score = len(query_tokens & content_tokens)
        if score > 0:
            scored.append((score, item))

    # 分数高的排前面
    scored.sort(key=lambda x: x[0], reverse=True)
    return scored[:top_k]


if __name__ == "__main__":
    docs = [
        {"title": "上下文窗口", "content": "上下文窗口是模型单次推理能够接收的最大 Token 数量。"},
        {"title": "Token", "content": "Token 是模型处理文本的最小单位。"},
        {"title": "RAG", "content": "RAG 是检索增强生成，通过检索外部知识来提升模型回答质量。"}
    ]

    result = search_knowledge_base("什么是上下文窗口？", docs)
    for doc in result:
        print(doc["title"], "->", doc["content"])

这段代码很简单，但已经具备了 RAG 的基本骨架：对用户问题分词、对知识文档分词、计算相关度、返回 Top K。真实项目中你可以把中间的关联度计算换成向量相似度，分词换成 Embedding 模型，效果会更好。

4. 完整实战：给 AI 做一套“喂食系统”

下面把前面几个工具串起来，做一个完整的“喂食系统”。它的运行流程是：用户提问 → 检索知识库 → 组合历史对话 → 组装系统提示词 → 调用模型 → 输出答案。

4.1 准备知识库

先写一个示例知识文件。实际项目中，这些内容通常来自公司内部文档或产品资料。

python复制# 文件路径：ai_feeder/knowledge.py
KNOWLEDGE_BASE = [
    {
        "id": "doc-001",
        "title": "上下文窗口",
        "content": "上下文窗口是模型单次推理能够接收的最大 Token 数量。"
                   "它决定了输入指令、历史对话和外部资料的总和上限。"
    },
    {
        "id": "doc-002",
        "title": "Token 计费",
        "content": "大模型服务通常按 Token 计费，输入和输出都会消耗。"
                   "降低 Token 使用量可以有效控制应用成本。"
    },
    {
        "id": "doc-003",
        "title": "RAG 检索增强生成",
        "content": "RAG 通过检索外部知识库，把与问题相关的资料拼入提示词，"
                   "能够让模型回答超出训练数据范围的私有问题。"
    },
    {
        "id": "doc-004",
        "title": "滑动窗口",
        "content": "滑动窗口是一种简单的对话记忆方案，只保留最近若干条消息，"
                   "适合对话长度波动不大的场景。"
    }
]

4.2 编写模型调用封装

这里做一个兼容真实调用和本地演示的封装。如果你没有 API Key，程序会打印将要发送的 message，并返回模拟结果，方便调试流程。

python复制# 文件路径：ai_feeder/llm_client.py
import os


def call_llm(messages, max_output_tokens: int = 512):
    """
    调用大模型接口。
    未配置 API Key 时进入演示模式，只打印 messages，不发起真实请求。
    """
    api_key = os.getenv("OPENAI_API_KEY")

    if not api_key:
        print("\\n[演示模式] 未检测到 API Key，下面展示即将发送给模型的上下文：")
        total_chars = 0
        for msg in messages:
            content = msg["content"]
            total_chars += len(content)
            print(f"----- {msg['role']} -----")
            print(content[:200] + ("..." if len(content) > 200 else ""))
        print(f"\\n[演示模式] 本次上下文总字符数：{total_chars}")
        return "[这是本地模拟返回的答案。配置 API Key 后可获得真实模型回答。]"

    try:
        import openai
        client = openai.OpenAI(api_key=api_key)

        response = client.chat.completions.create(
            model=os.getenv("LLM_MODEL", "gpt-4o-mini"),
            messages=messages,
            temperature=0.3,
            max_tokens=max_output_tokens,
        )
        return response.choices[0].message.content
    except ImportError:
        return "未安装 openai 依赖，请先执行 pip install openai"

注意，这里把模型名字放在环境变量 LLM_MODEL 中。不同模型服务商的接口字段可能不同，请根据你实际使用的服务调整。

4.3 组装主程序

主程序把记忆管理、知识检索和模型调用串起来。

python复制# 文件路径：ai_feeder/main.py
import os

from knowledge import KNOWLEDGE_BASE
from memory import ConversationMemory
from retriever import search_knowledge_base
from llm_client import call_llm

SYSTEM_PROMPT_TEMPLATE = """你是一个专业的技术助手。
请优先参考下方提供的资料回答用户问题。
如果资料中没有相关信息，请明确告知用户，不要编造答案。

参考资料：
{context}
"""


def build_system_prompt(context_docs):
    """把检索到的知识文档拼进系统提示词。"""
    if not context_docs:
        context = "（本次没有检索到相关参考资料）"
    else:
        parts = []
        for i, doc in enumerate(context_docs, start=1):
            item = doc["title"] + "：" + doc["content"]
            parts.append(f"{i}. {item}")
        context = "\\n".join(parts)

    return SYSTEM_PROMPT_TEMPLATE.format(context=context)


def main():
    # 1. 初始化记忆系统
    memory = ConversationMemory(max_context_tokens=6000, model="gpt-4")

    # 2. 给一个默认系统指令
    memory.add_message("system", "你是一个专业的技术助手，回答尽量简洁准确。")

    print("AI Feed System 启动成功")
    print("输入问题开始对话，输入 exit 退出")

    while True:
        user_input = input("\\n你的问题：").strip()

        if user_input.lower() in ("exit", "quit"):
            return

        # 3. 从知识库检索相关文档
        retrieved = search_knowledge_base(user_input, KNOWLEDGE_BASE, top_k=2)

        # 4. 组装系统提示词
        system_prompt = build_system_prompt(retrieved)
        messages_with_system = [{"role": "system", "content": system_prompt}]

        # 5. 获取预算内的历史对话
        history_messages, history_cost = memory.get_messages_within_budget()
        messages_with_system.extend(history_messages)

        # 6. 追加当前用户问题
        messages_with_system.append({"role": "user", "content": user_input})

        # 7. 调用模型
        answer = call_llm(messages_with_system)

        print("\\nAI 回答：")
        print(answer)

        # 8. 记录这次对话，供后续请求使用
        memory.add_message("user", user_input)
        memory.add_message("assistant", answer)


if __name__ == "__main__":
    main()

4.4 运行与验证

在项目根目录执行：

bash复制python main.py

输入一个问题，比如：

text复制什么是上下文窗口？

程序会先检索知识库，找到 doc-001，然后把内容拼进 system 提示词，最后调用模型。如果你没配 API Key，会看到类似下面的输出：

text复制AI Feed System 启动成功
输入问题开始对话，输入 exit 退出

你的问题：什么是上下文窗口？

[演示模式] 未检测到 API Key，下面展示即将发送给模型的上下文：
----- system -----
你是一个专业的技术助手。
请优先参考下方提供的资料回答用户问题。
如果资料中没有相关信息，请明确告知用户，不要编造答案。

参考资料：
1. 上下文窗口：上下文窗口是模型单次推理能够接收的最大 Token 数量。它决定了输入指令、历史对话和外部资料的总和上限。
...
----- system -----
你是一个专业的技术助手，回答尽量简洁准确。
----- user -----
什么是上下文窗口？

[演示模式] 本次上下文总字符数：xxx
AI 回答：
[这是本地模拟返回的答案。配置 API Key 后可获得真实模型回答。]

整个流程已经跑通：检索 → 组装 → 调用 → 记录。你可以继续追问，观察记忆组件如何保留最近的对话、检索组件如何根据新的问题返回新的资料。

4.5 结果说明

这套演示程序体现了三个关键设计：

• 知识检索只出现在 system 提示词里，用于补充业务背景。
• 历史对话通过 Token 预算裁剪，防止上下文无限膨胀。
• 用户最新问题永远放在最后，作为模型作答的直接触发点。

它还预留了升级空间。后续可以替换检索算法为向量检索，也可以把 memory 换成 Redis 存储实现多轮会话持久化，或者接入真实的 Agent 工具调用。

5. 常见问题与排查思路

实际开发中，很多问题并不是模型本身的问题，而是输入组织不合理。下面整理几个高频问题。

如果你遇到“模型看起来变笨了”，优先排查上下文里是否少了关键字段。可以用 print(messages) 把最终发送的内容完整打印出来，肉眼对比一下模型能看到的输入是否覆盖了必要信息。

另一个常见误区是盲目调大上下文长度。有些模型支持 128K 上下文，但你每次塞 120K Token 进去，成本高、响应慢，模型注意力也被平均稀释。正确做法是控制总量，让关键信息尽量提前且集中出现。

6. 最佳实践与工程建议

6.1 建立 Token 预算体系

不是所有模型输入都需要“装满”。建议给每次请求设定一个内部预算，比如：

• 系统提示词：固定占 500 Token
• 历史对话：最多占 3000 Token
• 知识检索结果：最多占 1500 Token
• 预留输出：至少 512 Token

在代码层面对每部分都做 Token 计数，超过预算就触发截断或摘要。这样能避免上下文随机膨胀，也能让核心信息更稳定地保留。

6.2 生产环境下的上下文策略

滑动窗口是起步方案，生产环境建议升级为“分层记忆”：

• 最近对话：完整保留，用于理解当前话题。
• 早期对话：定期生成摘要，以压缩形式保留。
• 业务关键信息：单独存结构化字段，比如订单号、用户设置、审批状态。

模型是概率推理系统，它对“夹在长文本里的一条用户信息”的注意力不一定足够。所以，与其把用户信息藏在 10000 字的历史里，不如单独提取出来，拼在 system 提示词里。

6.3 知识检索的工程化升级

本文演示的关键词检索适合教学，生产环境建议替换为向量检索。向量检索的基本流程是：

1. 把知识库文档切分成块，比如每 500 Token 一块。
2. 用 Embedding 模型将每个块转成向量并存入向量数据库。
3. 用户提问时，将问题向量化，在向量数据库中做相似度检索。
4. 取 Top K 块拼进提示词。

分块时要注意块之间保持语义完整，不要把一句话拦腰截断。还可以给每个块附带标题、来源链接、更新时间等元数据，便于在回答末尾给用户展示参考来源。

6.4 安全与权限

调用大模型服务时，API Key 必须放在环境变量或密钥管理系统中，绝不能硬编码在代码仓库里。涉及内部知识库检索时，还要注意权限控制：

• 不同角色用户只能检索到授权范围内的文档。
• 在检索层就完成权限过滤，而不是依赖模型提示词去“不回答”。
• 对外部用户输入要保持警惕，防止提示词注入。

所谓提示词注入，是指用户故意在输入中夹带“忽略上面的指令”等文本，试图让模型绕过系统设定。缓解方式包括：把用户输入和系统指令用明显的分隔符隔离、对输入做长度限制、在提示词中要求模型忽略指令性前缀。但请注意，提示词层面只能缓解，不能根治，关键仍是应用自身做好权限校验。

6.5 监控可观测性

上线到生产环境后，建议记录以下维度的日志：

• 每次请求的 Token 消耗量
• 知识库检索命中的文档 ID
• 模型响应耗时
• 用户提问的置信度或情绪判断

不要只记录模型返回文本。把输入上下文也留一份快照，问题复现时就能快速定位到底是检索不到位、上下文被截断，还是模型本身输出异常。这些能力很朴素，但在排查线上问题时价值极高。

7. 总结与学习路线

借 Snickers“数字棒”的话题，我们把“喂饱 AI”拆解成了三个可落地的技术方向：Token 计量、上下文管理、知识检索。你在本文中应该已经掌握：

• 如何用 tiktoken 精确估算输入 Token。
• 如何用滑动窗口控制历史消息长度。
• 如何做一个简单的关键词检索，并把检索结果拼进 system 提示词。
• 如何在没有 API Key 的情况下先跑通完整链路，再接入真实模型。

如果你接下来想继续深入，建议按这个路线走：

1. 先把向量检索跑起来，对比关键词检索和向量检索在不同业务文档上的差异。
2. 学习主流向量数据库的基础用法，例如 Milvus、Chroma、Elasticsearch 的向量能力。
3. 研究对话式 Agent 的记忆分层，加入摘要记忆、长期存储、工具调用。
4. 关注成本优化方面的最佳实践，包括缓存、模型分级、路由策略。

“AI 饥饿”的问题不会因为模型变大而自动消失。上下文窗口在增长，但业务数据的增长速度只会更快。真正决定体验的，始终是工程侧怎么选、怎么切、怎么放。建议你先在本地跑通这套最小示例，然后把其中一个模块替换成生产级方案，一步一步把“喂食系统”打磨成你业务里最可靠的那根“数字棒”。