企业官网建设流程全解析

1. 这不是“AI科普”，而是一份能让你亲手搭起生成式模型骨架的实操手记

我带过三十多个从零起步的生成式AI项目，最常听到的困惑不是“Transformer怎么算注意力”，而是：“我读完三篇论文，还是不知道第一行代码该写什么。”这句话背后藏着一个被严重低估的事实：生成式AI的学习曲线，根本不在理论深度上，而在概念到可运行模块之间的那层薄冰——它不厚，但踩错一步就掉进“懂了又不会做”的深坑。这篇内容，就是专门来帮你凿穿这层冰的。核心关键词是Generative AI Models、Concepts、Building Blocks，但请注意，我们不讲抽象定义，只拆解“当你打开IDE准备写第一个训练脚本时，真正需要理解的五个物理存在”：token、embedding、context window、loss function、sampling strategy。它们不是PPT里的图标，而是你调试时会报错、显存会爆、生成结果发散的具体对象。适合三类人：刚转行想快速上手的工程师、需要评估技术可行性的产品经理、以及被“大模型”三个字吓退但其实只需要用好一个微调接口的数据分析师。你不需要数学博士背景，但得愿意把“softmax温度值设为0.8”和“为什么这时候生成的句子更连贯”之间画上一根真实的线。下面所有内容，都来自我去年在电商客服对话生成、工业设备故障描述补全、医疗报告初稿辅助这三个真实场景里，反复重装CUDA、重跑实验、重改prompt后沉淀下来的硬经验。

2. 为什么必须从“构建块”切入？——避开90%初学者的逻辑断层

2.1 概念先行的陷阱：当“自回归”变成空洞口号

很多教程一上来就讲“生成式AI通过学习数据分布来建模条件概率”，听起来很对，但问题来了：你在写model.generate()时，这个“条件概率”具体对应哪一行代码？哪个tensor的shape？哪个超参数在控制它？如果答不上来，说明你还没进入实操域。我见过太多人卡在第一步：下载完Hugging Face的gpt2模型，调用pipeline("text-generation")能跑出结果，但一旦要求“只生成50个字且必须包含‘库存不足’四个字”，就彻底懵了。这不是能力问题，是知识结构断层——你缺的不是理论，而是概念到构建块的映射表。比如，“自回归”这个概念，在代码里不是一段文字描述，而是for i in range(max_length): next_token = model(input_ids); input_ids = torch.cat([input_ids, next_token], dim=1)这个循环本身；而“上下文窗口”不是教科书里的2048，而是你input_ids.shape[1]这个数字，一旦超过模型最大长度，forward就会直接报错IndexError: index out of bounds。这种映射关系，才是你调试时真正要盯住的东西。

2.2 构建块选择的底层逻辑：为什么是这五个，而不是更多或更少？

我筛掉所有花哨术语，只保留工程中不可绕过的五个物理构件，依据只有一个：它们在训练和推理链路上，必然出现且无法被封装隐藏。

• Token：不是“分词”，而是你喂给模型的最小整数ID。"hello world"被tokenizer.encode()后变成[15496, 11793]，这两个数字就是token。如果你没理解这点，后续所有关于padding、attention mask、position ID的操作都会像看天书。
• Embedding：不是“向量表示”，而是模型第一层权重矩阵model.transformer.wte.weight，它的shape是(vocab_size, hidden_size)。当你看到OOM（内存溢出）时，大概率是这个矩阵太大——vocab_size=50257、hidden_size=768，光这一层就占150MB显存。
• Context Window：不是“记忆长度”，而是model.config.max_position_embeddings这个硬编码值。GPT-2是1024，Llama-2是4096，你强行塞入4100个token，模型不会聪明地截断，而是直接崩溃。
• Loss Function：不是“交叉熵”，而是训练时loss = F.cross_entropy(logits.view(-1, logits.size(-1)), labels.view(-1), ignore_index=-100)这一行。ignore_index=-100这个参数，决定了哪些位置的预测不参与梯度计算——比如padding位、prompt位。漏掉它，loss值会虚高，模型根本学不会生成。
• Sampling Strategy：不是“随机采样”，而是torch.multinomial(torch.softmax(logits[:, -1, :] / temperature, dim=-1), num_samples=1)这个操作。temperature值小于1会让分布更尖锐（确定性高），大于1则更平缓（多样性高）。把它当成旋钮，而不是开关。

这五个构件，每一个都对应一个具体的内存地址、一个可修改的参数、一个会报错的边界。它们构成了生成式AI的“操作系统内核”，其他所有高级功能（RAG、LoRA、RLHF）都是在这个内核之上加载的驱动程序。

2.3 领域适配性：电商、工业、医疗场景如何倒逼构建块理解

不同行业对构建块的敏感度天差地别。在电商客服对话生成中，context window是生死线：用户历史咨询平均长度达3200字，但开源模型普遍只有2048窗口，硬截断会导致关键信息丢失。我们的解法不是换模型，而是重构tokenization——把“订单号：OD20240517XXXX”这类高信息密度字符串，强制映射为单个特殊token（如<ORDER_ID>），将3200字压缩到800token以内，实测准确率提升27%。在工业设备故障描述补全中，sampling strategy成了关键：维修手册要求描述绝对严谨，不能有“可能”“大概”等模糊词。我们关闭top-k采样，固定temperature=0.01，并用repetition_penalty=1.2压制重复词，生成文本的术语一致性从63%升至98%。而在医疗报告初稿辅助中，loss function的ignore_index设置出了大问题：原始数据里大量“N/A”字段被错误标记为有效label，导致模型学会胡编乱造。我们重写数据预处理脚本，对所有非文本字段打上-100，loss曲线才真正开始下降。这些都不是理论题，是每个领域里，构建块理解深度直接决定项目成败的铁证。

3. 五大构建块的实操解剖：从定义到调试现场

3.1 Token：不只是分词，而是你和模型对话的“摩斯电码”

Token是生成式AI世界的原子单位，但它的行为远比“把句子切开”复杂。以Hugging Face的AutoTokenizer为例，tokenizer("Hello, world!")返回的不仅是[15496, 11793]，还有token_type_ids=[0,0]、attention_mask=[1,1]。这三个数组，共同构成模型输入的“三原色”。token_type_ids在BERT类模型中区分句子A/B，但在纯Decoder模型（如GPT）中通常全为0，可忽略；而attention_mask却是生死线——它告诉模型：“后面这些0是padding填的，别算注意力！” 我曾因忘记传attention_mask，让模型对padding位也计算了注意力权重，生成结果全是乱码。

更隐蔽的坑在特殊token上。几乎所有tokenizer都有<s>（start）、</s>（end）、<pad>（padding）等控制符。tokenizer.encode("hi")可能返回[0, 15496, 2]，其中0和2就是start/end token。但如果你用model.generate()，它会自动添加start token；而用model.forward()手动训练时，你必须自己加。这个细节不注意，input_ids和labels的对齐就全乱了——labels应该是input_ids右移一位（即预测下一个token），但如果input_ids里没start token，labels的首位就变成了-100，loss计算直接失效。

实操技巧：永远用tokenizer.convert_ids_to_tokens()反查ID含义。比如发现loss异常高，立刻打印batch['input_ids'][0][:10]和tokenizer.convert_ids_to_tokens(batch['input_ids'][0][:10])，看是不是混入了意外token（如中文标点被切成多个子词）。我在线上环境部署时，就靠这招揪出过一个bug：日志系统把\n转义成\\n，tokenizer将其识别为两个独立token，导致每行文本多出1个无效token，最终context window提前耗尽。

3.2 Embedding：那个吃掉你80%显存的“隐形巨兽”

Embedding层是模型里最“贪吃”的部分。以Llama-2-7b为例，其wte.weight（token embedding）和wpe.weight（position embedding）合计占显存约1.2GB，而整个模型参数才3.5GB。这意味着，哪怕你只加载embedding层，显存也快见底了。更麻烦的是，embedding不是静态的——它在训练中持续更新。当你用LoRA做微调时，实际是在wte.weight旁边挂了一个小矩阵，所有梯度更新都先流经这个小矩阵，再影响主矩阵。所以，如果你的LoRA rank设得太小（如r=4），embedding更新就僵化，模型记不住新领域的专有名词；设得太大（如r=64），小矩阵本身又吃显存，得不偿失。我们测试过，在医疗报告任务中，r=16是最佳平衡点：既能学会“心肌梗死”“ST段抬高”等术语，又不拖慢训练速度。

另一个致命误区是混淆embedding和hidden state。很多人以为“模型输出的向量就是embedding”，这是错的。model(input_ids).last_hidden_state是最后一层的输出，shape为(batch, seq_len, hidden_size)，而model.transformer.wte.weight才是真正的embedding矩阵。前者是动态计算结果，后者是静态参数。当你想提取句子向量做聚类时，应该用last_hidden_state[:, 0, :]（取[CLS]位），而不是去扒wte.weight——后者维度是(vocab_size, hidden_size)，跟句子无关。

调试经验：显存爆炸时，第一反应不是“升级GPU”，而是检查embedding。用torch.cuda.memory_summary()打印显存分配，如果wte.weight占了90%，说明你的vocab_size可能被错误放大。比如，误把tokenizer.add_tokens(["<NEW_ENT>"])执行了100次，导致词表凭空多出100个token，embedding矩阵瞬间膨胀。解决方案：每次add_tokens后，立刻print(len(tokenizer))确认词表大小。

3.3 Context Window：不是参数，而是你必须跪着遵守的“物理法则”

Context window不是软件设置，是模型架构的硬约束。它由max_position_embeddings（位置编码最大长度）和rope_theta（RoPE旋转基频）共同决定。Llama-2的max_position_embeddings=4096，意味着你最多喂4096个token进去；超过这个数，forward函数会抛出IndexError。但更狡猾的是，有些模型（如Qwen）支持NTK-aware RoPE插值，能把窗口扩展到32768，但这需要手动修改config.json里的rope_theta值，并重置位置编码缓存。我们试过直接改config，结果模型输出全是重复词——因为RoPE的cos/sin缓存没清，旧缓存和新theta不匹配。最终解法是：在model.forward()前，强制model.model.rotary_emb._set_cos_sin_cache()，重新生成缓存。

实际业务中，window不够怎么办？常见方案有三：

1. 截断（Truncation）：最简单，但丢信息。我们曾用tail truncation（截尾），结果把用户咨询的最后关键句“请尽快补货”截掉了。
2. 滑动窗口（Sliding Window）：把长文本切成重叠块，分别生成，再拼接。但拼接处容易语义断裂。我们加了overlap=128，并在拼接时用model.generate(..., do_sample=False)确保重叠区一致，效果尚可。
3. 检索增强（RAG）：这才是正解。把长文档存在向量库，只把最相关的3个片段+当前query喂给模型。我们用sentence-transformers/all-MiniLM-L6-v2做嵌入，召回Top3后，用<CONTEXT>{text}</CONTEXT>格式注入prompt，context window压力骤降70%。

关键提醒：max_length参数在generate()中不是context window，而是生成长度上限。model.generate(input_ids, max_length=100)的意思是“最多生成100个token”，不是“最多处理100个token”。如果你的input_ids已有500个token，max_length=100会导致总长度超限报错。正确写法是max_new_tokens=100，它明确表示“新生成100个token”，与输入长度无关。

3.4 Loss Function：那个默默决定模型“学不学得会”的幕后裁判

生成式模型的loss，本质是“预测下一个token的交叉熵”。但它的实现细节，直接决定训练是否收敛。核心公式是：
loss = -log(softmax(logits)[true_token_id])
其中logits是模型输出的未归一化分数，true_token_id是标签中对应位置的真实token ID。这里有两个魔鬼细节：

• Label Shift（标签偏移）：labels必须是input_ids右移一位。例如，input_ids = [1,2,3,4]，则labels = [-100,1,2,3]（首位置-100表示忽略，因无前置token可预测）。如果错写成labels = [1,2,3,4]，模型就在学“预测当前token”，这毫无意义。
• Ignore Index（忽略索引）：-100是PyTorch交叉熵的魔法值，表示该位置不参与loss计算。但很多人不知道，-100必须严格等于整数-100，写成-100.0或torch.tensor(-100)都无效！我们曾因数据预处理脚本里用了np.int64(-100)，导致loss计算时跳过所有padding位，模型在训练集上loss=0，一到验证集就崩盘。

调试loss的黄金法则：在训练循环里，每100步打印loss.item()、logits.max().item()、logits.min().item()。如果logits范围在[-5,5]而loss却>10，说明标签对齐错了；如果logits范围突然变成[-1000,1000]，说明梯度爆炸，得立刻加gradient_clip_val=1.0。我们有个血泪教训：在工业设备数据上，因传感器读数含大量NaN，预处理时误将NaN转为token0，导致模型疯狂预测0，loss虚低，但生成全是乱码。后来改成NaN统一映射为特殊token<NAN>，并加入label_smoothing=0.1，问题才解决。

3.5 Sampling Strategy：那个把“概率分布”变成“确定文本”的终极开关

生成不是“选最高分”，而是“按概率抽样”。model.generate()默认用do_sample=False（贪婪搜索），即每步都选logits.argmax()。这保证确定性，但缺乏多样性。一旦开启do_sample=True，就进入采样世界，此时四大策略登场：

• Temperature Scaling：logits /= temperature。temperature=0.5让高分token概率更高，temperature=2.0让低分token也有机会。我们发现，电商文案生成用temp=0.7，工业报告用temp=0.3，医疗摘要用temp=0.1——越严谨的领域，温度越低。
• Top-k Sampling：只从top-k个最高分token中采样。k=1等价于贪婪搜索；k=50则引入可控随机性。但k值需随vocab_size调整：vocab_size=50000时，k=50太小，模型易陷入局部重复；我们用k=int(vocab_size*0.001)动态计算。
• Top-p (Nucleus) Sampling：累积概率超过p的最小token集合。p=0.9意味着“选概率和达到90%的最少token”。它比top-k更智能，因词汇分布不均。但p值敏感：p=0.95在中文上效果好，p=0.8在英文上更自然。
• Repetition Penalty：对已生成token的logits减分，抑制重复。penalty=1.2是安全起点，但医疗文本中，penalty=1.5才能压制“患者患者患者”这种病。

实操陷阱：采样参数必须在generate()调用时传入，不能在模型初始化时设。我们曾把temperature写在model.config.temperature里，结果完全无效——因为generate()根本不读这个字段！正确姿势是：model.generate(..., temperature=0.7, top_p=0.9)。另外，num_return_sequences（生成多条）和early_stopping=True（早停）配合使用，能避免无限生成。我们线上服务就用num_return_sequences=3, early_stopping=True，取三条中perplexity最低的一条返回，响应质量稳定提升。

4. 从零搭建第一个生成式AI流程：电商客服对话生成实战

4.1 环境与工具链：拒绝“pip install一切”

不要用pip install transformers一把梭哈。生产环境必须精确锁定版本，否则transformers==4.36.0和4.37.0之间可能有API断裂。我们的标准栈：

• Python 3.10（兼容性最好）
• PyTorch 2.1.0+cu118（CUDA 11.8，避免新版cu12.x的兼容问题）
• Transformers 4.35.2（Llama-2支持最稳的版本）
• Accelerate 0.25.0（分布式训练必需）
• Bitsandbytes 0.41.2（4-bit量化）

安装命令必须带--no-deps：

pip install torch==2.1.0+cu118 torchvision==0.16.0+cu118 --extra-index-url https://download.pytorch.org/whl/cu118 pip install transformers==4.35.2 accelerate==0.25.0 bitsandbytes==0.41.2 --no-deps

为什么？因为transformers依赖的tokenizers版本若与datasets冲突，load_dataset()会静默失败。我们吃过亏：tokenizers==0.13.3和datasets==2.14.0不兼容，导致数据加载时tokenize()返回空列表，训练loss=nan。解决方案是：pip install tokenizers==0.13.2 datasets==2.13.0，版本锁死。

4.2 数据准备：不是“清洗”，而是“构建token级真相”

电商客服数据不是CSV文件，而是token序列。我们拿到的原始数据是：

用户：订单OD20240517001的物流怎么还没更新？ 客服：您好，该订单已于5月17日发货，物流单号SF123456789，预计5月20日送达。

直接喂给模型？不行。问题有三：

1. 订单号OD20240517001被切分为["OD", "2024", "05", "17", "001"]，模型学不会整体概念；
2. 物流单号SF123456789同理，且数字序列易被泛化为任意数字；
3. “5月17日”“5月20日”中的“5”会被当成普通数字，失去日期语义。

解法：定制化tokenization。

• 步骤1：用正则预处理，把OD\d{9}替换为<ORDER_ID>，SF\d{9}替换为<LOGISTICS_NO>，\d{4}年\d{1,2}月\d{1,2}日替换为<DATE>。
• 步骤2：用tokenizer.add_tokens(["<ORDER_ID>", "<LOGISTICS_NO>", "<DATE>"])扩充词表。
• 步骤3：在encode()时，确保这些特殊token不被进一步切分——tokenizer.add_special_tokens({"additional_special_tokens": ["<ORDER_ID>"]})，并设is_split_into_words=False。

数据格式必须是{"text": "用户：<ORDER_ID>的物流... 客服：<LOGISTICS_NO>..."}，而非分开的user/chat字段。因为模型需要学习“用户-客服”的对话模式，不是孤立句子。我们用datasets.load_dataset("json", data_files="data.json")加载，再map()函数做上述预处理。关键技巧：map()时设batched=True, batch_size=1000，比逐条处理快12倍。

4.3 模型加载与微调：4-bit量化不是噱头，是生存必需

7B模型FP16加载需14GB显存，而我们用的A10（24GB）还要跑数据加载、梯度计算。不用量化，寸步难行。4-bit量化（QLoRA）是唯一解：

from transformers import BitsAndBytesConfig bnb_config = BitsAndBytesConfig( load_in_4bit=True, bnb_4bit_quant_type="nf4", bnb_4bit_compute_dtype=torch.float16, bnb_4bit_use_double_quant=True, ) model = AutoModelForCausalLM.from_pretrained( "meta-llama/Llama-2-7b-hf", quantization_config=bnb_config, device_map="auto" )

注意device_map="auto"，它会自动把embedding层放GPU，其余层放CPU/硬盘，但bnb_4bit_use_double_quant=True能减少量化误差。我们实测，开启double quant后，生成文本的术语准确率从82%升至89%。

微调不碰全参数，只训LoRA：

from peft import LoraConfig, get_peft_model lora_config = LoraConfig( r=16, # rank lora_alpha=32, target_modules=["q_proj", "v_proj"], # 只训注意力的Q/V矩阵 lora_dropout=0.05, bias="none" ) model = get_peft_model(model, lora_config)

为什么选q_proj和v_proj？因为注意力机制中，Q（Query）决定“找什么”，V（Value）决定“拿什么”，它们最影响生成的相关性。我们对比过，只训q_proj，模型记不住新订单号；只训v_proj，生成逻辑混乱；两者合训，效果最佳。

4.4 训练配置：learning_rate不是调出来的，是算出来的

LR不是玄学。我们用cosine学习率调度，峰值LR按公式：
LR = 2e-5 * sqrt(batch_size / 128)
其中128是基准batch size。我们用per_device_train_batch_size=4，gradient_accumulation_steps=8，num_devices=2，实际batch size=482=64，所以LR=2e-5 * sqrt(64/128)=1.41e-5。

训练循环必须加gradient_clip_val=1.0，否则logits爆炸。我们还加了save_strategy="steps"和save_steps=500，每500步存一次checkpoint。但重点是eval_steps=100和evaluation_strategy="steps"——每100步在验证集上跑一次perplexity。如果perplexity连续3次不降，就load_best_model_at_end=True回滚。

日志监控用WandbCallback，但关键指标不是loss，而是eval_loss和gen_len（生成长度）。我们发现，当gen_len突然从平均45降到20，说明模型开始“偷懒”，只生成短句应付，这时要立刻检查数据是否混入了大量短样本。

4.5 推理部署：不是model.generate()，而是“可控生成流水线”

线上服务不能裸跑generate()。我们封装成三层流水线：

• Input Layer：接收原始query，用正则提取<ORDER_ID>等实体，填充到prompt模板：
  "用户：{query} 客服："
• Generation Layer：调用model.generate()，参数严格锁定：

  output = model.generate( input_ids=input_ids, max_new_tokens=128, temperature=0.6, top_p=0.9, repetition_penalty=1.3, do_sample=True, pad_token_id=tokenizer.eos_token_id, eos_token_id=tokenizer.eos_token_id )

  注意pad_token_id和eos_token_id必须显式指定，否则在batch生成时，不同长度序列的padding位会干扰eos判断。
• Post-process Layer：对生成文本做三件事：
  1. 截断到第一个</s>或\n（防止生成过长）；
  2. 用正则还原<ORDER_ID>为真实订单号（re.sub(r"<ORDER_ID>", order_id, text)）；
  3. 检查是否含禁用词（如“抱歉”“无法”），若含则触发fallback逻辑，返回预设话术。

压测时，单卡A10（24GB）QPS达23，P99延迟<800ms。关键优化是torch.compile(model)——PyTorch 2.0的图编译，让推理快了1.8倍。但注意：compile()只支持torch>=2.0，且首次调用有2秒冷启动，需在服务启动时预热。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 “Loss不下降”问题速查表

我们最惨的一次：loss=nan，查了三天。最后发现是tokenizer.encode()时truncation=True, padding=True，但max_length设得太小（512），导致长文本被截断后，input_ids全为<pad>，labels全为-100，cross_entropy输入全零logits，直接nan。解决方案：truncation=True时，必须设max_length=None，让tokenizer按模型最大长度自动截断。

5.2 “生成结果乱码/重复”问题根因分析

乱码（如``、<0x80>）90%是编码问题：训练时用utf-8读数据，但数据源是gbk，导致中文被解码为乱码token。解决方案：open(file, encoding="gbk")，或统一转utf-8。

重复（如“库存库存库存”）有三大元凶：

• Repetition Penalty缺失：generate()没设repetition_penalty，模型陷入局部循环。
• Position ID错乱：input_ids长度超max_position_embeddings，位置编码复用，模型“认不出自己刚说过什么”。
• EOS token未终止：eos_token_id没传，模型生成到max_length才停，中间无终止符。

我们有个经典案例：工业设备报告生成，重复“故障故障故障”。print(tokenizer.convert_ids_to_tokens(output[0]))发现，output末尾全是<unk>token（ID=0）。追查发现，tokenizer的unk_token_id被误设为0，而模型输出logits的第0位恰好很高。解法：tokenizer.unk_token_id = tokenizer.eos_token_id，强制UNK=EOS。

5.3 “显存OOM”问题应急指南

OOM不是GPU不够，是内存管理失误。优先检查：

1. Batch Size：per_device_train_batch_size=1，看是否还OOM。若是，问题在模型；若否，调小batch。
2. Gradient Checkpointing：加use_cache=False和gradient_checkpointing=True，显存降40%。但注意：use_cache=False会让推理变慢，训练时开，推理时关。
3. Offload：device_map="balanced_low_0"，把部分层卸载到CPU。我们用accelerate launch时加--mixed_precision=fp16 --cpu_offload，A10上跑7B模型成功。
4. 4-bit Quantization：最后手段，但必须用bnb_4bit_quant_type="nf4"（比fp4精度高），且bnb_4bit_use_double_quant=True。

我们曾为省事，用device_map="sequential"，结果embedding层占满GPU，其余层全在CPU，训练慢如蜗牛。后来改"auto"，让Hugging Face自动分配，速度提升3倍。

5.4 “部署后响应慢”性能瓶颈定位

线上P99延迟>1s，按此顺序排查：

• I/O瓶颈：cat /proc/diskstats看磁盘IO，若await>100ms，说明模型权重从SSD加载太慢。解法：model = model.to("cuda")前，先torch.load(..., map_location="cpu")到内存，再to("cuda")。
• Tokenization瓶颈：timeit测tokenizer.encode()耗时。若>50ms，说明正则预处理太重。解法：把正则编译成re.compile()对象，全局复用。
• GPU计算瓶颈：nvidia-smi dmon -s u看GPU利用率。若<30%，说明数据加载阻塞。解法：DataLoader加num_workers=4, pin_memory=True，预加载到GPU内存。
• Python GIL瓶颈：多进程服务下，generate()调用被GIL锁住。解法：用multiprocessing启动独立进程跑generate()，主进程只做网络IO。

我们线上服务最终方案：Nginx负载均衡 + 4个FastAPI进程（每个绑1个GPU） +uvloop加速异步IO。单节点QPS从12飙到89。

6. 实操心得：那些让我少走两年弯路的硬核经验

第一次跑通生成式AI，不是在Jupyter里打出“Hello World”，而是在凌晨三点，盯着loss=nan的日志，把tokenizer源码翻到第372行，发现padding_side="left"导致attention_mask全0，从而让模型对padding位也计算了注意力——那一刻，我才真正摸到了生成式AI的脉搏。这些经验，没有一篇论文会写，但它们决定了你是“会调参的工程师”，还是“能解决问题的专家”。

第一个心得：永远相信token，而不是文字。当生成结果不对，第一反应不是“模型坏了”，而是print(tokenizer.convert_ids_to_tokens(input_ids[0]))和tokenizer.convert_ids_to_tokens(output[0])。我们曾为“为什么生成不了‘缺货’二字”纠结一周，最后发现，tokenizer把“缺货”切成了["缺", "货"]，而训练数据里99%的“缺货”都出现在“库存缺货”中，模型学会了预测“库存”后接“缺”，但单独预测“缺”时概率极低。解法：在add_tokens()里加入["缺货"]作为整体token，问题立解。

第二个心得：context window不是长度，是信息密度。与其拼命扩窗口，不如压缩信息。我们把电商咨询里的“用户ID：U123456”全部替换成<USER>，把“时间：2024-05-17 14:22:33”替换成<TIME>，同样500字