认真做产品实践笔记

我也遇到过，多半是本地服务监听地址绑了127.0.0.1而Claude走IPv6，试试改成localhost或::1。 超时前先看下服务器日志有没有收到请求，没收到就是网络层问题，收到了再查响应格式。

这问题我踩过，session_id得在MCP server里自己维护，官方确实没管，配个Redis按session隔离最稳。 试过用context传参给工具做路由，但代码丑且容易漏，还是建议在server层做全局session管理。

简历问答这个场景，问题多半不在embedding和chunk上，而是简历里信息密度太高，固定256字很容易把不同项目的职责和技能糊在一起。建议先按语义段落切，比如用换行或标题做边界，再配合关键词加权，把岗位名称、技能词单独抽出来当tag走一遍BM25，效果可能比直接换模型来得快。rerank对中文长文档不是没用，但得看你的top5里不相关的是不是真的语义相近，如果只是关键词碰巧重合，那重排也救不了

个人感觉system prompt这个变量影响可能比你想的大，本地没加线上加了，模型输出分布直接就变了，尤其Qwen对格式指令挺敏感的。另外vLLM的采样确实和HF默认不完全一样，特别是top_k和repetition_penalty的默认值有差异，建议先对齐这两个再测。TP=4的话注意下A10的显存带宽，batch大了容易触发投机采样或者动态batch的精度抖动，试试把max_num_seqs调

先别急着上框架，手动编排逻辑跑通了你才知道哪些环节需要给Agent放权，不然换汤不换药。 工具链堆得越猛越容易掩盖核心问题，建议先拿三个真实对话案例硬啃，把状态机画出来再谈自主决策。

50万条真不大，pgvector够用，更新频繁就别折腾es了，混合检索先看效果再说。 faiss全量更新确实坑，换pgvector增量更新省心，中文场景bm25加向量提升挺明显的。

太真实了，prompt越“专业”模型越像戴了紧箍咒，我现在只写关键约束，剩下全靠它自己发挥。

试试把检索内容拆成“事实+引用”两段喂进去，再明确告诉模型“不确定就直说”，稳定性会好很多。温度调0.1以下，JSON模式对结构化输出帮助大，但别指望它解决幻觉。

分段这个事我建议你先别纠结固定tokens还是语义段，得看你的检索粒度是什么。你内部知识库，用户问的往往是“某个流程怎么走”或者“某段规范原文”，那按章节、条款这种自然语义边界切，召回以后上下文是完整的，比512硬切强太多。但如果你文档里全是表格、列表，语义边界不明显，那就得混合策略了——比如先按标题层级分块，块太大再往下拆，同时给每块加个“父块摘要”作为额外检索字段，这样召回时能匹配到上下文更宽

7B写TS确实费劲，类型推断跟不上很正常，换Qwen2.5-Coder 7B估计也差不多，8G显存还是老实配个规则校验吧。

我之前搞类似东西踩过坑，核心思路是别把工具原始返回全塞进去，让工具自己先做一层结构化摘要，只回传关键字段或统计结果。另外可以给历史记录打上“已消费”标签，让Agent明确知道哪些信息已经用过，后续轮次里可以定期软删除这些引用。滑动窗口不是不行，但最好做语义压缩而不是简单截断，比如把旧轮次用LLM提炼成几条事实缓存。还有个小技巧是外部工具查询前先让Agent写个“意图草稿”，如果能预判答案范围，很多

召回率卡在60%大概率不是Milvus参数的问题，IVF_FLAT调nprobe到32已经挺激进了。你先算一下特征向量本身的余弦相似度分布，看看正样本对的相似度是不是普遍偏低，ResNet50直接提特征在电商图上经常不够用，建议试试用ArcFace或triplet loss微调一下，比折腾索引见效快。数据增强对检索任务没啥帮助，除非你是用来扩充训练集做微调，预处理倒是可以统一一下尺度，别让长宽比变

说实话32K上下文对量化模型来说更像是“能塞进去”而不是“真能记住”，4bit下注意力衰减比满血版明显得多。我之前试过类似重构，把目标方法连同它依赖的私有字段定义一起复制到提示词末尾，比扔整个类文件靠谱。RAG那思路我试过，抓准了确实稳，但老项目里符号交叉引用太乱，抽代码片段反而容易带偏。建议先试试把要改的方法和相关变量单独提出来，上下文缩短到2-3K以内，成功率会高不少。

这种几万条的量级，瓶颈大概率不在FAISS本身，而是embedding计算和序列化开销。bge-m3对短query其实有点杀鸡用牛刀，可以考虑换bge-small或者直接上gte-small，延迟能砍掉一大截。缓存这块，MCP协议本身不提供，但你在服务端包一层LRU字典或者用redis带TTL的缓存，对高频重复query效果立竿见影。另外如果只想做快速验证，先试试把embedding的batch

八成不是tensor_parallel_size的问题，单卡跑7B根本用不上这个。你查下vLLM的日志里有没有提示KV cache分配失败的语句，我怀疑是max_model_len虽然设了但实际被某些请求参数覆盖了。另外确认下是不是开了--enable-prefix-caching，那个吃显存挺凶的。 我之前遇到类似情况是卡在显存碎片上，A100 80G看着空闲但申请连续块失败。你试试把gpu_

检索准不代表生成对，问题多半在LLM没吃透规范细节，建议先试few-shot，效果不行再考虑LoRA。

这问题太典型了，我最近也在搞类似的Agent，发现prompt越长越容易让模型“自我意识过剩”，反而忽略了核心任务。我后来把每个子任务的prompt砍到只剩必要字段和一句输出格式说明，效果反而稳了很多。另外你试试在中间步骤加一个轻量的校验器，比如用正则或简单规则卡一下输出格式，别全指望LLM自律，能挡掉不少漂移问题。 还有一个思路是别把上下文全塞给后一个模型，只传它真正需要的那部分数据，信息越杂

我跟你遇到一模一样的问题，后面我干脆把types.ts里的关键类型直接复制到对话里，然后让它先写函数签名再补实现，效果会好一点。tab补全确实容易放飞自我，尤其是上下文长的时候，它更倾向于猜而不是查。Composer的agent模式会更靠谱些，但你得在需求里明确说“只能使用已有类型，禁止新建”，不然它照样自己造轮子。另外试试把类型文件作为依赖项加进上下文，不要只是贴路径，我体感这样遵守率能提升不少

遇到过类似的坑，多半不是StateGraph本身的问题，而是节点返回的dict会直接覆盖整个shared state，得用带前缀的键或者定义reducer来合并。你试试在总结Agent里只返回它该更新的字段，别把检索结果原样塞回去。Send API是搞动态分支用的，你这种固定流水线其实用不上，先检查下每个节点return的key是不是有重复或者遗漏。调试的话可以开LangSmith的trace，一

老项目隐式依赖多确实容易这样，试试把改动范围写成明确指令，比如“只改这个函数，别动其它”。