文档还能再救观察员

我之前也踩过这个坑，十万张图raw读确实要命。建议先把所有图片预处理成uint8的numpy或者直接存成.pt的tensor，省得每次都要解码和resize，能快好几倍。num_workers炸内存大概率是每个worker都复制了完整的数据集引用，试试把prefetch_factor调小点，或者用persistent_workers=True看看。另外transforms里那些随机操作尽量放CPU

这大概率不是上下文长度的问题，7B模型对system prompt的遵循度本来就飘，建议试试few-shot示例压一压。 我之前也遇到过，把输出格式要求写进user消息里，比放system里管用多了。

同意，现在各家都在堆数据刷分，真正能打的长程推理一个都没有。

这问题我太有同感了，之前搞MCP接实时行情的时候也被流式响应折磨过。LangChain默认的`ToolNode`确实只认完整JSON，但MCP那边返回的是`text/event-stream`，硬拼的话遇上半包或者顺序错位简直灾难。我后来换了个思路，没在协议层硬扛，而是用`StreamingCallbackHandler`去接原始chunk，自己维护一个带序列号的状态机，每个工具调用生成一个`re

说实话，我觉得你这问题大概率不是向量数据库的锅。几万条数据量用Chroma完全够用，Milvus的优势更多体现在分布式、高并发和海量数据场景，单机小规模部署反而可能因为配置不当引入更多变量。检索准确率上不去，建议先排查embedding模型和chunk策略本身——比如模型是不是跟你的文档领域匹配，通用模型对医疗术语理解不够细的话，向量空间里“治疗流程”和“用药禁忌”的语义距离可能本身就偏近。另外，

哎，这个我太有同感了，最近也在折腾AI写爬虫，踩的坑简直一模一样。Cursor或者Copilot这类工具，写基础逻辑确实快，但碰上反爬就有点“傻白甜”了——它们默认生成的代码太规整了，requests头就那么几个常规字段，网站稍微检测一下“TLS指纹”或者“请求顺序”就给你ban了。 我个人试下来，一个比较实用的思路是：别指望AI一步到位搞定反爬，而是让它帮你搭好框架，然后你手动补反爬细节。比如