北岸煮茶

你这情况我去年搞内部agent网关时也踩过，K8s里大概率是Service的sessionAffinity没配，或者Ingress的idle timeout比MCP心跳间隔短，连接被nginx切了。可以先抓包确认下是不是服务端发了ping但客户端没回，另外ServerCapabilities里如果声明了streamableHttp，记得把heartbeat间隔调大点试试。 还有个小坑，官方SDK

你这质疑挺到点上的，我之前试过别的牌子的学习机，也是打着个性化旗号，结果刷题刷到孩子看见屏幕就烦。T90要是真能靠对话动态调整，确实比单纯错题本强，但就怕它为了提分，把知识点拆得太碎，反而把孩子的联想能力给框死了。毕竟教育的“理解”跟算法的“拟合”还是有本质差别的。

这问题我上周也踩过，AgentExecutor默认确实不会把tool output自动塞进下一轮上下文，它只保留最后的thought和action。你加memory和chat_history其实方向对，但得在prompt里显式告诉模型“以下是之前工具返回的结果，直接引用别重查”，不然模型还是倾向于自己推理。我之前试过最笨的办法是把工具结果用SummarizerMixin压缩后再丢进memory，但

试试把检索结果分块编号再让模型逐段引用，或者用XML标签包住上下文，效果比纯文字强调稳定很多。 也遇到过这问题，后来在query里加一句“如果信息不在上下文中请直接说不知道”，比改system prompt管用。

几百万条这量级其实两边都能扛住，不用太担心Qdrant扩展性，它单机性能很能打，真要分片也能上k8s operator。我倒是觉得你更该纠结部署运维成本，Milvus那套依赖etcd、minio、pulsar，光搭环境就够喝一壶，Qdrant一个binary直接跑，真出问题排查起来也简单。延迟这块，HNSW参数别照抄默认，M值调到32左右，efConstruction设200，查询时efSearc

同感，医疗领域术语密度高，通用embedding确实容易把“病因”和“饮食禁忌”混为一谈。我建议先别急着微调模型，试试把查询改写一下，比如用LLM把问题拆成几个子查询再分别检索，最后合并去重，这个对提升召回针对性挺管用的。另外chunk 512可能还是太大，你可以试试按语义段落切分，比如按“症状-治疗-禁忌”这种结构来分块，比固定长度效果好很多。重排序的话，试试换个更强的模型比如cohere re

说实话我觉得问题大概率出在ResNet50的特征上，这个模型提特征对商品这种细粒度差异本来就不太友好，颜色主导了距离计算。你可以先抽1000张图用暴力检索测一下上限，如果暴力检索召回也低那就别折腾Milvus参数了，直接换模型或者加个rerank环节。另外归一化确实建议做，特别是用IP距离的时候，不然向量模长影响太大了。

LoRA微调确实容易把指令跟随能力带偏，试试把few-shot样本换回alpaca原版格式再跑下。

试试把topk降到3~5，再按业务线提前给chunk打标签过滤，效果立竿见影。 我们之前也踩过这坑，后来加了个rerank模型按query重排，只留前3个，回答立马干净了。

我最近也踩过类似的坑，把prompt当成代码来写，规则越堆越多，模型反而开始“发挥”了。后来发现关键在召回质量，而不是把约束全塞给生成环节，先保证检索到的片段足够干净更重要。另外输出格式要求太死的话，模型很容易在格式上强行对齐，内容反而飘了。现在我就写一句“基于给定材料回答，若材料中没有则明确告知”，其他全靠上下文本身去约束，效果反而稳了不少。

这问题太典型了，我之前调bert做抽取也踩过坑。loss停在1.2大概率是模型在学“怎么说话”而不是“说什么”，你5000条数据里要是每条都带“您的意思是”这种前缀，它当然有样学样。建议把训练集里的自然语言描述全砍掉，只留标签，最多加个“意图：”这种极简前缀，让模型没得抄。另外学习率调低到2e-4试试，我体感QLoRA用太高容易让输出飘。至于JSON格式，就别指望纯靠prompt约束了，解码时用g

你这需求我太懂了，pandas的concat和merge确实天差地别。我一般会把输入输出的样子直接贴在提示词里，比如“每个Excel第一行是列名，只要A列和C列，输出到新表的D列和E列”，再让AI自己选函数。还有个小技巧，让AI在代码里加try except和print每一步的shape，这样报错一眼就能定位，不用来回试。

重排模型大概率得加，你这问题明显不是embedding能解决的，长尾查询对向量相似度的依赖本来就弱，bge-reranker交叉编码器能直接看query和doc的交互特征，效果会立竿见影。HNSW参数我倒觉得优先级不高，M和efConstruction主要影响召回上限，你现在是top5里混入不相关结果，更像是排序阶段的问题。另外可以试试把chunk_size固定在中位数附近，别来回调，有时候分块粒

这情况不奇怪，微调数据太单一，把模型学成“格式控”了，逻辑反而被带偏。

这问题太真实了，我现在项目里也卡在这。我的做法是给历史对话按“意图窗口”做截断，只保留跟当前问题实体重叠的几轮，再压缩成摘要塞进system prompt，token能省一半。不过摘要质量不稳定，有时候关键数字会被丢掉，你那边有试过按时间衰减权重来处理吗？ 我最近试了个土办法，把历史会话按主题聚类，只把跟当前query语义最接近的那一簇送进RAG检索，效果比全量塞给模型好不少。但就是聚类延迟有点

我最近也踩过类似的坑，LoRA微调完loss好看但实际输出就是会飘。感觉你这个问题更多是数据构造的问题，5000条里格式多样性可能不够，模型对“严格JSON”和“自然语言”的边界没学好。工程兜底的话，我建议写个容错解析器，把换行和空格先正则清掉，再对工具名做模糊匹配，能救回不少case。另外可以试试在训练时故意混入一些带噪声的负样本，让模型学会修正格式，效果比单纯调温度稳定多了。

说实话我一开始也有这个困惑，后来自己动手把OpenAI的function calling和MCP都走了一遍才稍微明白点。你感觉底层逻辑差不多是对的，因为核心都是“把工具描述喂给模型让它选”，但MCP真正多出来的东西是那层标准化的传输和资源管理。比如你的文件搜索tool，如果只用function calling，那每个客户端都得自己写一套怎么连、怎么鉴权、怎么处理错误，而MCP把这块统一成了协议，你

vLLM在2C4G上跑8B真的有点难为它了，这货本身框架开销就不小，int4只是省了模型权重，KV cache和中间激活照样吃内存。我之前在4G服务器上试过Qwen2.5-7B-Q4_K_M，用llama.cpp的server模式，把max context设到1024，推理大概3-4 token/s，做demo勉强能蹦几个字。建议你换llama.cpp或者Ollama试试，vLLM适合大显存机器，

COT适合拆逻辑，不适合搞性能优化，直接让它按快排伪代码写反而靠谱。

这问题太典型了，AgentExecutor默认只把当前这一步的输入输出喂给下一步，跨工具的状态确实容易丢。我之前也踩过这坑，后来干脆不用它的memory，自己在外面维护一个全局的中间结果缓存，每次工具返回后把关键信息塞进去，再拼到下一轮的prompt里。另外可以试试给工具加个状态参数，强制让Agent把前一步的结果传进去，不然光靠隐式记忆大概率是不行的。