快手大模型算法三面

1.问实习

2. 项目拷打

3. LLM 落地部署有什么好用的 trick？

答案：现在 LLM 落地里，很多时候改模型不如先改数据和链路。第一步是把线上 badcase 分桶，区分是检索错、提示词错、模型能力不足、工具返回错还是数据源脏；第二步是做数据闭环，把高频错误变成 SFT、偏好对、规则样本或者评测集；第三步是做推理侧优化，比如 KV Cache、continuous batching、量化、prefix cache 和路由小模型。

比较实用的 trick 是不要盲目微调整个模型。很多业务问题是知识更新、格式不稳、证据引用错，这些更适合通过 RAG、结构化输出、后校验和数据清洗解决。只有当错误来自模型本身能力缺口，比如复杂分类边界、领域表达习惯、拒答策略，才考虑微调。

def route_fix_type(badcase):
    if badcase["retrieval_hit"] is False:
        return "优化召回/重排/元数据过滤"
    if badcase["evidence_conflict"] is True:
        return "清洗知识源并做证据优先级"
    if badcase["format_error"] is True:
        return "结构化输出+解析器+重试"
    if badcase["domain_pattern_miss"] is True:
        return "构造SFT或偏好数据"
    return "进入人工复核样本池"

4. 电商 NLP 场景中，为什么洗数据往往比改模型更重要？

答案：电商 NLP 的数据噪声非常重，商品标题、卖点、评论、客服对话、售后记录里都有大量模板话术、错别字、营销词、无效短句、重复样本和标签漂移。如果直接拿这些数据训练，模型会学到平台历史噪声，而不是学到真实业务规律。特别是风控、质检、审核类任务，标签本身会随平台规则变化，旧标签不一定永远正确。

洗数据的核心不是简单去重，而是保证样本的输入、标签、证据和时间版本一致。比如同一条客服话术在旧规则下合规，在新规则下违规，如果不带规则版本训练，模型就会学乱。实际落地里，先把数据质量提高，通常比盲目换大模型收益更稳定。

def clean_ecommerce_sample(sample):
    if len(sample["text"].strip()) < 5:
        return None
    if sample.get("label") not in {"pass", "risk", "reject"}:
        return None
    if sample.get("rule_version") is None:
        return None
    if sample.get("evidence") and sample["evidence"] not in sample["rule_text"]:
        sample["need_review"] = True
    return sample

5. 如果 HC 已经释放，组里更看重落地应用，你怎么体现自己的价值？

答案：答案要围绕“能不能快速把业务问题拆成模型问题和工程问题”。业务组一般不缺单纯会跑模型的人，更需要能定位问题、做数据闭环、控制成本并推动上线的人。比如一个问答系统效果不好，要能拆出来是知识库脏、召回不准、prompt 约束弱、模型不会拒答，还是线上指标设计不对。

落地型岗位最重要的是端到端思维：从数据采集、清洗、标注、训练、评测、部署到监控都能接住。research 能力当然加分，但在业务组里，能把论文方法变成稳定收益更关键。面试时可以重点讲业务指标、线上延迟、badcase 闭环、GPU 成本下降，而不是只讲模型结构。

6. 为什么说大模型部署时 GPU 资源比模型参数更难管理？

答案：参数量只是静态显存的一部分，真正难管理的是动态显存和请求调度。线上请求的 prompt 长度、生成长度、batch 组成、KV Cache 增长速度都不稳定，同一个模型在不同流量形态下显存峰值差异很大。很多 OOM 不是参数放不下，而是长短请求混跑、KV Cache 堆积、prefill 峰值太高或 batch 调度不合理。

GPU 资源管理要同时看吞吐、延迟、显存碎片和 SLA。业务高峰期不能只追求 batch 大，因为 batch 大会让长请求拖慢短请求；也不能只追求低延迟，因为 GPU 利用率会很差。实际部署通常会做请求分桶、prefill/decode 分离、KV Cache 复用、量化和限流。

def estimate_kv_cache_gb(batch, seq_len, layers, kv_heads, head_dim, dtype_bytes=2):
    # K + V
    bytes_num = batch * seq_len * layers * kv_heads * head_dim * 2 * dtype_bytes
    return bytes_num / 1024**3

7. 如何判断一个 LLM 业务问题该用 RAG、微调还是规则系统解决？

答案：如果问题来自知识更新频繁、答案必须引用依据、业务规则变化快，优先用 RAG 或规则系统；如果问题来自模型不会领域表达、不会特定格式、不会稳定分类，才考虑微调；如果问题是强确定性约束，比如金额、权限、审核红线、合规判断，规则系统应该放在模型外部。

这三者不是互斥关系。一个稳定系统通常是规则兜底、RAG 提供证据、LLM 做理解和生成、微调提升领域行为。最怕的是把所有问题都交给微调，最后模型背了一堆会过期的知识；或者把所有问题都交给 RAG，结果检索质量差导致模型被噪声带偏。

def choose_solution(issue):
    if issue["requires_latest_knowledge"] or issue["needs_citation"]:
        return "RAG"
    if issue["hard_constraint"] or issue["compliance_boundary"]:
        return "Rule/System Guardrail"
    if issue["domain_style_gap"] or issue["format_instability"]:
        return "SFT/DPO"
    return "Prompt + Eval"