青空种树集
Lv.1把零散灵感沉淀为可复用的方法，关注技术学习与数字生活，记录学习路径整理、知识体系搭建和真实实践中的思考；关注技术选择背后的成本与边界。这里不卖焦虑，只分享方法和真实经验。
发表的评论
表格数据被切散确实很常见，尤其是PDF转文本后表头跟数值分到不同chunk里，模型根本对不上号。我一般会单独把表格抽出来做结构化解析，比如用pdfplumber或者unstructured，再拼回上下文。另外你可以试试让模型先输出原文片段再提取指标，相当于强制它引用来源，漏的概率会低不少。
显存涨到20G确实有点夸张，ResNet50+bs8理论上12G左右就够了。建议先用torch.cuda.memory_summary()看看是谁在涨，大概率是某个中间变量没释放，比如你验证集忘了加torch.no_grad()，或者loss累加时把计算图也存下来了。另外检查下dataloader的num_workers和pin_memory，有时候cpu端张量没及时释放也会拖累显存。
实际项目里固定一个模型就行，换来换去重生成向量太折腾，1536维在Milvus跑着没毛病。
单次Prompt生成完整代码本来就难，建议拆成小函数逐步验证，比反复调咒语靠谱。 我试过把需求拆成几个子任务让GPT分步写，再人工拼装，出错率低很多。
没有万能搭配，本质是chunk粒度跟查询粒度对齐，建议按问题类型做混合检索。
你这问题其实挺典型的，根源在于开源模型对“约束条件”的优先级理解不够稳定。我试过把异常处理拆成子任务塞进system prompt，比如单独列一条“必须包含try-except块覆盖Timeout和HTTPError”，效果比堆在指令里好很多。另外，建议直接把函数签名给出来，比如“def fetch_title(url, timeout=10):”，模型就不容易漏定义。你可以试试把prompt改造
实测数据我跑过类似场景，LongCat在batch size 1时那30%的优势确实诱人，但一压到16并发，显存直接爆掉，DeepSeek的稀疏注意力反而把吞吐撑住了。不过有个点想  确认下——你提到的长尾精度损失，具体是哪些任务掉得厉害？我这边试代码生成时，LongCat在复杂逻辑分支上经常答非