LLM工程师能力体检表：8个真实工程问题

1. 这不是“八股文”是LLM工程师能力的体检表最近帮三家公司做过技术面试官也带过十几位刚转AI方向的新人发现一个特别扎心的现象很多人简历上写着“熟悉LLM应用开发”“掌握LangChain/RAG流程”但一问到“为什么RAG里要加rerank”“LoRA微调时rank8和rank32在显存占用和效果上的实际差异是多少”当场卡壳。不是记不住答案而是根本没在真实项目里踩过坑、调过参、看过loss曲线跳变——这恰恰是标题里“答不上来直接淘汰”的底层逻辑企业要的不是背题机器而是能立刻接手模型部署、调试、监控、迭代的工程型人才。“LLM面试必问的8个问题”这个标题表面看是求职技巧实则是当前大模型落地阶段对工程师能力边界的精准测绘。它不考论文复述不考公式推导考的是你是否真正把LLM当作一个需要被工程化管理的复杂系统来对待。比如第3题“如何判断一个RAG系统的召回结果质量是否达标”背后藏着数据清洗策略、向量库选型依据、chunk size与query长度的匹配关系、甚至业务侧对“相关性”的定义标准第5题“微调时发现loss震荡剧烈你会优先排查哪三个环节”直接暴露你有没有亲手跑过训练job、有没有读过GPU显存分配日志、有没有在tensorboard里盯过梯度norm曲线。我见过太多人花三个月啃《Attention Is All You Need》却连Hugging Face的Trainer类里data_collator参数怎么用都说不清也见过有人把Llama-3-8B在A100上跑通就以为掌握了LLM结果上线后QPS掉一半才发现没配flash_attn、没开kv_cache优化。这8个问题就是从这些真实故障现场里捞出来的“最小能力验证集”。它们覆盖了LLM工程师日常工作的四个核心断面模型理解What、推理部署How、数据工程Where、系统运维Why。接下来我会逐题拆解不给标准答案只讲我在金融风控、电商客服、医疗知识库三个真实项目里是怎么做的、为什么这么做、踩过什么坑。2. 问题拆解与能力映射每个问题背后都是一条完整工作流2.1 问题1“为什么ChatGLM3-6B比Qwen2-7B在相同硬件上推理延迟低15%请从计算图和内存访问角度解释”这个问题本质是考察你对模型架构与硬件特性的耦合关系的理解深度。很多候选人会答“因为ChatGLM用了GLU激活函数”“Qwen用了RoPE位置编码”这没错但远远不够。真正决定延迟的是计算图中kernel launch次数和显存带宽利用率。以我们电商客服项目为例Qwen2-7B在T4上推理单token平均耗时128ms而ChatGLM3-6B只要109ms。我们用Nsight Compute抓取kernel profile发现关键差异Qwen2的RoPE实现需要在每次attention前做两次额外的torch.bmm矩阵乘引入3个独立kernel launchChatGLM3的GLU门控结构将FFN层的计算合并为单次torch.einsum减少27%的kernel调度开销更重要的是ChatGLM3的KV cache采用paged attention设计显存访问呈连续块状而Qwen2默认用naive attentioncache命中率仅63%大量时间耗在显存随机读取上。提示面试官真正想听的不是“哪个模型更快”而是你能否把抽象架构特性映射到具体硬件指标。建议准备一个对比表格包含kernel launch count、显存带宽占用率GB/s、L2 cache miss rate三项实测数据——哪怕是你用torch.compile跑出来的模拟数据也比纯理论描述有力得多。实操心得别只盯着模型paper一定要动手跑torch.profiler。我们团队有个硬性规定新模型接入前必须完成三件事① 用torch.compile(fullgraphTrue)编译并记录compile time② 在batch_size1/4/8下测端到端latency③ 抓取Nsight profile截图标注top3耗时kernel。这三份报告就是你回答这个问题的底气。2.2 问题2“RAG系统中用户问‘上个月退货率最高的SKU是什么’但向量库只存了商品描述文本没有结构化销售数据。你会怎么设计混合检索策略”这是典型的语义检索与结构化查询的协同问题。很多候选人会说“加个SQL模块”“用HyDE生成查询语句”但忽略了最关键的工程约束延迟预算和数据一致性。在金融风控项目里我们处理类似问题“近30天逾期率超5%的客户群特征”时最终方案是三级混合检索第一层语义过滤用sentence-transformers模型将问题编码为向量在商品描述库中召回Top50候选SKU耗时80ms第二层规则精筛对召回的SKU实时调用预聚合的Redis Hashkey为SKU_idfield包含return_rate_30d等指标筛选出return_rate_30d threshold的SKU耗时15ms第三层动态补全对筛选出的SKU再用LLM生成自然语言摘要如“SKU#A789退货率12.3%主因物流破损”避免直接返回冷冰冰的数字。这个设计绕开了两个致命陷阱不把原始销售表直接扔进向量库会导致embedding维度爆炸且更新延迟高不让LLM直接生成SQL金融场景严禁未审核的SQL执行。注意面试官会追问“Redis Hash怎么保证实时性”。正确答案不是“用CDC同步”而是“在ETL pipeline末尾加一层Flink实时计算每分钟更新一次Hash容忍1分钟数据延迟——因为业务方明确表示退货率分析允许T1”。常见误区试图用单一模型解决所有问题。我们曾试过用Graph RAG把销售数据建模成图谱结果推理延迟飙升到2.3秒远超客服系统300ms的SLA。后来砍掉图谱改用上述三层架构P99延迟压到210ms。2.3 问题3“微调Llama-3-8B时LoRA rank设为8和32显存占用差多少效果提升是否线性”这是检验你资源权衡决策能力的试金石。很多人背过“rank越大效果越好”但没算过真实代价。我们实测过A100-80G上Llama-3-8B的LoRA微调rank显存占用(GB)训练吞吐(token/s)验证集准确率442.118.772.3%848.916.275.1%1659.312.476.8%3278.68.177.2%关键发现rank从4→8显存增加6.8GB但准确率提升2.8个百分点性价比极高rank从16→32显存暴涨19.3GB准确率仅增0.4%且训练速度下降35%更隐蔽的问题是rank32时adapter权重矩阵尺寸达(8192×256)导致GPU tensor core利用率不足60%大量计算单元闲置。实操心得永远用增量实验法。我们团队的标准流程是先用rank4跑1个epoch确认loss能下降再升到rank8跑3个epoch观察验证集指标拐点最后只在rank8基础上微调learning rate。这样既避免盲目堆rank又防止过早放弃潜力。避坑提醒别信“rank64效果最好”的玄学说法。我们在医疗项目里试过rank64发现adapter层梯度norm异常波动查日志发现是FP16精度下矩阵乘法溢出——这问题只有真跑起来才会暴露。2.4 问题4“如何验证一个RAG系统的输出是否‘幻觉’请给出可落地的自动化检测方案”“幻觉检测”是当前LLM落地最头疼的工程问题。面试官想听的不是“用BERTScore比对”而是你如何在生产环境里低成本、高覆盖率、低误报率地拦截错误。我们电商知识库的方案分三层规则层快准狠对输出中的数值、日期、SKU编码等实体用正则业务字典强校验。例如检测到“退货率120%”立即触发告警——这步拦截了63%的明显幻觉向量层兜底将LLM输出分句用same embedding model编码计算每句与向量库中最相似chunk的cosine similarity低于0.65的句子标为“高风险”逻辑层防漏网用小型分类器3层MLP判断输出是否符合业务逻辑链。比如用户问“怎么退换货”输出中若同时出现“无需寄回”和“需支付运费”模型判定为矛盾幻觉准确率92.7%。这套方案上线后人工抽检幻觉率从18.4%降至2.1%且平均检测耗时仅47ms。关键在于不追求100%拦截而是把高危幻觉控制在可接受阈值内——毕竟业务方更在意“不能错”而不是“必须全对”。注意面试官常追问“为什么不用LLM-as-a-judge”。答案很实在LLM判别LLM的输出相当于让学生批改自己的试卷。我们试过用GPT-4做裁判发现它对自家幻觉的识别率仅71%还经常把合规回答判为幻觉误报率34%。经验教训幻觉检测必须和业务强绑定。曾有个项目用通用NLI模型检测逻辑矛盾结果把“该商品已停产建议选购替代款”判为幻觉因NLI认为“停产”和“建议选购”矛盾后来改成用业务规则引擎才解决。2.5 问题5“微调时loss突然飙升你会按什么顺序排查请列出前5个检查项及对应命令”这是考察你故障诊断肌肉记忆的题目。真正的高手不是知道原理而是能在3分钟内定位问题。我们总结的黄金排查顺序附实操命令检查梯度爆炸nvidia-smi --query-compute-appspid,used_memory --formatcsv看显存是否突增 →python -c import torch; print(torch.cuda.memory_summary())查显存分布 → 若allocated memory远大于reserved memory大概率梯度爆炸验证数据管道python -c from datasets import load_dataset; ds load_dataset(your_data); print(ds[train][0])确认样本格式无异常尤其注意text字段是否为空或含非法字符核对学习率grep -r lr ./training_script.py找实际lr值 → 用python -c print(1e-4 * 2**20)心算是否超出FP16范围65504会溢出检查tokenizerpython -c from transformers import AutoTokenizer; tk AutoTokenizer.from_pretrained(model_id); print(tk.encode(test))确认特殊token id是否正常曾因|eot_id|被误设为-1导致loss炸验证loss函数python -c import torch; y torch.randn(2,10); t torch.randint(0,10,(2,)); print(torch.nn.functional.cross_entropy(y,t))手动跑loss排除label mismatch。实操心得把这5条命令写成shell脚本存在/usr/local/bin/llm-debug新同事入职第一天就要学会用。我们团队有条铁律任何loss异常必须按此顺序执行跳过任一步都算违规。血泪教训有次loss飙升同事直接重跑训练结果浪费12小时。后来按顺序查发现是数据管道里某批样本的input_ids长度超过max_length被截断后label移位——这种问题只看log根本发现不了。2.6 问题6“如何让LLM在不微调的前提下稳定输出JSON格式请给出三种方案并比较适用场景”JSON稳定性是API集成的生命线。很多候选人只会说“加system prompt”但生产环境里这招失效率高达40%。我们验证过的三种方案方案1Schema约束Logit Bias推荐用vLLM的guided_decoding功能传入JSON Schema自动在logit层屏蔽非法token。优势零延迟、100%格式保证劣势仅支持vLLM等少数引擎。在金融API中强制使用P99延迟仅增3ms。方案2后处理修复保底输出后用jsonrepair库自动修正非json.loads对{name: Alice, age: 25}这类常见错误修复率达99.2%。优势兼容所有模型劣势需额外RTT且无法修复逻辑错误。方案3两阶段生成平衡第一阶段生成自然语言描述第二阶段用轻量模型如Phi-3-mini做JSON转换。优势格式语义双保险劣势延迟翻倍。在医疗问诊中采用因需确保字段语义准确。关键细节别忽略Unicode问题。我们曾因JSON里的中文引号“”被当成非法字符后来在schema里显式声明additionalProperties: true并预处理输入文本。避坑指南永远用真实业务数据测试。曾用新闻摘要数据验证JSON方案上线后发现电商订单数据里大量null值导致schema校验失败——最后在schema里加了nullable: true才解决。2.7 问题7“如何评估一个LLM应用的‘业务价值’请给出三个可量化的指标及采集方法”这是区分“技术玩家”和“业务工程师”的分水岭。很多人答“准确率”“响应时间”但业务方只关心“省了多少钱”“赚了多少单”。我们在三个项目中定义的核心指标人力替代率客服场景下用LLM处理的工单数 / 总工单数。采集方法在工单系统打标LLM处理/人工处理要求准确率95%才计入转化 uplift电商场景中启用LLM推荐后关联商品点击率提升百分比。采集方法AB测试对照组用传统推荐实验组加LLM生成话术用埋点统计点击事件错误成本节约金融场景中LLM拦截的高风险操作次数 × 单次人工复核成本。采集方法记录LLM标记为“需人工复核”的操作追踪后续是否真发现问题。注意必须定义“有效处理”。我们曾把LLM回复率当指标结果发现它把80%的简单咨询都转人工——后来改成“首次解决率”用户未转人工即关闭会话。经验之谈指标要和业务KPI对齐。给CEO汇报时我们从不说“模型F10.82”而是说“每月减少237小时人工审核折合人力成本18.6万”。2.8 问题8“如果让你给非技术高管解释‘为什么不能直接用GPT-4做内部知识库’你会怎么说”这是终极考验能否把技术风险翻译成商业语言。答案不能出现“幻觉”“token限制”等术语。我们的标准话术“就像您不会让新入职的销售直接背完公司十年合同库再去见客户GPT-4也没法安全地处理您的核心数据。它有三个确定性风险第一数据不可控——每次提问都可能把客户信息、产品参数发到境外服务器这违反咱们的数据安全条例第二响应不可靠——它可能把去年降价的商品说成今年涨价导致客诉第三成本不可测——高峰期调用量暴增单月账单可能翻三倍而咱们的IT预算早就锁死了。”然后递上一页纸的替代方案用本地部署的Qwen2-7BRAG初期投入24万含GPU服务器实施费三年TCO比GPT-4 API低67%且所有数据留在内网。实操心得永远用高管熟悉的参照物。说“API调用成本”不如说“相当于多雇3个全职员工”说“延迟”不如说“比客服响应慢2秒会导致12%客户流失”。血泪教训有次技术负责人坚持用GPT-4结果上线两周后审计发现37份客户合同片段出现在OpenAI日志里——最后整个项目叫停损失预算120万。3. 超越8题构建你的LLM工程能力护城河这8个问题只是起点真正的竞争力在于把它们串成体系。我在带新人时会让他们用两周时间完成一个“能力验证闭环”3.1 构建个人LLM沙箱环境不依赖云服务用一台30908000搭最小可行环境安装Ubuntu 22.04 Docker NVIDIA Container Toolkit部署vLLM支持FlashAttention-2 LangChain ChromaDB下载Qwen2-1.5B量化后仅1.2GB跑通RAG全流程用llm-benchmark工具测baselineQPS、首token延迟、显存占用。关键动作在/etc/docker/daemon.json里配置default-runtime: nvidia否则容器看不到GPU——这个坑90%新手会踩。3.2 完成一次真实数据攻坚找一份公开数据集如Amazon Reviews做端到端处理用pandas清洗剔除50字符的无效评论用langchain.text_splitter切分测试chunk_size128/256/512的效果用all-MiniLM-L6-v2生成embedding对比FAISS vs Chroma的召回率微调Qwen2-1.5B做情感分类记录LoRA rank对F1的影响。心得别跳过数据清洗。我们发现Amazon数据里23%的评论含HTML标签直接导致embedding质量下降——这问题只有亲手跑才会发现。3.3 设计一次故障复盘演练假设线上RAG系统P99延迟从200ms飙升至1.2秒模拟步骤在ChromaDB里插入10万条假数据关闭索引优化排查路径用htop看CPU负载 →nvidia-smi看GPU利用率 →curl http://localhost:8000/metrics查Prometheus指标根本原因ChromaDB的HNSW索引未重建导致搜索退化为线性扫描。工具链必须装py-spyPython性能分析nvtopGPU实时监控prometheus-client指标暴露。这些不是加分项是生存必需品。4. 面试之外那些没人告诉你的LLM工程真相4.1 “微调”正在被重新定义行业共识正在转向微调不是目的而是手段。我们90%的新项目已不再做全参数微调而是用QLoRA在消费级显卡上微调用DPO直接对齐人类偏好用RAGPrompt Engineering解决80%需求。真正值钱的不是调参能力而是判断何时该微调、何时该换数据、何时该改架构的决策力。4.2 文档比代码更重要在金融项目里我要求所有LLM组件必须配三份文档数据契约明确定义输入字段类型、取值范围、更新频率SLA承诺书写清P95延迟、错误率、降级方案熔断手册列明触发条件如连续5次幻觉、执行动作切回规则引擎、通知对象。没有这三份文档代码再漂亮也不许上线。4.3 最危险的不是技术债是认知债见过太多团队沉迷于“换更大模型”却忽视基础建设没有统一的prompt版本管理导致A/B测试失效没有标准化的评估数据集每次效果对比都是玄学没有日志规范debug时找不到关键上下文。这些看似琐碎的事才是决定项目生死的关键。最后分享个小技巧每次面试前把这8个问题的答案用故障树形式画出来。比如问题5的loss飙升画成“梯度爆炸→数据异常→学习率错误→tokenizer故障→loss函数bug”五层树每层标注你的排查命令和预期输出。这样面试时不是背答案而是展示你的思维框架——而这正是淘汰线划在哪儿的根本原因。