周末商业进阶录

试试把topk降到3-5，或者加个rerank环节，相关性过滤比单纯靠分数靠谱多了。

8G跑1B的LLaMA 3.2确实紧巴巴的，但你这一套配置按理说不该直接OOM。我怀疑问题不在batch size或序列长度，而是8-bit量化后的显存占用跟你想象的不一样——bitsandbytes的LLM.int8()在训练时其实会保留一部分fp16的梯度/优化器状态，实际显存开销比纯推理高不少。建议你先把gradient checkpointing确认真的生效了，有些教程里的写法在trans

我也遇到过类似问题，后来发现chunk size和overlap其实不是最关键的，文档本身的结构更重要。建议你先按标题层级把文档拆成独立段落，比如每个一级标题下的内容单独切，再结合小overlap（比如50-100字符）试试。另外，embedding模型对长文本的语义理解有限，太长的chunk反而会稀释关键信息。如果售后政策有固定格式，比如FAQ那种，可以考虑单独提取出来作为独立chunk，检索效

我也遇到过类似的问题，AI太容易陷入局部视野了。我的做法是先用ast-grep这类工具把调用链和依赖关系扫出来，生成一个精简的上下文索引文件，再把这个索引和重构目标一起喂给Agent，效果比单纯丢项目结构文档好不少。另外，你可以在Prompt里明确指定“每次修改前先检查这个索引文件”，强制它做全局考量，虽然不能完全解决但至少能减少漏改。

这个问题太真实了，我最近也在折腾这个，简直是一模一样的坑。你说加few-shot和写死约束，我也试过，但模型一换就废，特别是Claude和GPT对格式的敏感度完全不一样。我现在最常用的做法是两层保险：第一层是在system prompt里把输出格式定义成类似Pydantic模型的结构，用代码块包起来，明确告诉模型“只输出这个代码块里的内容，不要任何额外文字”；第二层就是加一层轻量的校验重试逻辑，比

我最近也踩过类似的坑，你这个情况大概率是chunk切分的问题。技术报告里表格经常被切到不同chunk里，模型只看到一半数据，自然容易漏或者混淆。我之前试过把表格单独提取出来做结构化存储，然后在Prompt里明确告诉模型“先查表格数据，再读正文”，效果会好一些。另外你的Prompt模板如果太笼统，比如只写“提取关键指标”，模型容易自己发挥，我后来改成“逐行列出每个模型对应的准确率、召回率、F1值，如