企业官网建设流程全解析

1. 这8个问题不是考知识，而是筛掉“没真正用过LLM”的人

最近帮某高校实验室做一次AI方向的实习生筛选，面试了23位声称“熟悉大模型”的候选人。结果令人意外：17人卡在第一个问题——“你本地跑过哪个开源LLM？用什么方式加载的？显存占用多少？”——不是答错，是根本没跑过。有人脱口而出“我用ChatGLM”，我问：“你本地加载的是int4量化版还是FP16原生权重？用transformers还是llama.cpp？显存峰值出现在哪一步？”对方愣住，说“我……主要用网页版”。

这就是标题里“答不上来直接淘汰”的真实语境。它不是在考教科书定义，也不是测背诵能力，而是一套行为验证型问题集：通过8个高度具象、无法凭空编造的操作细节提问，快速识别出谁真正在终端敲过命令、改过配置、调过参数、踩过OOM、修过tokenizer报错。它背后有一套隐性逻辑链：能说清“为什么用vLLM而不是Text Generation Inference” → 意味着你部署过服务；能复现“LoRA微调时rank=8和rank=16对显存的影响差异” → 说明你亲手跑过训练脚本；能解释“为什么Qwen2-7B在推理时要加use_cache=True但微调时必须关掉” → 证明你读过源码注释。

这8个问题，本质是8个最小可行实践锚点（Minimum Viable Practice Anchor）。每个锚点都绑定一个不可伪造的动作：下载权重、修改config、观察log、对比profile、调试CUDA kernel。它们共同构成一道“动手真实性过滤网”。我见过太多简历写“精通Llama 3微调”的人，连HuggingFace Hub上模型card里那个小图标（🟢表示已验证可加载）都没点开看过。所以这篇不讲“标准答案”，只还原这8个问题背后的真实操作现场——包括我当时在实验室白板上随手画的内存分配草图、终端里滚动的nvidia-smi截图时间戳、以及三次失败重试后才跑通的accelerate launch命令完整参数。

提示：如果你现在心里想“我好像没做过其中几项”，别急着焦虑。这恰恰是本文的价值起点——我们不是比谁起点高，而是看谁能最快补上那条“从知道到做到”的断层线。下文每个问题都会附带一条“零基础可启动”的实操路径，不需要GPU服务器，一台16GB内存的MacBook Pro就能完成全部验证。

2. 问题1：你本地加载过哪个开源LLM？用什么方式加载？显存/内存占用多少？

这个问题看似简单，却是整套筛选体系的“第一道闸门”。它直指一个核心事实：所有LLM应用能力都建立在“加载成功”这个物理动作之上。没有加载，就没有推理，没有微调，没有RAG，一切上层架构都是空中楼阁。

2.1 为什么必须问“用什么方式加载”？

因为加载方式直接暴露技术栈深度。我们拆解三种主流路径：

• Transformers + AutoModelForCausalLM：最通用，但默认加载FP16权重。以Qwen2-1.5B为例，在RTX 4090上显存占用约3.2GB。但很多人不知道：device_map="auto"会把embedding层扔进CPU，导致首次推理慢200ms以上——这是实测数据，不是理论值。

• llama.cpp + GGUF量化：轻量级首选。用q4_k_m量化后的Qwen2-1.5B仅需1.1GB内存（非显存），MacBook M1 Pro可流畅运行。但陷阱在于：--ctx-size 4096参数若设错，会触发token截断却无报错，输出突然变短——我见过3位候选人栽在这里，坚称“模型坏了”，其实是上下文长度配置失误。

• vLLM + PagedAttention：生产部署方案。加载Qwen2-1.5B时显存占用仅2.4GB（比transformers低25%），但必须配合--tensor-parallel-size 1启动。曾有候选人说“vLLM更快”，我追问：“你测过PagedAttention的page size对吞吐量的影响吗？”对方沉默——这说明他只复制了启动命令，没理解底层机制。

2.2 如何现场验证“显存/内存占用”？

不能靠嘴说，必须给方法论。以下是我在实验室用的标准三步法：

1. 预热与基线测量：

   # 启动前先清空GPU缓存（关键！） nvidia-smi --gpu-reset -i 0 2>/dev/null || true # 记录空载显存 nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits

2. 加载过程实时监控：
   在另一个终端执行：

   watch -n 0.1 'nvidia-smi --query-gpu=memory.used --format=csv,noheader,nounits'

   同时在主终端运行加载脚本。你会看到显存数字跳变：从0→1.2GB（加载权重）→2.8GB（初始化KV cache）→稳定在3.2GB。这个跳变过程就是验证“真加载”的铁证。

3. 内存占用交叉验证：
   对于llama.cpp这类CPU方案，用htop按F6选MEM%排序，找到main进程，观察RES列。Qwen2-1.5B q4_k_m量化版典型值为1.08GB——注意是“RES”不是“VIRT”，后者包含mmap映射的磁盘文件，会虚高。

注意：所有数值必须标注硬件环境。我在M1 Pro上测得llama.cpp内存占用1.1GB，但在Intel i7-11800H上是1.3GB（AVX指令集优化差异）。说“大概1GB”等于没说——真实工程世界里，±0.2GB就决定能否塞进边缘设备。

2.3 零基础实操路径：15分钟验证你的第一个LLM加载

不需要买GPU，用MacBook或Windows笔记本即可：

1. 安装llama.cpp（5分钟）：

   git clone https://github.com/ggerganov/llama.cpp cd llama.cpp && make clean && MAKEFLAGS="-j$(nproc)" make

2. 下载量化模型（3分钟）：
   去HuggingFace Hub搜Qwen2-1.5B-Instruct-GGUF，下载qwen2-1.5b-instruct.Q4_K_M.gguf（约1.1GB）。

3. 加载并监控（7分钟）：

   # 终端1：启动监控 htop # 终端2：运行模型（自动检测CPU核心数） ./main -m ./qwen2-1.5b-instruct.Q4_K_M.gguf -p "你好" -n 32

   观察htop中main进程的RES值是否稳定在1.0~1.15GB之间。如果超过1.3GB，检查是否误下了Q5_K_M版本（体积更大）。

这是我给实习生布置的“入职第一题”。23人中仅9人能在30分钟内完成全流程并准确报告数值。剩下的人要么卡在make报错（缺Xcode命令行工具），要么下载了错误GGUF文件（没注意文件名后缀），要么把-n 32当成“生成32个token”却不知这是最大长度限制——这些细节，正是区分“用过”和“看过”的分水岭。

3. 问题2：你调过哪些推理参数？为什么选这个值？效果差异有多大？

如果说问题1验证“能不能加载”，问题2则检验“会不会调优”。这里没有标准答案，只有参数选择背后的决策链。面试官真正想听的，是你如何在延迟、质量、资源三者间做权衡取舍。

3.1 温度（temperature）不是“越低越好”

新手常犯的错误是把temperature设成0.1，认为“更确定”。但实测Qwen2-1.5B在temperature=0.1时，连续5次相同prompt的输出重复率高达68%（用ROUGE-L计算）。而temperature=0.7时，多样性提升至82%，同时保持事实一致性（人工抽检100条，错误率仅3.2% vs 0.1时的5.7%）。

关键洞察：temperature影响的是logits分布的平滑度，不是“正确率”本身。我画过一张图给实习生看：横轴是token概率，纵轴是采样次数。temperature=0.1时，曲线像一根尖刺，顶部几个token垄断90%采样；temperature=0.7时，曲线呈宽峰，Top-10 token都有合理出现机会——这正是人类写作的节奏感。

3.2 top_p（nucleus sampling）的隐藏陷阱

top_p=0.9是常见推荐值，但它在长文本生成中会引发“尾部衰减”。测试发现：当生成长度>512 token时，Qwen2-1.5B在top_p=0.9下，最后128 token的困惑度（perplexity）飙升47%。原因在于：随着KV cache增长，有效词汇表动态收缩，固定top_p导致候选集过窄。

解决方案是动态top_p：

# 实际部署中用的策略 def adaptive_top_p(current_length, max_length=2048): if current_length < max_length * 0.3: return 0.95 elif current_length < max_length * 0.7: return 0.90 else: return 0.85 # 尾部放宽，避免卡死

这个函数让模型在收尾阶段更敢于探索，实测使长文档结尾连贯性提升31%（人工评分）。

3.3 max_new_tokens：被严重低估的“安全阀”

很多人把max_new_tokens当成“想要多少就设多少”，却不知它直接关联OOM风险。Qwen2-1.5B在RTX 4090上，max_new_tokens=2048时显存峰值比1024高39%——不是线性增长，而是指数级。因为KV cache大小 = batch_size × seq_len × n_layers × hidden_size，其中seq_len包含max_new_tokens。

我的经验公式：
安全max_new_tokens ≤ (GPU显存GB数 × 1024) ÷ 8
（适用于7B级模型，int4量化）
例如24GB显存：24×1024÷8 ≈ 3072 → 但实际建议设2048，留30%余量防突发。

提示：面试时若被问“为什么设这个值”，不要只说“经验”，要给出可验证的依据。比如：“我用torch.cuda.memory_summary()对比过2048和4096的reserved memory，前者峰值7.2GB，后者11.8GB，超出我卡的8GB阈值，所以降为2048”。这种回答，面试官立刻知道你真干过。

3.4 零基础实操：用10行代码验证参数影响

无需训练，用公开API即可验证（免费额度足够）：

from transformers import AutoTokenizer, AutoModelForCausalLM import torch model = AutoModelForCausalLM.from_pretrained("Qwen/Qwen2-1.5B-Instruct", torch_dtype=torch.float16).cuda() tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2-1.5B-Instruct") prompt = "请用三句话描述光合作用" inputs = tokenizer(prompt, return_tensors="pt").to("cuda") # 测试temperature=0.1 output_low = model.generate(**inputs, temperature=0.1, max_new_tokens=64) print("T=0.1:", tokenizer.decode(output_low[0], skip_special_tokens=True)) # 测试temperature=0.7 output_high = model.generate(**inputs, temperature=0.7, max_new_tokens=64) print("T=0.7:", tokenizer.decode(output_high[0], skip_special_tokens=True))

重点观察两点：

1. output_low是否出现重复短语（如“光合作用是...光合作用是...”）
2. output_high是否出现轻微事实偏差（如把叶绿体说成线粒体）

这才是参数调优的本质：在可控范围内接受微小噪声，换取表达丰富性。没有银弹，只有权衡。

4. 问题3：你处理过Tokenizer的哪些坑？怎么定位和修复的？

Tokenizer是LLM的“呼吸系统”，90%的诡异bug都藏在这里。面试官问这个问题，是在探测你是否具备底层协议调试能力——当模型输出乱码、截断、或莫名卡住时，你第一反应是查tokenizer还是骂模型？

4.1 最经典的坑：special_tokens_map.json缺失

某次部署Qwen2-1.5B到Docker时，服务启动后所有请求返回空字符串。日志显示generate()返回空list。排查3小时后发现：Docker镜像里只拷贝了pytorch_model.bin，漏了tokenizer.json和special_tokens_map.json。AutoTokenizer.from_pretrained()在找不到special_tokens_map.json时，会静默回退到默认BOS/EOS token，而Qwen2的EOS是<|im_end|>，不是常规的</s>——导致模型永远等不到结束符，无限生成直到超时。

修复方案极其简单：

# Dockerfile里必须显式拷贝 COPY tokenizer.json special_tokens_map.json ./

但关键是如何快速定位？我的方法是：

# 加载后立即验证 tokenizer = AutoTokenizer.from_pretrained("./model_dir") print("BOS token:", tokenizer.bos_token, tokenizer.bos_token_id) print("EOS token:", tokenizer.eos_token, tokenizer.eos_token_id) print("PAD token:", tokenizer.pad_token, tokenizer.pad_token_id)

如果输出None或-1，立刻停手检查文件完整性。

4.2 编码不一致：UTF-8 vs CP1252的隐形战争

Windows用户常遇到：本地测试正常，部署到Linux服务器后中文全变。根源是Windows记事本默认用CP1252编码保存prompt文件，而Linux Python默认用UTF-8读取。tokenizer.encode()收到乱码字节后，会将其映射到未知token ID，最终输出不可预测。

验证方法：

# 检查原始字符串字节 prompt = "你好世界" print([hex(b) for b in prompt.encode('utf-8')]) # 正确应为 [0xe4, 0xbd, 0xa0, ...] print([hex(b) for b in prompt.encode('cp1252')]) # 错误会出 [0x81, 0x82, ...] # tokenizer内部编码验证 ids = tokenizer.encode(prompt) print("Token IDs:", ids) print("Decoded back:", tokenizer.decode(ids)) # 若不等于原prompt，编码已损坏

4.3 truncation的双重陷阱

truncation=True看似安全，实则暗藏两层风险：

• 第一层：截断位置错误
  默认truncation="longest_first"，对多轮对话会优先截前面的历史，保留最后的user query——这违背常识。应强制truncation="only_last"，确保历史被压缩，query完整保留。

• 第二层：截断后未重加special tokens
  Qwen2要求每轮对话以<|im_start|>user开头，<|im_end|>结尾。若截断发生在中间，可能切掉<|im_end|>，导致模型等待结束符而卡死。解决方案是：

  # 截断后手动补全 input_ids = tokenizer.encode(prompt, truncation=True, max_length=2048) if input_ids[-1] != tokenizer.eos_token_id: input_ids.append(tokenizer.eos_token_id)

4.4 零基础排坑实战：3分钟定位tokenizer问题

当你遇到“模型输出异常”时，按此流程：

1. 打印原始输入字节：

   prompt = "你的prompt" print("Raw bytes:", prompt.encode('utf-8'))

2. 打印tokenizer分词结果：

   tokens = tokenizer.convert_ids_to_tokens(tokenizer.encode(prompt)) print("Tokens:", tokens[:10], "...") # 看前10个是否合理

3. 反向解码验证：

   ids = tokenizer.encode(prompt) decoded = tokenizer.decode(ids, skip_special_tokens=False) print("Round-trip:", decoded == prompt) # 必须为True

如果第3步为False，问题100%在tokenizer。此时检查tokenizer_config.json里的add_prefix_space、clean_up_tokenization_spaces等字段——这些冷门参数，才是区分“用过”和“调过”的试金石。

5. 问题4：你微调过哪个模型？用什么数据？怎么验证效果的？

微调是LLM落地的核心环节，但面试官不关心你“有没有微调”，而关注你如何定义问题、设计验证、归因失败。一个真实的微调项目，至少包含三个不可省略的环节：数据清洗的脏数据比例统计、验证集构建的分布偏移分析、效果评估的bad case归类。

5.1 数据层面：为什么80%的微调失败源于数据

我复现过12个开源微调项目，其中9个在验证集上loss下降但业务指标恶化。根因全是数据问题：

• 标签噪声：某法律问答数据集，标注员将“刑法第232条”误标为“刑法第233条”，模型学到错误映射。用scikit-learn的LabelNoiseDetector扫描，发现12.7%样本存在此类矛盾。

• 分布偏移：训练数据90%是“咨询类”问题（如“怎么申请房贷”），但线上流量70%是“投诉类”（如“银行乱收费怎么办”）。模型在咨询类F1=0.89，投诉类骤降至0.41。

• 长度失配：训练数据平均长度32 tokens，但线上用户提问平均128 tokens。模型在长输入时attention mask失效，产生幻觉。

我的数据质检清单：

5.2 微调方法选择：LoRA不是万能钥匙

LoRA（Low-Rank Adaptation）因显存友好被滥用，但它有明确适用边界：

• 适合场景：领域适配（如医疗、法律）、风格迁移（如公文转口语）、小样本增强（<1000条）。Qwen2-1.5B用LoRA微调，rank=8时显存增加仅0.3GB。

• 不适合场景：任务本质改变（如把问答模型改成摘要模型）、需要修改模型结构（如加额外head）。曾有候选人用LoRA强行让Qwen2做NER，F1仅0.23——因为NER需要token-level分类，而LoRA只改attention输出，不碰FFN层。

正确做法是混合微调：

• LoRA调attention层（节省显存）
• 全参微调最后2层MLP（提升任务适配）
• 冻结embedding层（防止词表漂移）

实测Qwen2-1.5B在此配置下，医疗问答F1从0.68→0.79，显存增量仅0.8GB（vs全参微调的3.2GB）。

5.3 效果验证：拒绝“准确率”幻觉

业务场景中，“准确率”是危险指标。举个真实案例：某客服微调项目，测试集准确率92%，但上线后用户投诉率上升40%。根因是模型学会了“安全回答”——对所有不确定问题统一回复“请咨询人工客服”，这在测试集里被判正确（因label是“转人工”），但用户体验极差。

我的验证三支柱：

1. 业务指标：首响时间≤3秒占比、一次解决率（FCR）
2. 鲁棒性测试：用TextAttack生成对抗样本，模型在扰动下FCR下降<5%
3. 人工盲测：邀请5位业务专家，对100条输出打分（1-5分），要求Kappa系数>0.75

注意：所有验证必须在独立于训练集的线上流量抽样上进行。用训练集划分的validation set，只能反映过拟合程度，不能预测线上表现。

5.4 零基础微调：用Colab免费跑通Qwen2-1.5B LoRA

无需配置环境，30分钟完成：

1. 打开Google Colab，新建Notebook
2. 运行以下代码（已预装依赖）：

   !pip install peft transformers datasets accelerate bitsandbytes from peft import LoraConfig, get_peft_model from transformers import AutoModelForCausalLM, TrainingArguments, Trainer # 加载基础模型（自动量化） model = AutoModelForCausalLM.from_pretrained( "Qwen/Qwen2-1.5B-Instruct", load_in_4bit=True, device_map="auto" ) # 配置LoRA peft_config = LoraConfig( r=8, # rank lora_alpha=16, target_modules=["q_proj", "v_proj"], # 只改attention lora_dropout=0.1, bias="none" ) model = get_peft_model(model, peft_config)

3. 用HuggingFace Datasets加载公开的mlqa子集（已清洗）
4. 启动训练：trainer.train()

关键观察点：

• 训练日志中loss是否平稳下降（非震荡）
• nvidia-smi显存是否稳定在~6.2GB（4bit+LoRA）
• 生成测试时，model.generate()是否仍支持temperature等参数（验证PEFT集成正确）

这比背100道理论题更能证明你“会微调”。

6. 问题5：你部署过LLM服务吗？用什么框架？怎么压测的？

部署是LLM从实验室走向生产的关键跃迁。这个问题直击工程闭环能力：能否把本地跑通的模型，变成稳定、可观测、可伸缩的服务？很多候选人能调参，却说不出vLLM的--block-size设为16和32对P99延迟的影响。

6.1 框架选型：vLLM vs TGI vs Text Generation Service

三者核心差异不在功能，而在设计哲学：

真实案例：某金融客户用TGI部署Qwen2-1.5B，设置-b 128（batch size），但实际流量burst时P99延迟飙到8.2秒。换成vLLM后，--max-num-seqs 256+--block-size 16，P99降至1.3秒——因为PagedAttention能动态分配显存块，避免TGI的静态cache碎片。

6.2 压测不是跑ab命令，而是建模请求模式

多数人用ab -n 1000 -c 100压测，这毫无意义。真实线上流量有三大特征：

• 长尾分布：80%请求<1KB，但20%请求>10KB（含附件解析）
• 突发性：每小时有3-5次流量尖峰（如营销活动开始）
• 语义相关性：同一用户连续请求有上下文关联（如多轮对话）

我的压测方案：

1. 录制线上流量：用mitmproxy抓取7天真实请求，提取prompt长度、响应时间、错误码分布
2. 合成负载：用locust脚本模拟：

   class LLMUser(HttpUser): @task def generate(self): # 按真实分布随机选prompt长度 length = np.random.choice([32,128,512,2048], p=[0.4,0.3,0.2,0.1]) prompt = "A"*length # 简化，实际用真实语料 self.client.post("/generate", json={"prompt":prompt})

3. 观测维度：不仅看QPS，更盯vLLM的gpu_cache_usage（应<85%）和num_requests_waiting（应<5）

6.3 关键参数调优：block-size的物理意义

--block-size是vLLM最易被误解的参数。它不是“越大越好”，而是显存块与计算效率的平衡点：

• block-size=16：每个KV cache块占16 tokens空间，适合小模型（如Qwen2-1.5B），显存碎片少，P95延迟低
• block-size=32：适合大模型（如Qwen2-7B），减少块数量，提升GPU利用率，但小请求可能浪费空间

实测Qwen2-1.5B：

最优解是16——它在延迟和吞吐间取得最佳折衷。这个结论必须通过实测得出，而非理论推导。

6.4 零基础部署：用vLLM在Colab免费启服务

1. Colab中运行：

   pip install vllm python -m vllm.entrypoints.api_server \ --model Qwen/Qwen2-1.5B-Instruct \ --tensor-parallel-size 1 \ --block-size 16 \ --max-num-seqs 256 \ --host 0.0.0.0 \ --port 8000

2. 在另一终端用curl测试：

   curl http://localhost:8000/generate \ -d '{"prompt":"你好","max_tokens":64}'

3. 监控：打开http://localhost:8000/metrics看Prometheus指标

重点验证：

• vllm:gpu_cache_usage_ratio是否在0.7~0.85区间
• vllm:num_requests_waiting是否长期为0
• 连续发送100次请求，time curl ...的stddev是否<50ms

这才是“部署过”的证据链。

7. 问题6：你做过RAG吗？Embedding模型怎么选？Chunk策略怎么定？

RAG（检索增强生成）是当前最实用的LLM落地模式，但90%的实现停留在“调用API”层面。面试官想确认你是否理解信息检索与语言生成的耦合机制——Embedding不是黑盒，chunk不是切片，而是精度与召回的精密博弈。

7.1 Embedding模型：bge-small-zh vs m3e-base的实战抉择

两者都是中文SOTA，但适用场景截然不同：

• bge-small-zh：专为检索优化，训练时使用hard negative mining。在金融合同检索任务中，top-3召回率89.2%，但生成答案时幻觉率12.7%（因过度聚焦关键词，忽略语境）。

• m3e-base：通用型，平衡语义与句法。同一任务top-3召回率82.1%，但幻觉率仅4.3%——因为其向量空间更平滑，生成时不易被噪声词带偏。

我的选型决策树：

graph TD A[任务类型] -->|高精度检索<br>如法律条文定位| B(bge-small-zh) A -->|生成质量优先<br>如客服问答| C(m3e-base) A -->|需多语言<br>如跨境合同| D(text2vec-large-chinese)

注意：所有Embedding模型必须在目标领域语料上微调。直接用HuggingFace原版，在专业领域效果下降30%+。微调只需200条高质量query-doc pair，用sentence-transformers的MultipleNegativesRankingLoss，1个epoch即可。

7.2 Chunk策略：不是“按字数切”，而是“按语义单元切”

常见错误是chunk_size=512, chunk_overlap=50。这在技术文档中灾难性：可能把“步骤1：登录系统”和“步骤2：输入密码”切成两个chunk，检索时只召回步骤1，生成答案缺失关键动作。

正确方法是语义感知分块：

• 技术文档：按## 标题分割，每个chunk是一个完整章节
• 对话记录：按[USER]/[ASSISTANT]边界切，保留对话轮次完整性
• PDF扫描件：用unstructured库先提取表格/段落/标题，再按逻辑块聚合

工具链：

from unstructured.partition.pdf import partition_pdf from langchain_text_splitters import MarkdownHeaderTextSplitter # 先提取结构化内容 elements = partition_pdf("manual.pdf", strategy="hi_res") # 再按标题层级切分 headers_to_split_on = [("#", "Header 1"), ("##", "Header 2")] splitter = MarkdownHeaderTextSplitter(headers_to_split_on=headers_to_split_on) docs = splitter.split_text("\n".join([str(e) for e in elements]))

7.3 RAG效果验证：必须做A/B测试

不能只看“检索是否相关”，要看最终生成答案的业务价值。我的验证框架：

1. 离线测试：构建100个真实用户问题，人工标注标准答案
2. A/B分组：
   • A组：RAG（bge-small-zh + 标题切分）
   • B组：纯LLM（Qwen2-1.5B）
3. 评估维度：
   • 准确性（vs标准答案）
   • 完整性（是否遗漏关键步骤）
   • 安全性（是否生成违规内容）

实测某政务问答项目：RAG在准确性上+22%，但安全性-8%（因检索到过时政策）。最终方案是RAG+规则引擎：对生成答案中的政策条款，强制调用法规数据库校验时效性。

7.4 零基础RAG：用LlamaIndex 10分钟搭原型

1. 安装：pip install llama-index-core llama-index-llms-huggingface llama-index-embeddings-huggingface
2. 加载文档：

   from llama_index.core import VectorStoreIndex, SimpleDirectoryReader from llama_index.embeddings.huggingface import HuggingFaceEmbedding # 使用m3e-base（更稳） embed_model = HuggingFaceEmbedding(model_name="moka-ai/m3e-base") documents = SimpleDirectoryReader("./docs").load_data() index = VectorStoreIndex.from_documents(documents, embed_model=embed_model)

3. 查询：

   query_engine = index.as_query_engine() response = query_engine.query("如何办理营业执照？") print(response.response)

关键验证点：

• response.source_nodes[0].score是否>0.6（相关性阈值）
• response.response是否包含文档中的具体条款编号（如“依据《XX条例》第5条”）
• 连续5次相同查询，score是否稳定（波动<0.05）

这比背“RAG原理”更能证明你“做过”。

8. 问题7：你处理过哪些LLM幻觉？怎么检测和缓解的？

幻觉（Hallucination）是LLM最顽固的缺陷。面试官问这个问题，是在考察你对模型局限性的敬畏心和工程化缓解能力。不是问“什么是幻觉”，而是问“你亲眼见过它怎么害人，又怎么把它关进笼子”。

8.1 幻觉的四种物理形态

必须区分类型，因为缓解策略完全不同：