1、自我介绍2、项目深挖3、如果让你设计一个 Agent 的评测体系，你会怎么做Agent 的评测不能只看最终回答像不像，因为很多场景里最终答案看起来没问题，但中间过程其实已经错了。真正可用的评测体系应该至少覆盖三层。第一层是结果评测，也就是任务有没有完成，最终输出是不是符合目标。第二层是过程评测，要看任务拆解是否合理、工具是否选对、参数是否正确、执行顺序是否稳定。第三层是系统评测，要看延迟、成功率、重试率、单次成本、异常恢复能力这些工程指标。如果是线上系统，我会把评测拆成离线和在线两部分。离线阶段构造标准数据集，做固定样本回放，评估规划正确率、工具调用成功率、任务完成率和输出质量。在线阶段则...

1、自我介绍2、项目拷打3、介绍 DeepSeek 与 Manus，以及他们之间区别4、介绍 LLM Decoder-Only 架构Decoder-Only 架构本质上就是只使用 Transformer 里的 Decoder 结构，通过自回归的方式一个 token 一个 token 地往后生成内容。它的训练目标通常是 next token prediction，也就是根据前面的上下文预测下一个 token。它的关键点在于 Masked Self-Attention。所谓 masked，就是当前位置只能看到前面的 token，看不到后面的 token，这样模型才能按从左到右的方式学习生成。整体结...

1、先做一下自我介绍2、介绍一个你最熟悉的大模型项目3、你在项目里具体做了哪些优化4、如果让你做一个保险知识问答系统，你会怎么设计如果是保险场景，我会把重点放在“依据”和“边界”上。因为用户问的很多问题，比如能不能赔、赔多少、什么情况下免责、等待期怎么算，这些都不是开放式闲聊，不能让模型自由发挥。整体上我会先把知识源整理出来，常见的包括：保单条款FAQ理赔规则产品说明客服知识库内部业务手册然后对这些文档做清洗、切分、去重、打标签和建索引。检索层我会优先考虑混合检索，因为保险场景里很多词比较硬，比如免责、既往症、等待期、受益人、赔付比例这类，单靠语义检索不一定够稳。生成层会尽量限制模型，只让它基...

1、自我介绍2、对大模型应用的理解我理解的大模型应用，核心不是“模型能回答”，而是“模型能稳定解决业务问题”。单纯从能力上看，大模型擅长自然语言理解、内容生成、总结归纳、信息抽取、问答、多轮对话、代码辅助这些任务，但真正到了业务场景里，还要考虑知识时效性、幻觉控制、结果可解释性、调用成本和响应速度。所以大模型应用一般不是一个裸模型直接上线，而是一个完整系统。常见会包括下面这些模块：用户输入理解Prompt 构造外部知识检索工具调用模型生成输出校验日志监控和效果评测如果是企业场景，大模型应用通常有几个典型方向：智能问答和知识库助手企业内部 Copilot智能客服文档总结和信息抽取数据分析辅助Ag...

1、自我介绍2、讲一个你做过的最有代表性的 Agent 项目3、如果让你设计一个通用 Agent 框架，你会怎么设计我会把它拆成六层。最上面是接入层，处理用户请求、鉴权、限流和会话管理。下面一层是理解层，负责意图识别、槽位抽取、风险识别和任务分类。再往下是规划层，根据任务复杂度决定是直接回答、走工作流，还是做多步规划。中间一层是记忆和上下文层，统一管理短期记忆、长期记忆、任务状态和检索到的证据。再下面是工具层，把所有外部能力封装成标准化 skill，包括描述、参数 schema、执行逻辑和异常处理。最底层是执行与评测层，负责模型调用、工具执行、结果回填、日志埋点和效果评估。如果要做成工程上可维...

1、自我介绍我主要做的是大模型应用和 AI Agent 相关开发，平时接触比较多的是 Prompt 工程、RAG、工具调用、工作流编排、上下文管理、模型评测和服务化落地。技术栈以 Python 为主，也做过接口开发、异步并发、日志监控和效果优化这类工程工作。相比只关注模型本身，我更关注模型放到真实系统里之后，怎么把效果、稳定性、延迟和成本一起做好。2、提示词模板是怎么构建的提示词模板本质上是在给模型定义任务协议，而不是简单写一段说明。一般会包含角色设定、任务目标、输入数据、约束条件、输出格式和示例。比如让模型做工具调用时，提示词里通常会明确：你是什么角色你要解决什么问题什么情况下需要调用工具工...

1、自我介绍2、讲一下你做过的一个最有代表性的项目3、RAG 里 chunk 怎么切，为什么这是个关键点chunk 切分会直接影响召回质量和最终回答质量。因为向量检索不是按整篇文档检，而是按切分后的片段检。如果切得太长，一个 chunk 里会混入很多无关信息，虽然语义覆盖大，但相似度不一定集中，模型拿到后也不容易抓住重点。如果切得太短，单个 chunk 虽然很纯，但上下文不完整，容易导致召回回来的内容缺少关键信息。实际做的时候一般会根据文档类型来定。像制度文档、说明文档，可以按标题、段落、语义边界切；如果是 FAQ 或问答对，本身就天然适合按条切。通常还会设置 overlap，避免一个关键信息...

1、自我介绍2、通俗讲一下大模型从训练到落地到评测的全过程可以把大模型看成一个先大量学习、再针对任务训练、最后真正上岗工作的系统。第一步是预训练。这个阶段会给模型非常大量的文本，让它去做“根据前文预测下一个词”这样的任务。比如给它一句“今天天气很”，它要预测下一个字可能是“好”还是“热”。这个过程做得足够大以后，模型就会学到语言规律、常识知识、一些推理模式和表达能力。第二步是微调或者对齐。预训练出来的模型虽然懂很多东西，但不一定会按人的要求回答，所以还要进一步训练。比如给它大量“问题-答案”数据，让它学会更像助手一样回复，这就是 SFT。有些场景还会继续做人类偏好对齐，比如让模型学会什么回答更...

1、自我介绍2、项目拷打3、RAG 的完整链路是什么，哪些地方最容易出问题RAG 的完整链路一般是文档接入、清洗去噪、切 chunk、向量化、建索引、在线检索、重排、上下文构造、Prompt 拼接、模型生成和结果后处理。线上请求过来以后，先对用户 query 做归一化处理，再进行向量召回或者混合召回，把候选文档取回来，然后用 rerank 模型重新排序，选出最相关的内容拼到 prompt 里，再交给大模型回答。最容易出问题的地方通常有几个。第一是 chunk 切得不合理，太短会丢语义，太长会导致噪声太多。第二是召回率不够，模型根本没拿到正确证据。第三是重排不准，正确文档被排到后面。第四是上下文...

1、LoRA 微调的原理LoRA 的核心思想是不直接更新预训练模型里的原始大权重，而是在某些线性层旁边增加一个低秩更新分支，用低秩矩阵去近似权重增量。假设原始权重是 W∈Rd×k，全量微调时直接学习ΔW，LoRA 则把它写成：ΔW=BA其中A∈Rr×k，B∈Rd×r ,，(r) 是远小于 (d) 和 (k) 的秩。这样前向计算就变成：h=Wx+ΔWx=Wx+BAx实际里通常还会加缩放项：这样做的本质是认为很多下游任务对大模型权重的更新其实存在低秩结构，不需要真的去学习一个完整的大矩阵。LoRA 的优点是可训练参数少、显存占用低、训练快，而且原模型参数冻结，方便多任务切换和权重管理。2、LoRA...

1、自我介绍2、训练和推理的并行策略大模型训练和推理常见的并行策略主要有数据并行、张量并行、流水线并行和专家并行。数据并行是每张卡放一份完整模型，不同卡处理不同 batch，然后通过 All-Reduce 同步梯度。它实现简单，但模型太大时单卡放不下。张量并行是把同一层的权重按列或者按行切到多张卡上，每张卡只算一部分，再做通信聚合，适合单层参数特别大的场景。流水线并行是把不同层分配到不同 GPU 上，让不同 micro-batch 像流水线一样流动，能解决单卡放不下完整模型的问题，但会有流水线气泡。专家并行主要出现在 MoE 结构里，不同 token 路由到不同专家，参数量可以很大，但每次只激...

1 . RAG 怎么评测，有哪些维度，那些指标RAG 的评测一般分成检索、生成、端到端三层。检索层主要看正确证据有没有被找回来，常用 Recall@K、HitRate@K、MRR、NDCG；生成层主要看答案对不对、是不是基于证据回答，常看 Answer Correctness、Faithfulness、Relevance、Completeness、Citation Accuracy；端到端层更偏业务效果，比如用户满意度、追问率、拒答率、时延和成本。真正做项目时不会只看最终答案，因为答案错可能是召回错、重排错、上下文拼接错，也可能是模型生成错。2. 数据集包括什么RAG 的数据集一般不只是知识库...

1、为什么引入父子索引，为什么引入 BM25，比例是怎样的，具体流程是什么，有没有 rerank父子索引主要是为了解决 切块后召回准，但是上下文不完整 的问题。如果文档直接按 300～500 token 切成小块做向量检索，确实更容易召回到具体答案，但很容易丢掉原文结构，比如标题、段落关系、表格上下文、前后约束条件。所以会把文档拆成两层：父块：保留完整语义单元，通常是 800～1500 token子块：用于召回，通常是 200～400 token检索时先搜子块，命中后回源到对应父块，再把父块内容喂给大模型。这样既保证召回精度，也保证上下文完整性。引入 BM25 是因为向量检索对语义相似比较敏感...

1、实时生成的聊天代理模型，如果线上出问题了，怎么定位这种问题一般先按链路拆。如果是实时生成类聊天代理，通常一条请求会经过网关、会话层、Prompt 拼装、模型推理、工具调用、结果后处理和流式返回几个阶段。线上出问题时，先判断是全量故障还是部分故障，是所有请求都失败，还是只有某一类请求延迟高、返回空、内容异常。定位时先看监控和日志。监控上看 QPS、平均延迟、P95/P99、错误率、超时率、GPU 利用率、显存占用、容器重启次数。日志上重点看 request_id，把一次请求链路串起来，看是卡在 Prompt 构造、模型推理、下游工具调用，还是 SSE/流式返回阶段。如果是模型输出异常，要回看...