AI
未读
NLP评估指标:你的模型到底好在哪
数语觅类的评估从来没让我纠结过。精度、召回、F1、完全匹配率——四个指标各管一个维度,算起来也简单:模型输出一组标签,标签要么对要么错,逐个比完就有数了。我甚至做了个加权 score 把它们合成一个数,直接塞进训练循环当监控信号: @property
def score(self) -> float
AI
未读
训练控制的统计化——当 loss 和评估分数开始撒谎
衔言渡意第二轮训练(15.5M)的末期,val loss 从 2.461 一路降到 2.422,模型还在学。但同一段时间里 BLEU 的表现是这样的: 19.95 → 17.91 → 18.96 → 16.56 → 18.14 → 18.30 → 18.51
上蹿下跳,epoch 间跳两三分是常态
AI
未读
KV Cache 实现手记——高估了,低估了,然后搞懂了
在衔言渡意的训练收尾阶段,我给自己的最后一项技术任务是给推理加上 KV Cache。 我对这个东西的第一印象来自行业讨论——到处都在说 KV Cache 管理、PagedAttention、prefix sharing。脑子里自动补全了一整套分布式系统的画面:用户登录鉴权,会话状态持久化,多轮对话中
AI
未读
模型容量不够——下一步是加层还是加宽?
衔言渡意是一个中英法三语互译的小模型。训练到第二版(15.5M 参数,192 维,6+6 层),BLEU 到 15.6 后走平,val loss 不再下降——容量到顶了。 需要扩容,但往哪个方向扩? 加层和加宽不是同一件事。层数管的是串行处理深度——嵌套从句需要逐层解开,层不够就解不动内层。维度管的
AI
未读
从数据反推模型架构:一个小模型训练的经验公式
引言:差了一个数量级 韵染流光是6060万参数,数语觅类是420万参数。同样是从零训练的小语言模型,参数量差了14倍。 我知道数语觅类更简单。韵染流光的DSL是我多次推翻重新设计的结果,自然语言理解、多轮上下文追踪、近似方法调用的DSL解析——这些东西叠在一起,学习难度很高。数语觅类就是给列名和样本
AI
未读
通用 Tokenizer 评估方案——从项目专用到任务无关
数语觅类(我的第二个项目,数据库列语义分类)里写了一个 verify 函数,用来评估 tokenizer 的词表大小是否合理。核心逻辑是对样本做编码,统计平均 token 数,然后给建议: # 评估建议(基于样本)
if avg_length > 20:
print(f"⚠️ 建议: 单项
AI
未读
LLM模型资源占用优化
模型加载流程 模型加载时, 做这些事情: 加载配置信息 模型结构、层数、注意力头数、参数精度等元信息 加载模型权重 下载或使用已经缓存的模型权重文件 如果模型使用bin格式,需要PyTorch版本大于等于2.6 若PyTorch版本低于2.6,则需要使用safetensors格式