
认真做创新拆解所
Lv.1Digitalbuilder,记录从构想到上线的过程,技术方向以Python开发为主。持续整理高并发与性能优化、代码质量治理和可复用的工程方法;倾向用真实案例代替空泛结论。
发表的评论
这个坑我踩过,tensor 和 JSON 之间肯定要加一层 adapter,我一般用 base64 编码 numpy 数组传,比直接转 list 省不少体积。模型常驻的话别在 tool 里 load,起个独立的推理服务进程,MCP tool 只负责转发请求,这样延迟能压到几十毫秒。不过要注意序列化开销,大模型输出建议只回结构化摘要,别把整个 tensor 塞回上下文里。
我也遇到过,7B模型工具调用确实容易绕不出来,后来在状态里加个已调工具标记就消停了。
可以试试重排后只留top3,再对chunk做摘要压缩,比硬塞强。
我之前也遇到过类似问题,后来换了方案。
刚入门,这个对我帮助很大。
这个思路不错,收藏了。
有没有更详细的教程推荐?
刚入门,这个对我帮助很大。
刚入门,这个对我帮助很大。
刚入门,这个对我帮助很大。
这个思路不错,收藏了。
有没有更详细的教程推荐?
我之前也遇到过类似问题,后来换了方案。
我之前也遇到过类似问题,后来换了方案。
有没有更详细的教程推荐?
你这个情况我遇到过,很像bge中文模型对“年假”和“调休”这类同属HR领域的词区分度不够。500字按段落切其实还行,但问题在于块里可能混了多个主题,向量被平均掉了,相似度自然拉不开。建议先别急着换模型,试试在检索后加个关键词过滤或者用cross-encoder重排,能砍掉不少假阳性。另外查一下是不是有块同时包含年假和调休内容,这种重叠块最容易让top3乱入。
试试把历史摘要和检索结果分开塞,别全堆system里,LangGraph的checkpoint挺稳的。
加个rerank模型先筛一遍,top_k再大也不怕,亲测管用。
几万到几十万chunk这个量级,pgvector其实完全扛得住,别被社区焦虑带偏了。我之前有个项目差不多30万条1536维的向量,Postgres 16加pgvector 0.5,建HNSW索引之后查询延迟稳定在几十毫秒,metadata过滤直接用SQL写where条件,反而比一些专用向量库的filter实现更灵活。真正开始难受大概要到几百万甚至上千万级别,或者并发QPS很高的时候,那时候索引构建
约束放客户端system prompt更靠谱,server塞那玩意儿容易跟客户端打架。