深度学习笔记

我之前也踩过这个坑，后来发现别死磕chunk size，先看文档结构。Markdown本身有标题层级，直接用markdown header做切分比固定大小稳得多，代码块和正文分开处理效果会好很多。 overlap其实不用太纠结，10%左右够用了，真正影响大的是检索策略，比如先按标题粗筛再细切，或者用父子chunk。你可以试试把table、代码单独拎出来，这样混合内容时互相干扰会少很多。 另外建

说实话你这情况挺常见的，LoRA微调本来就更偏向改变生成风格和指令遵循能力，对检索环节的改善非常有限。我试过在训练数据里把检索到的chunk和问题拼接时加个特殊分隔符，比如[RETRIEVED]这种，效果比单纯问答对要好一些。另外你只训了3个epoch，1000条数据对LoRA来说可能真不够，而且学习率3e-4偏保守，可以试试1e-4加更多步数。还有个思路是微调embedding模型而不是LLM，

试过tree-sitter做AST切分，确实比固定行数强太多。Python和Go的语法树都支持得很好，按函数、类、方法边界切，检索出来的片段基本就是完整逻辑块。不过有个坑，AST切分出来的chunk大小差异很大，小函数可能才几十行，大模块一个就上千行，embedding的时候要么截断要么补padding，反而影响检索质量。后来我是折中了一下，用语法树先定位边界，再根据token数限制做合并或拆分，

说实话500条数据训7B确实有点少，LoRA再省显存也扛不住这么点样本量，loss震荡太正常了。另外你那个格式太裸了，至少得套个chat模板或者alpaca的格式，不然模型根本不知道你输入输出边界在哪，特殊token还是有必要的。学习率3e-4对LoRA来说偏高，降到1e-4或者5e-5试试，我调的时候发现低学习率配合多跑几个epoch反而更稳。建议先拿这500条过拟合一下看看能不能降到0.3以下

试试把表格区域单独检测出来转成图片，用OCR带坐标信息输出，再按坐标重构成结构化数据，这个方案比纯文本解析稳很多。跨页表格可以加个页眉页脚识别，把表头重复标记一下，检索时按表格ID分组处理。unstructured其实没那么重，部署也就一个Docker容器，只是文档里表格样式太乱的话效果会打折。另外如果表格是扫描件，那真不如直接走多模态，轻量方案可以试试PaddleOCR-VL，中文表格效果还不错

几十万条分片这量级Chroma确实有点吃力了，尤其你本地跑Qwen2.5，索引全在内存里吧？我试过类似配置，最后是换了Qdrant，单机docker起个实例就行，不用etcd那套，而且自带filter和payload索引，召回率比Chroma稳不少。不过你要是想完全省事，先试试给Chroma的collection换掉默认的HNSW参数，比如把efConstruction调高到200，M调到32，可

固定512切确实太粗暴了，技术手册里代码块和正文混着，语义早被切碎了。我建议你先用unstructured或者markdown解析器把文档按标题层级拆成“章节块”，代码和表格单独拎出来用更小的块存，别跟正文混在一起。另外bge-m3对长文本效果一般，可以试试把每个章节块再按段落二次切分，召回时用重排模型过滤一下，比纠结切法管用多了。

说实话我最近也踩过类似的坑，polars和duckdb其实性能确实比pandas强，但如果你队友不熟这些库，维护起来确实想骂人。我的办法是在提示词里直接写“只允许使用pandas和re处理，不要引入其他第三方库”，然后加上“保持代码风格与现有项目一致”。另外建议你装个pip-audit或者让Cursor解释每个库的用途，确实有用再留，不然就手动删掉重跑一遍。

“撤销”和“版本回退”这块我实测过，它确实会记住对话里的修改节点，但如果你中途插入了别的指令，再回退到很早的版本，画布状态和上下文就容易对不上，得手动点好几次才靠谱。你说的全局风格迁移偏差太真实了，感觉它把“调暖”理解成了单一色相变化，对组件级联动的参数映射还是弱了点，估计训练数据里这类复合指令占比不够。话说你们团队有没有试过给它加个“风格锚点”的自定义层，强制锁定阴影和描边的参数范围？我最近在这

说实话你的问题很可能不在TopK本身，而是切分粒度和检索策略的匹配。300-400字对BGE-base来说已经偏长了，很多语义信息被稀释在段落里，TopK=5漏掉的是分散在多个片段里的关键证据，TopK=20又必然引入噪声。我建议你先试试把文档切到200字左右，重叠提到80，很多情况下召回质量会明显改善。 然后关于阈值，你说得分分布不稳定，这太正常了。不同查询的语义密度本来就不一样，固定阈值肯定

说实话我觉得这个判断挺准的，人形机器人现在最缺的还真不是技术demo，而是让普通人愿意掏钱的场景。速卖通那套全球履约网络确实能帮MagicBot快速试错，但消费级用户买回去大概率是当玩具或者摆件，技术含金量反而被稀释了。我倒好奇他们怎么解决售后和内容生态，毕竟机器人不是手机，坏了不能光靠寄回去修。

4张80G跑推理稳的，微调确实得翻倍，预算不够就量化加LoRA凑合。

这问题太典型了，我之前做客服问答也栽过。试试在第二轮把历史query和当前问题拼接成一个新检索词，或者干脆对第一轮的答案做实体抽取，拿“材料”去过滤检索结果。另外给检索回来的chunk加个时间戳或主题标签，合并前按相似度去重，能压掉不少“串味”的段落。 还有个土办法，把多轮历史单独存个buffer，生成时只让LLM看第一轮答案的摘要，不直接拼原始检索文本，能少点混乱。你用的LangChain有现

说实话你这直觉挺对的，Prompt模板放前端基本就是给自己埋雷。先不说Token计算不一致这种技术问题，光是模板里的角色设定和few-shot示例被用户扒出来，你的整个系统逻辑就裸奔了，更别说有人能直接改JS绕过你的计费或者权限控制。我这边之前做过类似的知识库项目，后端把模板和动态上下文拼好，只把最终要发给模型的那段字符串传出去，前端要预览流式输出就直接拿这个字符串配合SSE流做渲染，完全不需要知

说实话你这情况我太熟了，之前搞法律条文检索也栽过一模一样的坑。固定512无重叠切块对合同文本来说确实太粗暴了，条款和定义经常被拦腰截断，语义完整性直接没了，我建议先试试按段落和条款边界去切，哪怕长度不统一都行。Embedding方面，BGE和text2vec对通用中文还行，但合同里大量专业术语和长句逻辑，它们的向量空间可能根本没学好这种分布，有条件可以对比下m3e或者干脆微调一个领域模型。实体识别

说实话你遇到的这个情况太典型了，我觉得问题真不全在prompt上。模型对“重构”的理解就是基于它见过的海量代码模式来套模板，它压根没真正理解你项目里的事务边界和表关系。我试过把相关表结构和函数实现直接贴进上下文，让它分步改，效果会比一次性给个大任务好不少。另外像这种涉及架构变动的活儿，我基本只让它产出单点修改的diff，然后自己来拼装整体逻辑，这样review压力小很多。

3070跑7B确实悬，量化后速度和质量都崩很正常，建议试试5B或3B的模型，8G显存能舒服不少。

工具调用这块确实稳多了，不过30%那个数我也持保留态度，感觉评测样本还是偏少。

这精度掉得有点多，不太像纯量化问题，opset 11的话BatchNorm和AdaptiveAvgPool一般不会这么伤。建议先排查一下模型里有没有动态shape或者自定义op，用onnxruntime的graph优化开关试试，还有检查下预处理（mean/std）在转换时有没有被固化错。移动端部署的话这个精度肯定不能接受，但也不一定非要TFLite，可以先试下onnxruntime的mobile

说实话你这个问题我太熟了，之前用7B做垂直域也踩过一模一样的坑。5000条数据其实不算少，但关键看你这数据是不是“干净”到能让模型学到意图边界，错别字被学进去基本就是数据里太多噪声了，清洗的时候得把用户口语里的重复词、无意义语气词都处理掉，不然LoRA会把它们当成特征。还有啊，你直接拿Instruct版本做LoRA其实没问题，但7B这种规模对指令格式的敏感度很高，我建议你先拿1000条高质量数据做