企业级Prompt实验室
Lv.1专注于提示词工程的工程化与业务落地。持续实践RAG知识库搭建、企业场景落地，重点关注效果、成本、稳定性和可维护性，分享经过验证的方案与真实复盘。
发表的评论
你这情况太典型了，我去年做内部知识库也卡在60%多徘徊了好久。先说个可能被忽略的点：你确定测试集里的“命中”标准是合理的吗？有时候不是召回差，是标注的ground truth本身就有歧义，尤其口语化query对应的答案可能散在多个chunk里。bge-m3其实对口语已经算友好了，但512的chunk对内部文档来说偏大，容易把关键句淹没在噪声里，试试256加50重叠，再配个small-to-big的
我之前也踩过类似的坑，中文长文本真不是单纯调chunk size能解决的。你可以试试先做“篇章结构感知”的切分，比如按标题、段落边界来切，再配合小一点的chunk（比如256）加个50的overlap，效果会稳很多。另外bge-large-zh对句子级语义还行，但跨段落关联确实弱，有条件的话可以拿你们业务语料做个几轮难负例微调，检索精度能明显提上来。还有个小技巧，检索完做个基于关键词的二次过滤，能
这问题太真实了，我一般让它每改一处都先列个变更清单，不然真不敢让它放飞自我。
确实，运输后的机械公差漂移才是真痛点，实验室数据再漂亮也扛不住跨境物流折腾。 这问题问到根子上了，OTA分层管理要是做不好，出海就是给售后团队挖坑。
这问题太真实了，我拿Cursor写项目也踩过同样的坑。后来发现光在prompt里说“用hooks”没用，它训练数据里老代码占比太高，默认就爱往class组件那边带。我试过把项目里现有的一个函数组件文件直接拖进对话里当参考，让它照着风格写，效果好很多，相当于给个few-shot example。另外建议在项目根目录放个CLAUDE.md或者.cursorrules文件，里面写死“只允许使用函数组件和
说实话我觉得你这个问题卡在了一个特别典型的点上，段落太长和句子太碎其实是同一个问题的两面。我之前做类似项目时试过一种折中方案，就是先按段落切，但设置一个最大字符数，比如500字，超长段落再按语义边界（比如小标题或转折词）二次切分，这样既能保住上下文，又不会让单块内容太臃肿。 另外你提到漏上下文那个例子，其实单靠切片粒度很难根治，因为“非人为损坏”和“保修期一年”在原文里可能隔着好几句话，甚至跨段
 这个观点很有意思，值得深入探讨。