企业官网建设流程全解析

🔥个人主页：代码不加冰（欢迎来访）
🎬作者简介：java后端学习者
❄️个人专栏：LeetCode刷题日记 ， 苍穹外卖日记，SSM框架深入，JavaWeb，
✨命运的结局尽可永在，不屈的挑战却不可须臾或缺！

前言：

大家好，我是代码不加冰，接着前面的从0-1的agent专栏，在那里我们对agent整体有了一个了解，而我们接下来，就要细致的对agent进行学习，让我们一起来看看吧。（至于python的基础语法，再加上一点python的后端，这一部分过几天再学）

摘要：

作为一个后端学习者，习惯了确定性的代码逻辑，刚接触LLM时会经历一段痛苦期。很多系统问题并不是代码 Bug，而是模型的不确定性在系统架构中被放大了。

我们需要明确一个核心认知：大模型并不是真正的智能，它本质上是一个基于海量训练数据、预测下一个 Token 的概率机器。

学习 LLM 基础的目的，不是为了去训练或微调模型，而是为了“预测模型在系统里的失败方式”。只有理解了它的底层机理，我们才能在接口设计、重试策略、Prompt 工程以及 Agent 系统架构中做好兜底与防御性编程。

一、 Token 与上下文窗口

1. 什么是 Token

模型处理的不是原始文本，也不是字符，而是 Token（词元）。Token 是文本片段的最小统计单位（例如英文中一个单词可能是 1-2 个 Token，中文一个汉字通常对应 1-2 个 Token）。

• 计费基础：API 调用的成本（Input/Output）完全由 Token 数量决定。

• 性能瓶颈：Token 数量直接决定了首字延迟（TTFT）和整体推理时间。

2. 上下文窗口（Context Window）

每个模型都有其最大的上下文限制（如 8k、32k、128k 甚至百万级别）。

• 上下文长度不等于长期记忆：增加上下文长度只是拉长了模型的“短期工作内存”。它没有真正的、持久化存储的“记忆能力”。

• 截断策略（Truncation Strategies）：当用户的对话历史或注入的背景知识超过限制时，系统必须进行截断。是采取“滑动窗口（丢弃最旧的对话）”还是“总结压缩”这需要后端在业务层实现，否则直接调用接口会导致400错误。

• 大海捞针（Needle In A Haystack）问题：即使模型宣称支持 128k 上下文，并不意味着它能完美提取中间段落的信息。长上下文中容易出现信息遗忘或注意力偏移（通常两头效果好，中间效果差）。

二、 Transformer 与注意力机制

我们不需要像算法工程师那样去推导复杂的数学公式，但必须在工程直觉上理解Transformer 架构和自注意力机制（Self-Attention）。

1. 下一个 Token 预测（Next-Token Prediction）

LLM 的运行逻辑非常简单：输入一段文本，模型计算出下一个最可能出现的 Token 的概率分布，然后选择一个输出；接着将这个新 Token 放入输入中，继续预测下一个。

• 状态丢失：每一次生成都是基于当前窗口内的所有 Token。模型没有“撤回”或“边想边写”的能力，它在写下第一个字时，其实并没有想好整句话怎么结尾。

为什么叫预测 Token

大模型本质上是一个概率文本续写机。它不能像人类大脑一样，在落笔前就构思好整句话的结构，它每一次只能蹦出一个词（Token）。

其工作流程是一个死循环（Loop）：

1. 输入：你给模型发了一句话："今天天气真"。

2. 预测：模型通过复杂的概率计算，从自己的词表（Vocabulary）里，挑出下一个概率最高的 Token。比如它算出来："好"的概率是 80%，"糟"的概率是 10%……

3. 输出：模型选择了"好"，并把它吐给你。

4. 滚动循环：接着，模型把"今天天气真好"整体作为新的输入，再次塞入模型，去预测下一个 Token（比如预测出"啊"）。

这个根据前文，算出下一个概率最大的词的过程，就叫做预测 Token。

Transformer 是一种革命性的神经网络架构。现今所有主流的大模型（如 GPT-4、Claude、DeepSeek、Llama），其底层的核心算法架构都是 Transformer。

在它出现之前，AI 很难处理长文本。Transformer 的出现改变了这一切，它之所以这么强大，核心在于解决了两个痛点：

1. 核心机制：自注意力机制（Self-Attention）

在 Transformer 之前，模型看句子是一字一句按顺序读的（像磁带）。读到句尾，句头就忘得差不多了。

而 Transformer 的注意力机制，让模型可以同时“看到”整句话里的所有 Token，并自动计算出词与词之间的关联权重。

举个例子：

银行把贷款利率调高了，因为他们需要控制风险。

当模型处理到他们这个 Token 时，Transformer 的注意力机制会像连线一样，给银行分配极高的权重。模型瞬间就能精准理解：这里的他们指代的就是银行。

2. 为什么要了解它

因为 Transformer 的这种“同时看所有词”的特性，导致了以下两个工程结果：

• 显存占用与上下文长度呈二次方爆炸（O(N^2)）：输入的文本越长（N越大），词与词之间两两计算关联的矩阵就呈指数级飙升。这就是为什么长上下文的 API 极其昂贵，且容易导致 GPU 显存溢出（OOM）。

• 天然支持并行计算：正因为不需要像老旧模型那样按顺序死板地读，Transformer 可以在训练时大批量并行处理海量数据，这才是今天“千亿参数大模型”能够被训练出来的技术基石。

总结来说：Transformer 是底层的机器发动机（架构），它运作的方式是通过不断地“预测下一个 Token”来生成文本，而在这个过程中，每一次计算都在消耗算力和 API 。

三、 采样参数：如何驯服模型的不确定性

调用 LLM API 时，参数配置直接决定了输出的稳定性。我们作为后端设计者，不能全用默认值，要根据业务场景精细化控制：

四、 幻觉与不确定性

1. 为什么会产生幻觉（Hallucination）

幻觉不是 Bug，它是 LLM 的原生特性。因为模型是“概率预测机”，它的目标是让句子读起来“通顺、合理”，而不是“事实正确”。当它的训练数据中缺乏相关知识，或者 Prompt 的引导存在偏见时，它就会以极其自信的语气编造事实，这些都是很常见的问题。

2. 哪些任务容易产生幻觉

• 计算与逻辑推理：模型无法在内部运行真正的数学公式，它只是在“模仿”计算题的文本格式。

• 长尾/冷门知识检索：询问知名度极低的人名、罕见的 API 用法。

• 复杂引用：让模型指出某句话出自具体哪本书的哪一页。

后端防御性思维：永远不要信任模型的直接输出。如果业务不允许幻觉（如医疗、金融、客服），必须在架构上引入RAG（检索增强生成）注入权威上下文，或者在后端使用结构化验证（如 Pydantic、Json Schema）对模型返回的数据进行强类型校验与解析重试。

五、 模型能力差异：按需选型的工程策略

在后端系统设计中，一套架构可能会组合使用多种模型。盲目追求“最贵、最强”的模型往往会导致 ROI（投资回报率）低下。我们需要区分以下五种模型能力：

• 通用对话模型（General Chat）：如 GPT-4o、Claude 3.5 Sonnet。理解复杂指令能力强，适合作为 Agent 的核心大脑，处理流程调度和复杂意图识别。

• 推理模型（Reasoning）：如 OpenAI o1 / o3 / DeepSeek-R1。这类模型在输出前会进行长期的内部“思考（CoT）”，极大地提升了数学、代码和复杂逻辑推理的准确率，但响应时间（TTFT）较长、成本较高。

• 代码模型（Code-specific）：针对语法、上下文学过专门优化的模型。适合用于代码生成、自动化补全或日志分析。

• 多模态模型（Multimodal）：能同时接收/输出文本、图片、音频。在设计后端接口时，需要考虑多媒体流式传输、二进制数据存储及文件生命周期管理。

• Embedding 模型（嵌入模型）：本质区别：它不输出文本，而是将文本转化为高维向量（Vector）。

  • 后端核心用途：它是 RAG 和向量检索的基石。后端工程师需要处理 Embedding 的批量生成、向量数据库（如 Milvus, Pinecone）的写入与相似度检索（Cosine Similarity）。

结语：

站在后端架构的角度，LLM 就像是一个极其聪明、但满嘴跑火车、偶尔还会间歇性失忆的外部依赖服务。

我们学习上述基础的目的，是为了在写下每一行调用代码时，心里都能清醒地意识到：

1. 这个接口随时可能超时（需要配置长超时与流式传输Stream）。

2. 返回的 JSON 格式随时可能崩溃（需要写好 Try-Catch 与格式修复逻辑）。

3. 模型的输出可能因为今天换了一个标点符号而完全不同（需要建立自动化评估集进行回归测试）。