灯下赶路集
Lv.1一边看远方，一边解决眼前的问题，关注技术学习与数字生活，记录学习路径整理、方法总结和真实实践中的思考；希望内容既讲清为什么，也说明怎么做。持续更新，尽量让每一篇内容都有实际价值。
发表的评论
我现在的做法是让Copilot专心干脏活累活，比如getter/setter、DTO转换、简单的CRUD，这些它确实快。但凡是碰到事务边界、异常传播、并发这些，我压根不等它补全完就直接开ChatGPT问，因为Copilot在这块经常给你整出个@Transactional乱标或者try-catch吞异常的骚操作。风格不统一的问题我也遇到过，后来干脆在项目根目录放了个.copilot-instruct
我一般按语义切，再用小模型过滤低质块，比死磕大小管用。
我之前也踩过这个坑，大概率是Agent对工具返回结果的解析太“死”了。LangChain默认那套output parser对字段名和结构挺敏感的，你工具返回的JSON里如果嵌套深一点或者key跟它预期的不一样，它就直接判定失败。可以试试在工具外面包一层适配器，把返回统一成简单字符串再喂回去，或者换个更宽松的parser。另外ReAct确实会稳一些，但prompt里最好把“什么算成功”写清楚，不然模
两张4090跑6B直接上vLLM吧，AWQ量化后单卡就够，吞吐比FastChat高好几倍，别折腾了。
研二遇到这情况太正常了，我当年也是TF1.x和PyTorch来回横跳。后来发现真正卡人的不是API，而是两套框架的思维方式——TF是静态图先搭后跑，PyTorch是动态图边跑边改，你把这个底层逻辑吃透，语法切换就是查文档的事。建议你选PyTorch当主力深耕，TF1.x只当维护老代码的工具，别追求两边都精通，精力有限。复现老论文时把TF当“翻译任务”做，跑通就行，别陷进去。
没开flash attention肯定慢啊，加上它速度能翻倍，再试试gradient checkpointing。
让Agent写循环我都先让它出伪代码，确认逻辑对了再生成代码，直接上代码确实容易翻车。
我之前也踩过这个坑，后来发现关键不是死磕token数，而是按文档结构切。技术手册里标题和代码块本身就是天然边界，用MarkdownHeaderTextSplitter或者按段落切效果比固定长度好很多。overlap我一般设chunk的10%-15%，太大容易重复召回，太小又丢上下文。另外可以试试在检索后加个rerank，能明显缓解大chunk带来的噪声问题。
几十万切片、1024维这个量级其实挺尴尬的，说大不大说小不小，Chroma跑demo确实舒服，但真到生产上并发一上来它的短板就藏不住了，尤其是持久化和横向扩展这块。Milvus Lite跟正式版差距还是明显的，Lite基本就是个单机玩具，索引类型和性能调优空间都受限，别指望拿它平滑过渡到集群版。ES加向量插件我倒觉得可以认真考虑，如果你本来就有ES运维经验，省一套组件的心智负担很值，只是召回和延迟
这个问题我踩过类似的坑，感觉你未必是切分的锅。300字加50重叠在人事政策这种文档里确实容易把一条完整规则拆散，比如年假条款可能前半段在讲适用范围、后半段才提到入职首年的折算方式，中间再插个考勤定义，embedding就会把整块语义拉偏。但更关键的可能是query和chunk的语义粒度不匹配，bge-m3对这种带条件限定的短问句本身就不太敏感，“入职第一年有没有年假”里的核心约束是“第一年”，可向
这个坑我们也踩过，Faiss 本身不太适合做带元数据管理的增量更新，它的索引结构对删除和局部替换支持很弱，你重建整个索引其实是被逼的。后来我们换成了 Qdrant，给每个 chunk 带上 doc_id 和 version 字段，更新时先按 doc_id 过滤删掉旧向量再插入新的，基本能做到分钟级同步，不用全量重建。不过要注意切分策略得稳定，否则同一篇文档两次切出来的 chunk 对不上，去重逻辑
几十万条单机自用，Chroma其实够，但它的where过滤确实偏弱，复杂组合条件容易踩坑。我后来换Qdrant就是冲着payload filter去的，按时间和标签筛很顺手，Docker一条命令起也不重。MCP那边建议走官方SDK，HTTP多一层封装延迟反而高，还容易在并发时出幺蛾子。跟LangChain接的话Qdrant有现成vectorstore，省不少事。
其实你理解得没错，prompt就是给模型的输入指令，但在不同框架里它承载的格式确实不一样。比如transformers里tokenizer的prompt，本质上是把文本转成模型能读的token序列，得按它要求的模板来，比如加个[CLS]或者[SEP]这种特殊标记，你直接扔一句大白话进去当然报错。diffusers那边更离谱，prompt是描述画面的文本，但内部会先编码成向量再参与生成，所以格式上更
直接上rerank吧，你这问题大概率不是切分的事，bge对长文本确实拉胯。 500带重叠还是太粗了，试试按语义段落切，或者先换bge-m3看看效果。
生产环境里LLM只做抽取不做判断，规则兜底才是常态，Prompt能搞定的是非结构化转结构化前的粗筛。
这题我熟，八成是Reducer没配好，共享字段得用add_node时的自定义合并逻辑，别指望默认覆盖。 我之前也踩过这坑，LangGraph调试用LangSmith看轨迹最直观，节点间传参能看得一清二楚。
你这数据量直接上微调embedding性价比真不高，先把父子分块和元数据过滤试了再说。
试试用async/await把所有工具包成Promise，再上个类似p-limit的并发控制，超时用Promise.race兜底，能省不少心。
数据混合比例可以试试9:1通用兜底，你这个纯领域语料占比太高了，通用能力肯定崩。 另外模板里把工具描述写得更具体点，带上触发条件试试，能少瞎调用。
这情况大概率是数据里中英混杂导致模型学乱了，建议先筛掉英文样本或加翻译对齐再试。