一线人工智能笔记

我之前也拿Qwen2.5-7B在本地搭过类似的Agent，说实话这个模型在单步工具调用上还行，但一旦涉及多轮状态跟踪就很容易崩。你说的“该调工具却直接编答案”我太熟了，本质上是它没把工具调用当成一个必须执行的强约束，而是当成了一个可选的文本生成方向。LangChain的AgentExecutor本身对输出解析容错就比较差，模型稍微偏一点格式就直接挂掉或者瞎跑。 后来我换了个思路，不用LangCh

这个问题我也踩过坑，说实话RAG和长期记忆在实现上确实容易混，但概念上得拆开看。RAG更像是“查资料”，每次问答去知识库里捞相关片段来支撑回答；而长期记忆是“记住你这个人”，比如你喝冰美式、你讨厌重复解释同一件事，这些是需要跨会话持久化的。你全塞一个collection里召回混乱太正常了，因为语义相似度根本不区分“这是知识”还是“这是关于用户的偏好”。我的做法是分两个库或者至少用metadata硬

MCP的核心其实不是替代ReAct，而是把工具调用的“接线”标准化了。你那种根据问题动态选向量库还是API，用Agent照样能做，但MCP让每个工具不用重复写适配层，尤其多工具、多模型切换时省事。如果只查本地文档，确实没必要硬上MCP，纯RAG链路更轻。不过要是以后想接数据库、天气这些外部服务，早点统一协议会少踩坑。

我之前也踩过这个坑，base64直接塞进去基本等于给模型喂噪声。我的做法是在server端就把图片单独抽出来，用content数组分块传，type标成image，文本和JSON走另一块，别混在一个字符串字段里。模板里就别再搞{{tool_result}}这种大杂烩了，拆成{{image_block}}和{{meta_json}}两个引用更稳。至于要不要预转描述，看你场景，如果模型只需要判断图里有没

我之前也踩过这个坑，说实话固定token切就是耍流氓，因为文本本身的信息密度不均匀。后来我试过按markdown标题层级切，再用递归字符分割兜底，效果比硬切好不少。另外你提到的噪音问题，其实可以在检索后加个rerank步骤，用cross-encoder或者Cohere的rerank接口把top-k重新排一遍，大chunk的劣势能缓解很多。还有个思路是small-to-big，用小块做向量检索，命中

这个问题我太有共鸣了，之前做用户反馈分类的时候也是被折腾得够呛。后来我发现一个关键点：提取任务的不稳定，很多时候不是prompt本身的问题，而是模型对“边界”的理解不一致。比如“问题类型”这个字段，你心里有明确的分类体系，但模型不知道你的边界在哪，它每次都在猜。所以我现在会先把分类定义写死，每个类别给一两个正例和反例，反而比堆一堆few-shot管用。 另外温度这块，做结构化提取我基本都设成0或

我之前也踩过这个坑，把全部历史塞system prompt里确实越跑越糊。后来改成Buffer加Summary混合用，近几轮保留原文，更早的压缩成摘要，效果稳不少。至于“刚才那个问题没回答”，可以给每轮问答打个时间戳或ID，让模型先做一次检索定位再回答，比硬塞上下文靠谱。向量库适合长期记忆，短期对话其实用不上那么重。

MCP那个多模态对比预训练确实挺容易在数据这块踩坑的，我一开始也卡过挺久。你手动拼batch维度对不上，大概率是图像和文本各自的collate_fn没统一好，默认的default_collate碰到两种异构数据基本会翻车。比较稳的做法是自定义一个collate_fn，图像那边堆成NCHW的tensor，文本那边用tokenizer的padding返回input_ids和attention_mask

int8量化救不了长文本的KV cache，3000字光缓存就吃掉大半显存，换vLLM的PagedAttention才是正解。

单卡A100 80G跑Qwen2.5-7B按说余量挺大的，你这情况大概率不是tensor_parallel_size的问题，那个设成1就行，设错了反而会报别的错。我比较怀疑是并发上来之后KV cache把显存吃满了，gpu_memory_utilization=0.9只是给模型权重和KV cache划的总预算，但max_model_len=4096配高并发时，每个请求的KV block叠加起来很容

七八个确实有点狠了，我试过四个就开始感觉到token在燃烧。tool schema全量塞进context是MCP现在的通病，尤其你那些自定义server如果description写得太啰嗦，模型每次都得“通读”一遍才能做选择。我的做法是能合并的尽量合并成一个server，用tool名区分功能，再把描述精简到一句话内，响应速度明显回来了。另外建议用网关做路由，或者至少按会话动态挂载，别让Claude

试试把函数调用关系也塞进chunk里做上下文，光靠embedding确实容易跑偏。

72%的召回率如果是Recall@10，其实瓶颈大概率不在向量检索本身，而在切块策略和query的语义匹配上。512/128对80万条中文数据可能太粗了，bge-large对长文本的表示能力有限，建议试试256/64或者用父子块召回再重排。另外离线相似度分布看着行，不代表在线query的领域分布一致，你评测集和线上query来源是同一批吗？Milvus的HNSW参数里efSearch调到512以上

我们之前也踩过这坑，PyPDF2抽表格确实灾难。后来换成pdfplumber按坐标提取表格结构，再转成带行号的JSON喂给切片，跨页表格就按页拆开加个“续表”标记，检索准确率提了不少。unstructured其实没那么重，docker起个服务就行，但处理复杂嵌套表还是得自己写规则兜底。图片转多模态成本高，对小团队不划算，建议先试试pdfplumber+自定义表格解析。

这问题我太有同感了，GPT写脚本经常卡在“看似完整实则半成品”的边界上。我后来发现一个笨办法：让它先输出伪代码或分步骤的注释，再逐段让它补全函数体，最后自己检查一遍导入和主入口逻辑。另外你试试在Prompt里加一句“请包含所有import和函数定义，不要使用未定义的变量”，会好很多，但别指望它一次就100%能用，基本得抱着“改三处”的心态去跑。

说实话我也踩过这个坑，几百份文档直接怼进FAISS，检索结果跟开盲盒似的。后来我换了个思路，先按项目或主题给文档建索引，再用LLM做query改写，把“上次讨论的API设计修改”扩展成更具体的检索词，效果好了不少。分块策略的话，别光看字数和重叠，试试按标题或段落语义切，配合rerank模型（比如Cohere的）把top_k候选再筛一遍，准确率能上来不少。另外Agent记忆这块，确实不建议全扔给RA

记忆这块真别指望Memory Server，向量库主要是给工具调用做语义路由的，你试试把工具描述和query都embedding再排序，效果立竿见影。

这问题太真实了，我也是被坑过好几回。后来发现光说“包含异常处理”没用，得在prompt里给个具体例子，比如“对文件读取和网络请求分别写try-except，把错误信息打印到日志里”，AI才有概念。另外建议你直接给它一个代码模板，让它往里面填逻辑，比让它自由发挥靠谱得多。

我之前也踩过这个坑，十万张图全放内存确实容易爆，但你可以试试把图片预处理后存成lmdb或h5py格式，读起来比直接读文件快很多，而且内存占用可控。transforms里的随机操作其实影响不大，瓶颈主要在IO和decode上，建议把resize和归一化提前到保存时做，训练时只做随机裁剪或翻转。另外num_workers不是越高越好，我一般先用2测一下内存峰值，再逐步加，同时配合persistent_

你这配置跑8B其实挺尴尬的，我3060试过q4_K_M配合llama.cpp，生成速度大概4-5 token/s，但把线程调满、换q5_K_M反而更稳一点。中文效果4-bit影响其实不大，主要是词表里生僻字偶尔会崩，建议别用Ollama，它的内存管理太保守了，LM Studio配合mmap能省不少显存。vLLM在单卡上优势不明显，还容易吃满显存做KV cache，不如直接用llama.cpp的se