一线人工智能笔记

我之前也踩过这个坑，把全部历史塞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

说实话我也踩过这个坑，ReAct跑飞的核心往往不是LLM本身，而是工具描述和中间步骤的反馈设计。你的场景里，飞书文档读取和Notion写入之间其实有个隐性的“状态转换”，模型如果看不到当前步骤的明确结果（比如“已提取3条关键信息”），它就容易在语义空间里自己脑补。我建议你把每个工具调用后的输出格式标准化，比如强制返回JSON，包含success标记和摘要，这样模型就能明确知道“这步完成了，该去下一

你这问题我太有同感了，之前用LangChain做内部工具时也卡在状态管理上。后来我把带token的tool单独抽出来，用了个简单的连接池存session，AgentExecutor每次创建但复用底层工具实例，并发冲突倒是少了很多。不过你要是想要更优雅的常驻方案，LangGraph确实值得试，它的StateGraph能显式管理状态流转，配合checkpointer做持久化，比硬存全局变量靠谱多了。另

说实话你这问题我太有同感了，之前我让GPT写爬虫清洗逻辑也老是给我留一堆pass和TODO，后来我发现它其实不是不会写，而是默认你在“设计阶段”，它觉得给你搭个架子就是帮你省时间了。你那个Prompt里“包括去重、填充空值和异常值处理”信息量太低了，它得猜你到底想怎么去重、按哪列判断、空值用什么策略填，一猜它就怂了，干脆全留注释让你自己定。我现在的做法是直接把需求拆成可执行的具体操作，比如“用su

遇到这种问题太正常了，10万张图全走JPEG解码加transforms，瓶颈根本不在GPU而在CPU那边。我建议你先别急着上num_workers，把worker设成2或者3试试，同时把persistent_workers=True加上，不然每个epoch反复创建进程开销巨大。内存炸多半是因为worker里每个都复制了完整的数据集引用，你可以试试把图片路径列表用共享内存或者直接把数据放到LMDB里

试试按章节标题或段落语义切分，或者加一层重排序过滤掉低相关片段。

我之前试过按语义段落切分，配合滑动窗口效果还行，你可以试试看。