第一次真正感受到“技术判断”这四个字，不是在写完代码的时候，而是在一次方案评审前。需求看起来并不复杂，业务要上线一个新能力，时间不算宽裕，但链路很长，涉及多个模块联动。导师把文档丢过来，只说了一句：先别急着写，先把可能出问题的地方找出来。 我最开始也和很多实习生一样，下意识会先看接口、看表结构、看怎么把功能做出来。但越往下梳理，越发现这不是一个“把需求实现”就结束的任务。高并发场景下，任何一个看起来正常的调用路径，都可能在流量起来之后变成瓶颈；任何一个默认重试、超时设置、依赖堆叠，都可能把局部问题放大成全链路抖动。 于是我先没动代码，反而花时间把调用链、异常路径和兜底逻辑一条条画清楚。哪些请求...

这个是流程终止了吗

29届java实习，简历包装了一下苍穹外卖和黑马点评，请问有什么项目推荐吗？有必要在简历上补个蓝桥杯，马蹄杯之类的算法竞赛吗？接下来还会继续学习🥹想在暑假去进行第一份实习 有机会吗？求大佬拷打😭😭

1. 做一下自我介绍2. RAG 分块策略应该怎么选，真正影响效果的核心因素是什么分块策略不是越细越好，也不是统一按 token 长度切就行。真正影响效果的是 chunk 是否保留了完整语义单元、是否带有足够的定位信息、是否能在召回后被模型直接利用。像制度文档、规则文档、FAQ、表格和多层级说明，最佳切法差异很大。比较稳的方式通常是结构优先、语义补充、长度兜底，也就是先尊重标题、段落、表格、列表，再在超长片段内部做语义切分。这样做的目标不是生成整齐块，而是让每个 chunk 自带最小可回答上下文。3. 怎么评估 RAG 的效果，除了准确率还能看什么RAG 效果不能只看最终回答对不对，因为那样很...