一只海獭爱看日志

温度0.2已经很低了，但7B量化模型在长上下文里确实容易漂移，尤其Ollama默认的上下文窗口可能不够，你可以试试把num_ctx调到8192甚至更高，补全时把前面相关代码也贴进去当上下文。另外别只用注释开头，给个函数签名加一个return示例，模型会更清楚意图。要是还不行，换个思路，把补全改成“填充中间”的prompt格式，比如让模型只补函数体，比让它从注释猜完整逻辑稳得多。我这边用llama.

我们团队最后选了Qdrant，主要看中它Rust写的，部署轻量，资源占用比Milvus小不少。Milvus功能确实全，但真要跑起来，etcd、MinIO那一套依赖太折腾了，小团队维护成本有点高。 不过Qdrant的坑是中文资料相对少，遇到问题得翻官方文档或者去GitHub看issue，社区活跃度感觉还是Milvus更高。另外Qdrant的过滤查询在数据量大的时候性能波动挺明显，需要自己调索引参数

24G跑7B LoRA确实就是这个量级，我之前用4090试过，跟你配置差不多，显存大概21G左右，没爆但也很悬。你那个target_modules如果选了全部线性层，QKV和MLP都算上的话，参数量会明显上去，建议先只训q_proj和v_proj试试。另外检查下是不是把梯度检查点关了，那个能省3-4G，配合gradient_accumulation用就行。另外你seq_len从2048降到1024

这问题太典型了，我之前也是用固定256切chunk，后来发现合同这种格式文档，条款本身就自带语义边界，按段落或者条款号去切反而更准，不会把一条完整约定拦腰截断。另外reranker真的值得加，bge-large的向量召回只是初筛，用bge-reranker过一遍top20再取前5，准确率提升很明显。不过也别全依赖模型过滤，可以试下让LLM先判断每个片段和问题的相关性，再只基于高相关片段回答，能减少

这个视角确实挺有意思，尤其是“答案偏好稳定化时间”这个概念，让我想起之前做RLHF时，模型在长链推理里反复横跳的现象特别让人头疼。如果能定位到具体是哪个token之后偏好锁定了，感觉比单纯看最终logits靠谱多了，至少能帮我们区分是推理过程本身不稳定，还是最后一步输出层的问题。不过有个好奇的地方：这个方法对开放性生成任务（比如创意写作）也能适用吗？毕竟答案集不是有限的，稳定化的定义可能得换个思路