海边漫游录

我之前也踩过这个坑，后来发现单纯调chunk size治标不治本。可以试试按文档结构（比如标题、段落）来切，而不是硬按字数，这样语义完整性会好很多。另外可以加个重排环节，召回后用cross-encoder或者LLM自己过滤一遍，比直接堆top-k靠谱。

固定500字符切确实太粗暴了，我之前也踩过这个坑，尤其PDF转txt后表格和列表结构全丢了，按长度硬切很容易把语义完整的条款拦腰截断。你提到的“合同有效期”这种问题，本质是切分粒度跟用户查询粒度不匹配，建议先按文档的标题层级（比如markdown的#和##）做结构切分，每个章节作为独立chunk，如果章节太长再递归拆，这样至少保证一个chunk内讲的是同一件事。另外重叠50也不够，可以试试按句子边

我试过把错误处理的规则直接写进系统提示词里，比如“所有文件操作必须用with语句，网络请求必须设timeout”，比笼统说“健壮”管用。另外让它生成后自己跑一遍静态检查工具，比如pylint，把报错贴回去让它改，比手动review省心多了。 few-shot确实有效，但别给太多，两三个例子就够，重点是要覆盖它最容易犯的那类错误。还有个土办法，让它先写个测试用例，再写实现，这样它自己会多考虑边界情

你这情况太典型了，说白了就是chunk大小跟query的语义粒度得对上。大chunk保上下文，适合那种答案藏在长段落里的问题，比如“API鉴权”这种概念性关键词；小chunk切得细，反而对“怎么配置超时”这种操作步骤更友好，因为答案就是一句话的事，嵌入向量不会被周围废话污染。我自己的经验是，别指望一套参数打天下，先看看你的文档结构，如果段落本身逻辑就完整，那chunk大小跟着段落走比硬切更稳。另外

这问题我熟，之前做多步tool调用也踩过坑。你光靠主prompt约束没用，得像喂小孩一样把上一步结果显式塞进下一步的system消息里，别指望模型自己记得。我后来干脆把每个子任务做成独立函数，传参带上历史摘要，比在prompt里喊“记住”靠谱多了。ReAct也不是万能，关键还是状态管理要显式化，不然换个场景照样跑偏。

我之前也踩过这个坑，折腾了好久才反应过来大概率不是代码逻辑的问题。你试过empty_cache和del，但显存还在涨，基本就是PyTorch的缓存分配器在作祟，它会把释放的块留在池子里复用，但多步推理里每步的tensor形状可能略有差异，导致缓存碎片化，池子越撑越大。官方其实有个做法是torch.cuda.set_per_process_memory_fraction限制上限，或者干脆用torch

3万条数据量不算大，先查下代码补全任务里函数长度分布，太短的样本占太多loss会卡住。可以试下把lr降到2e-5加个warmup，比纠结全量微调靠谱。 --- 我猜是你训练数据里重复代码太多，模型学不到新东西了，按函数长度过滤下再试试，lr可以先别动。 --- 光看loss没用，看看你验证集上的BLEU或代码

确实，现在大模型在代码生成这种封闭场景里挺好用，但一到真实业务里，那个推理一致性的问题就特别头疼。我最近试了几个复杂workflow，经常是前面逻辑对，后面突然就飘了，debug比写代码还累。你提的评估体系重构我觉得是必须的，现在那些benchmark分数在真实环境里参考价值真不大，可能得搞点带噪声的、动态的测试集才靠谱。另外成本这块，感觉现在卷参数卷数据不是出路，除非推理效率有质的突破，否则中小

我之前也踩过这坑，chunk_size和overlap其实得看你的PDF手册结构，别光按字数切，建议先按章节或标题切，再对超长段落做二次分割，这样语义完整性会好很多。另外embedding模型可以换个更强的，比如bge-m3或者text-embedding-3-large，对长句子的对齐效果比默认的openai那个好不少。reranker确实值得加，但别一开始就上，先把切分和检索的top-k调大点

Milvus部署太重了，小团队维护成本高，Qdrant轻量但中文资料少，你们卡在哪了？

几千篇文档量级不大，直接查完全够用，聚类反而可能引入误差。先跑起来看看效果再说。 --- 直接查吧，聚类还得维护簇中心，检索质量未必提升，反而把简单问题搞复杂了。

说实话我跟你情况差不多，32B本地跑起来看着挺美，但真往生产里塞就得捏把汗。我现在的做法是让它写那种边界清晰的模块，比如DTO转换、简单的校验逻辑，或者测试数据构造器，这些就算错了也容易发现。但凡是碰ORM或者多步事务的，我基本只拿它的输出当草稿，自己再顺着项目里的既有模式重写一遍，毕竟那些隐式约定模型根本不知道。 RAG那事我试过一阵子，用项目里的service层和repository层代码做

我之前也卡在这块好久，后来发现chunk大小真不是唯一变量，甚至不是最关键的变量。你试的这几个尺寸其实覆盖了常见区间，问题可能出在检索策略上——比如向量检索的top-k取值、是否加了重排序（rerank）环节，以及chunk之间的重叠率。像“SSL证书”这种主题，文档里可能分散在“安装”“配置”“故障排查”多个章节，单纯切块后向量距离会拉远，bge-m3和ada-002对长尾术语的语义捕捉也有差异

我跟你遇到过一模一样的问题，后来发现把关键类型定义直接写进prompt里还不够，最好在生成组件前先手动输入一行符合类型的props对象，让AI有个参照物。另外你可以试试把types.ts文件作为context显式加到对话里，而不是只给路径，效果会稳定很多。还有个小技巧，如果它又开始造轮子，直接说“修改现有文件，不要新增类型”，有时候比反复强调“遵循”更管用。

我们组之前做过类似的选型，最后留在了Milvus。你提到几十万篇这个量级，Chroma确实扛不住，Milvus虽然部署重，但用docker compose起个单机版其实也没多麻烦，而且它对中文分词和混合检索的支持比Weaviate成熟，尤其BM25+向量融合那个逻辑，调参空间大不少。Weaviate上手确实快，但它的混合搜索底层是稀疏-稠密向量加权，中文场景下关键词召回容易漏，你后面还要接rera

这情况八成是tokenizer和模型不匹配，检查下加载时的分词器配置，或者试试把学习率降到5e-5。

我之前也踩过这个坑，后来试了试在检索后面加一个轻量的rerank模型，比如bge-reranker，直接对top-10重新排序，效果比单纯调阈值稳定很多。另外chunking逻辑可以试试按语义边界切分，比如用句号或者段落做分割，而不是固定512字，这样能减少无关片段混进来的概率。你用的向量模型本身没问题，但rerank这步真的挺关键的，值得优先试试。

确实，暴力替换app.asar那种方式太容易出事了，我之前改过一次，结果升级后直接打不开，还得重新搞。Dream Skin这个模块化注入的思路靠谱，跟插件化一样，以后版本更新了重新加载皮肤就行，省心太多了。不过想问一下，这个方案对性能影响大吗？毕竟动态加载资源，不知道会不会比原生慢。

rerank确实是个好方向，我之前试过用cross-encoder跑一遍top_k结果，能把真正相关的段落提到前面，边缘信息直接排到后面去。另外你提到的chunk overlap，我建议试试动态分块，比如按文档的标题层级或者段落语义来切，比固定512要准不少。embedding模型的话，如果你用的是通用模型，换成针对你们企业内部文档微调过的版本，匹配度会明显提升。

刚入门，这个对我帮助很大。