小禾_Java手记

豆瓣这类站其实用requests加个完整浏览器头就够了，重点是把Accept、Accept-Language、Referer这些补全，别只换UA。让AI写的话直接告诉它用session并模仿真实浏览器请求头，比反复换UA管用。代理池新手真没必要一上来就搞，先试试控制频率加随机休眠，实在不行再考虑。另外豆瓣对未登录用户挺敏感的，挂个cookie能稳不少。

回复: 用AI编程助手写Python爬虫，怎么老是被反爬拦住？ 15天前

这个问题我也遇到过，Claude确实特别爱“贴心”，尤其画图和日志这俩简直是它的默认动作。我的经验是光说“不要加”没用，得把边界写死，比如明确告诉它“只输出一个函数，不要import任何库，不要print，不要画图”，越具体越管用。另外可以要求它先复述需求再写代码，这样跑偏了你能马上发现。完全靠提示词根治不太现实，最后还是得扫一眼，但能省不少删代码的功夫。

回复: Claude写Python代码总喜欢自作主张加功能，怎么控制 23天前

7B写复杂SQL确实吃力，换CodeQwen或14B会好很多，模板建议用vanna那种带schema的。

回复: 用Qwen写SQL老出错，是我Prompt姿势不对还是模型就 23天前

这问题真不全是工具的事，Cursor的Composer确实有“改一处动全身”的毛病，我一般会先圈定范围再让它动手，不然diff能吓死人。你同事说的“顺从AI”我也有同感，模型天然喜欢拆函数、加类型，写业务代码反而显得绕。我的做法是让它先给方案我再手动落地，或者干脆用inline模式只改局部。你可以试试在prompt里明确写“最小改动、不重构”，会好很多。

回复: 用Cursor写业务代码总被同事吐槽，是我姿势不对还是工具不 23天前

这种问具体数字的查询，关键词匹配和向量语义经常打架，试试加个元数据过滤或混合检索，光调chunk没用。

回复: RAG系统检索结果不准，是chunk切分问题还是embedd 23天前

12G显存跑8B的fp16确实不够，光权重就16G了，爆是正常的。4-bit量化慢可能不是量化的锅，先看看是不是CPU卸载了部分层，GPU没吃满的话速度肯定上不去。中文效果4-bit会有损失但日常够用，Q5_K_M或者Q6_K更稳一点，3060跑Q4其实勉强能接受。工具链的话Ollama省心适合快速试，LM Studio界面友好，想折腾性能还是vLLM或llama.cpp手动调参更实在。

回复: 有没有人把Llama 3.1 8B在本地跑起来？我的RTX 23天前

给几个典型输入输出示例比说“考虑边界”管用多了，模型照着例子补逻辑稳不少。

回复: 用Prompt写代码总在边界条件翻车，怎么让LLM稳定输出可 24天前

我也遇到过，感觉模型就是有“命名洁癖”，哪怕你写死了它也要顺手改成更常见的名字。后来我干脆在Prompt里加一句“变量名必须严格用我给的，改了就算错”，效果好了不少。还有个办法是把指定名字的代码框架先贴给它，让它只填逻辑，别动结构。另外温度调低一点也有帮助，默认温度下它太爱自由发挥了。

回复: 用Prompt写Python脚本，为什么GPT总把变量名改来 24天前

试试把异常处理拆成单独一步让它补，别指望一次生成就全带上。

回复: 用Prompt让Claude写Python脚本，总是漏掉异常 24天前

我之前也把啥都往一个State里塞，后来拆成几个TypedDict按节点需要组合，清爽多了。MemorySaver确实只管checkpoint级的短时状态，长期记忆我一般单独走向量库或Redis，跟State解耦。子图状态传递可以试试在父图里定义共享字段，子图只声明自己关心的那部分，别全量透传。对了，LangGraph的Command和Send API处理分支传参挺顺手，值得看看。

回复: 用LangGraph写Agent，状态管理和记忆到底该怎么设 25天前

用tokenizer的padding_side配合attention_mask，模板部分单独算完再拼，别让pad混进特殊token里。

回复: 用PyTorch写Prompt模板时，怎么优雅地处理batc 26天前

我也踩过这个坑，之前一口气挂了六个server，工具列表直接爆炸，模型每次都要在几十个工具里挑，延迟肉眼可见地涨。后来我的做法是按场景拆Agent，不要让一个Agent扛所有工具，比如写代码的只给它文件和Git，运维相关的单独一个Agent接数据库和Slack，这样每个Agent的工具数控制在十个以内，准确率明显回升。相似工具的冲突问题确实烦，光靠system prompt压不太住，模型该选错还是

回复: MCP服务器连多了会不会拖慢Agent？大家生产环境一般挂几 26天前

40G确实偏高，但也不是完全没可能。vLLM默认会按gpu-memory-utilization预分配KV cache，0.9在4090上就是接近21G左右专门留给cache，加上7B模型fp16权重大概15G，再加上CUDA context、激活值和框架开销，冲到三十多G不奇怪。你看到的那些20G出头的博客，多半是开了量化或者把max-model-len压到2048、gpu-memory-uti

回复: 用vLLM部署Qwen2.5-7B，显存占用飙升到40G正常 26天前

量化确实有影响，Q4_K_M对7B模型来说损失挺明显的，尤其是指令遵循这块，你试试Q5或Q6对比一下就知道差距了。不过更核心的问题是在线API那个模型参数量大概率比7B大不少，小模型本身对复杂prompt的理解就是会打折扣。我自己的经验是把系统提示词写得更硬一点，比如明确说“只输出正文，不要解释”，然后few-shot里给两三个严格符合格式的例子，比调temperature管用。另外任务拆细确实有

回复: 大模型本地部署后Prompt写不好，效果还不如在线API，正 26天前

几百万这个量级pgvector其实完全扛得住，HNSW索引建好查询延迟也很低，关键是你们团队已经在用PostgreSQL，运维成本几乎为零，省下来的精力够调好几轮参数了。Qdrant我也用过，过滤查询确实比Milvus顺手，但真要上生产，生态和文档这块还是得自己多填坑。HNSW那个m和ef_construction别一上来就拉满，先从m=16、ef_construction=200试，ef_sea

回复: 向量数据库选型纠结死了，Milvus和Qdrant到底怎么选 28天前

时间窗口切块本身没问题，但你漏了很关键的一点：向量召回是纯语义的，它压根不知道“新”比“旧”重要。建议在检索后加一层时间衰减打分，比如按天数做个指数衰减再重排，成本很低效果立竿见影。串台那个事，光靠session_id过滤不够，得把项目维度也塞进metadata里，查询时强制带上。另外你说top_k调了没用，很可能是embedding模型对短对话区分度太差，可以试试把每轮对话拼上摘要再入库。

回复: 用向量数据库做Agent长期记忆，召回不准还老串台，是我姿势 29天前

5万条切片用text-embedding-3-small其实够用了，问题大概率不在向量库上，PGVector和Milvus在召回质量上没本质差别。你试试把chunk的粒度改一下，按语义段落切而不是固定字数，报销和年假混在一起很可能是切片把不同主题揉一块了。另外纯向量召回确实容易飘，加个BM25关键词召回做混合检索，再拿cross-encoder精排top50，效果比死磕阈值强得多。

回复: 向量数据库做RAG，召回率上不去还有救吗？求大佬指条明路 29天前

几十万切片真不算大，ES扛得住就别急着拆架构，维护两套系统的成本比那点召回提升高多了。我之前也踩过这个坑，换到Milvus后发现过滤还得自己写，反而更累。混合检索建议直接上，纯向量在专有名词和缩写上翻车概率太高，BM25兜底很香。先把ES的向量参数和分片调一调，实在不行再考虑迁。

回复: 向量数据库和ES到底怎么选？做RAG感觉越用越糊涂 29天前

几十万片用Chroma确实会开始吃力，它底层还是SQLite那套，量大了索引和检索都会拖后腿，不是配置能救回来的。我去年也踩过这个坑，后来换成了Qdrant，单机跑一个二进制就行，不用etcd那些乱七八糟的依赖，docker起一个容器就完事，几十万向量检索基本毫秒级。如果你不想换太大的技术栈，其实Milvus有Lite版本，但说实话Qdrant的API和文档对新手更友好，过滤条件写起来也顺手。混合

回复: 向量数据库搭配开源大模型做RAG，求推荐一个不太折腾的？ 29天前

这个差值0.1-0.2确实挺典型的，我之前转YOLOv5也踩过类似的坑。你重点先别怀疑量化，因为export默认是FP32，根本没走量化流程，问题大概率出在图优化或者算子实现差异上。先拿ONNX Runtime关掉所有图优化再跑一遍，用session_options.graph_optimization_level = ORT_DISABLE_ALL对比下，如果关了优化结果就接近了，那就是融合算子

回复: PyTorch转ONNX后推理结果和原模型差很多，是量化问题 29天前

发表的评论