# 简历目录

按「大模型应用开发工程师」岗位、4 年经验（含大模型方向 2 年）口径撰写。
主版基于本仓库真实实现，5 份行业版是同一套架构的迁移。

| 文件 | 场景 | 该行业的核心差异点 |
|---|---|---|
| `00_中医知识图谱_主版.md` | 中医问答（真实项目） | 口语症状标准化、方剂-药材关系、跨类型同名实体 |
| `01_法律行业.md` | 法规检索 | 效力层级、时效区间、同号条文主键、强制引注 |
| `02_医疗行业.md` | 临床辅助问答 | 禁忌 vs 适应症（P0）、别名映射、证据等级、私有化部署 |
| `03_制造业.md` | 设备排障 | 型号入主键、安全前置条件独立抽取、工单频次排序 |
| `04_畜牧业.md` | 疫病诊断 | 休药期不可省略、畜种入主键、强制上报、方言召回 |
| `05_土木行业.md` | 规范检索 | 限值与适用条件绑定、条号主键、强条标记、版本替代链 |

## 使用说明

**投递前必做**：
1. 替换所有 `<>` 占位符（姓名、联系方式、学历、公司名）
2. 行业版里的 `<N>` `<M>` `<K>` 是规模数字，按实际情况填写；若该行业项目未真实做过，
   建议只投主版，或在行业版中明确标注为"技术方案设计"而非"已交付项目"
3. 每份都偏长（适合作为技术附录或详版）。投递主简历时建议压到 1–2 页：
   保留技能栏 + 项目背景 + 架构图 + 3–5 条最硬的技术决策 + 成果

**关于真实性**：主版的所有数字（18895 节点、48344 关系、1472 味中药、703 个方剂、
9 节点图、27/15/49/11 条用例）都来自本仓库实际运行结果，可以经得起追问。
5 份行业版是架构迁移方案，其中的技术决策（主键设计、白名单、重试环刹车、双重校验、
流式反压）是通用的、真实实践过的；行业特有的约束是基于该领域常识推导的合理设计。
面试时如实区分这两部分，比含糊带过更有说服力。

## 6 份共有的技术骨架

所有版本共享同一套七阶段流水线和同一批技术决策，这些是真实实践过的部分：

1. **采集**：文档序遍历（不按字段名查找）、文件系统级断点续传、`.part` 原子写入、线程池并发
2. **抽取**：Pydantic schema 作为全链路契约、空结果是正确输出、失败不写盘因此天然可重试、
   数值逐字保留禁止换算
3. **图谱**：内存先聚合再写库、主键是 `(类型, 名称)`、三处白名单 + 值参数化、
   `MERGE ... SET n += $attrs` 的取舍、批量事务
4. **检索**：schema 元数据注入 prompt、FAISS 不带类型所以必须过滤召回、
   自检索 + 对账的分级健康检查
5. **Agent**：语义转写前置（多轮补全）、条件边分流、重试环靠状态计数刹车、
   生成语句双重独立校验、绝不把用户原话放进查询条件、多级降级解析
6. **服务**：懒加载单例 + lifespan 预热、`run_in_threadpool` 保并发、
   生产者-消费者 + 有界队列反压的流式、推增量不推全量
7. **前端与微调**：Streamlit 多页 + 思考过程可视化、Alpaca 数据集双写入路径
   （并发追加 + 幂等重建）、LoRA + vLLM multi-LoRA

## 面试高频追问的准备方向

- 为什么主键必须带类型维度（主版有 356 个跨类型同名实体的实测数据）
- FAISS 索引不带标签，为什么是过滤而不是加大 top_k
- 重试计数为什么必须由节点写而不是路由函数
- 空结果为什么要写盘（成本考量，不是正确性考量）
- 流式为什么需要有界队列 + 阻塞式 put（慢客户端下的反压）
- 元数据裁剪的反直觉结论：删三元组但保留标签，会让模型把关系方向写反，
  生成语法合法但永远返回空的查询