宏任务和微任务

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

鼠鼠好唐鼠鼠好唐鼠鼠好唐鼠鼠好唐鼠鼠好唐鼠鼠好唐鼠鼠好唐鼠鼠好唐鼠鼠好唐鼠鼠好唐

debuff叠满了，打招呼后已经没有后续了，连简历石沉大海的经历都没有（投都投不出去）！两段实习一点含金量都没有，求大佬们给我爆改一下，谢谢喵！

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