研0 -> 从java转向ai agent day01

1. 自我介绍2. 智能合同审阅平台里为什么要同时使用向量检索和全文检索？单一检索方式为什么不够？答案：在合同审阅场景里，用户的问题或者待审条款通常不是简单关键词匹配，而是存在大量语义相近但表达不同的内容，比如“提前解除合同”“单方终止协议”“无责解约”语义接近，但关键词并不完全一致。如果只用全文检索，比如 Elasticsearch 的 BM25，优点是关键词匹配精确、可解释性强，对合同编号、金额、日期、公司名称、条款标题这类结构化或半结构化字段效果很好。但它对同义表达、语义改写、隐含风险点的召回能力较弱。如果只用向量检索，优点是语义召回能力强，但是容易召回一些语义相似但法律含义不完全一致的...

各位牛客的大佬/前辈好！我是26届应届生，Java后端方向，目前在找全职机会。个人技术栈和底子比较扎实，干活绝对不虚，绝非只会写 CRUD 的小白，期望能有大佬帮忙内推（绝不浪费您的内推名额！）：💡 核心优势：深入理解 JVM 底层（类加载机制、双亲委派、调优思路）和 **JUC 高并发**（线程池底层原理及拒绝策略、手写DCL单例等）。深入理解 MySQL 索引底层（B+树、覆盖索引、最左前缀法则），能独立解决慢 SQL 与索引失效问题。 3. 熟悉 Redis 核心原理（持久化、Cluster分片哈希槽），并在项目中实际落地过基于 Redis 结合 MySQL 实现的强一致性幂等防重机制。项目经验真实硬核（智能货柜物联网电商），利用 MQ 和线程池改造过核心交易链路解决高并发假死，并从 0 到 1 落地过基于本地消息表的分布式补偿组件。

我和我的mentor相处模式绝对是“亦师亦友的硬核技术搭子”。刚切入新能源电池测试的大数据架构时，面对每天海量的并发数据流，我其实挺头疼的。但带我的齐工从来不搞职场PUA，而是直接拉着我一起看底层链路。我们最常做的不是单向分派任务，而是一起对着屏幕争论怎么优化Kafka和Flink CDC的同步逻辑，或者研究怎么把Doris的查询性能压榨到极致。每周的部门技术分享会上，他也会极力鼓励我上去讲讲分布式数据库的实战踩坑经验，帮我建立技术影响力。平时遇到难啃的骨头，比如梳理实验室测试流程管理模块（TRP）的复杂数据清洗规则，总是一针见血地点出瓶颈，然后鼓励我大胆用AI原生工具链去提效重构。这种不讲虚...

真是逆天，今天突然收到前司leader的微信，让我请假一天回去帮他修bug，写需求气不过，骂了回去，资本家们都这么不要face的吗？兄弟们，怎么看