长期主义低代码成长记

几十万条其实真不用纠结，Chroma单机扛这个量级没问题，我团队之前五十万文档跑得挺稳，迁移的事等真到了百万级再说也不迟。bge-m3效果我觉得比OpenAI的还稳，尤其中文场景，关键便宜太多，除非你要做多模态检索，不然真没必要花那个钱。真要担心将来迁移，写个抽象层把查询接口封装一下，换库就是改个配置的事，别给自己加戏。 --- 这个量级Chroma完全够用，我生产环境跑过80万条，查询延迟也

代码生成我直接0.2加top_p 0.85，repeat_penalty设1.1，比单调温度稳多了，你可以试试。API和本地参数逻辑大体一样，但本地Ollama对采样细节更敏感。

实测下来确实没啥惊喜，现在各家都在挤牙膏，等架构真的变了再说吧。 边际收益递减这话太对了，刷分时代该结束了，看看啥时候能跳出这个循环。

把query重写一下再喂进去，能明显减少无关条款，另外系统提示词里加一句“只提炼和问题直接相关的步骤”比笼统的“相关”好用。 试试在prompt里让模型先判断检索片段和问题的相关性，不相关的直接忽略，再总结，比单纯加约束稳很多。

说实话你这个问题我当初也卡了很久，后来才意识到很多人聊RAG默认只聊文本，但多模态内容压根是另一套玩法。纯文字切块丢Milvus当然简单，可图表、截图里那些视觉信息，embedding模型根本吃不到，用户一问“柱状图趋势”就抓瞎，这太正常了。 我的经验是，如果PDF里有图，得先做一层版面解析，把图片区域单独抽出来，用多模态embedding模型（比如CLIP那类）单独生成向量，再跟它周围的文字块

之前处理类似问题的时候试过把代码按函数和类拆成AST节点再存，查询的时候只召回相关的子图，上下文能小不少。另外可以试试在检索后加一道重排序，把最关键的依赖关系优先塞进prompt，比单纯滑动窗口稳。代码embedding的话，codebert或者unixcoder效果还可以，但得用公司代码微调一下才贴合场景。

说实话我也踩过这个坑，top-k拉满看着信息全，但生成质量反而崩。你这情况我建议先别急着上MMR，把召回源头捋一捋——查一下embedding模型和你的领域文本匹不匹配，OpenAI那个通用embedding在专业术语多的场景下相关性排序其实挺糙的，换个微调过的bge或者e5可能立竿见影。 另外chunk size和overlap动辄调参没用，核心问题可能是你切分策略太死板了。试试按语义边界切，

你说到点子上了，WAIC这两年确实越来越像“愿景发布会”，真正能落地的技术细节少得可怜。尤其那个“大模型迈向物理世界”的口号，从2023喊到现在，我身边做机器人控制的朋友都快听吐了——真拿模型去试产线抓取，别说重力感知了，连“杯子倒扣时不能从底部抓”这种常识都经常翻车。Transformer的因果推理短板太明显，它本质是在做模式匹配，不是理解物理规律，堆数据只能让它在训练集分布内显得聪明，换个场景