用向量数据库做RAG，文本分段和embedding到底该怎么选？

按业务语义切分比死磕tokens数靠谱，bge-large对专业词弱建议微调或换m3e。

分段这事儿真不用死磕固定长度，我们之前试过按标题和段落切，效果比512硬切好不少，特别是长文档，检索出来的上下文连贯性明显提升。embedding模型的话，bge系列对专业术语确实有点吃力，可以试试混用，比如用bge粗召回，再用一个领域微调的小模型精排，成本不高但效果能拉起来。另外建议把PDF里的表格和页眉页脚先清洗掉，不然这些噪音很容易干扰向量化。你们现在检索结果里，是相关文档排不上去，还是排上去了但答案对不上？

分段按语义走，卡着标题和段落边界切，比死磕512靠谱多了，专业词不准试试混个rerank兜底。

分段别太死板，按语义段落切，再给每段补点上下文重叠，效果立马不一样。模型的话可以先试试混用bge-large和别的，对比检索结果再定。

分段这块我建议别用固定长度，按语义段落切会好很多，但前提是你得先清洗文档结构，不然PDF解析出来全是乱段落也白搭。可以试试先按标题和章节粗切，再对超长的段落实行滑动窗口重叠，这样检索时上下文能保留一部分。至于bge-large-zh对专业术语弱，其实可以加一层领域词典做查询改写，或者干脆用bge-m3，多语种和长文本支持都好些，就是资源占用大点。你那边文档里图表多吗？如果多的话，还得考虑把图表里的文字单独抽出来，不然检索容易漏。

分段这块我建议别死磕固定长度，按语义段落切会更稳，但得配合一个滑动窗口的overlap机制，比如段落之间保留个20%的重叠，这样既能保住上下文连贯，又不至于让embedding稀释掉关键信息。你那个上百页的PDF，最好先用标题或者章节结构做个粗切分，再对超长段落内部按句子边界二次切，不然直接硬切512 tokens很容易把表格或者列表拆得七零八落。

至于bge-large-zh，其实它本身对通用领域的中文语义还挺好的，但如果是垂直行业术语，比如医疗、法律或者你们公司的内部黑话，确实会力不从心。我有次做金融文档，也是感觉某些专业词汇检索出来牛头不对马嘴，后来换了bge-m3或者试了试OpenAI的text-embedding-3-large，效果明显好一些，不过后者成本也高。如果你不想换模型，可以试试在分段前做一层术语词典替换，把“净利润”这种词先统一成“净收益”，再喂给embedding，有时候能救回来不少。

另外Milvus这边还有个坑，就是检索的时候别只看向量相似度，最好加个BM25的混合检索，把关键词命中的段落权重提上来。我之前只靠向量召回，经常把相似但语义无关的段落排前面，后来加了Rerank，用bge-reranker-base过一遍，准确率直接涨了一截。你环境允许的话，强烈建议把这个流程加上。

不建议纯按固定长度切，之前我们试过512 tokens，结果很多段落被硬生生截断，检索出来经常是半截话。后来改成按文档标题和段落结构先粗切，再对超长段落按句子边界二次拆分，效果明显好多了。embedding这块，bge-large-zh对通用领域还行，但专业术语确实容易跑偏，可以试试把术语表或领域词典拼到上下文里再喂给模型，或者微调一下，比直接换模型成本低。另外检索完最好加个rerank环节，能救回来不少不相关的top-k结果。

分段这事我建议别用固定长度，先按文档结构切，再用滑动窗口做重叠，比如每段500字重叠100字，这样既能保住上下文又不会太碎。bge-large-zh对专业术语弱是正常的，可以试试在召回后加一层rerank，或者直接用bge-m3，多语言和长文本支持更好。另外你们内部知识库如果术语特别多，最好收集一些领域语料微调一下embedding，效果会提升很明显。

语义段落为主，超长再按512切，重叠设128，bge换bge-m3会好不少。

分段别死磕固定长度，按语义块切，再配合重叠窗口召回，效果立竿见影。bge对专业术语确实弱，试试混用BM25补召回。

分段按语义走，嵌模型换bge-m3试试，专业词得加词典或微调才靠谱。

我之前也踩过这个坑，固定长度分段确实省事但检索效果飘忽，后来改成按标题和章节切，再给每段补个上下文摘要，效果稳多了。embedding这块，bge对专业术语弱是正常的，建议试试在切分时把术语和缩写单独抽出来做成关键词索引，跟向量检索做混合召回。另外你们文档量级多大？如果过十万级，Milvus的索引参数也得调，不然召回延迟会很难看。

分段按语义走，重排加个rerank能救不少，bge换bge-m3试试。

固定长度切真的坑，上下文碎了检索出来没法看，建议先粗切再按标题合并。

分段别死磕固定长度，先按章节语义切，再对超长段二次切分，效果立现。模型换bge-m3试试，专业词理解比large强不少。

这个坑我太熟了，我们之前也是拿Milvus做企业知识库，一开始固定512切，结果检索出来的片段经常一句话说到一半就断了，后来换成语义段落为主、长度兜底的策略，就是先用标题和段落边界切，超过设定上限再强制截断，效果好了不少。关于embedding，bge-large-zh确实对通用领域好，但专业术语你得考虑微调或者混合检索，我建议你保留向量检索的同时加一个BM25的关键词召回，然后把两者结果做融合，很多专业名词靠向量真的容易跑偏。至于模型，如果不想折腾微调，可以试试bge-m3或者最近那些支持长文本的模型，但对内部术语，可能得自己准备一些同义词或知识增强的预处理，比如把文档里的缩写和全称先映射一下。还有个细节，分段的时候把段落标题或者文档名作为元数据存进去，检索后返回时带上这个上下文，能明显缓解“上下文不完整”的问题。另外，建议你先抽一小批典型query做人工评测，跑通后再规模化，别一上来就追求完美方案，RAG的调优真的得靠迭代。

我们之前也踩过这个坑，最后是混合用的：先按文档结构切出语义块，再对超长的块按400-600 token二次切分，同时保留段间重叠。另外bge-large-zh确实对专业领域词表覆盖一般，建议先在领域语料上做增量预训练，或者试试bge-m3，多语言和长文本支持会好一些。

分段建议按语义走，可以设个上下限兜底，专业术语那事儿换bge-m3或干脆加词典扩充试试。

说实话你这俩问题我全踩过，尤其分段这个事儿，固定长度512token做企业文档真的不太行，PDF排版乱起来经常把一句话砍成两半，检索出来上下文全断。我现在的做法是先用layout识别把标题和段落结构抽出来，再结合标题层级去切，每个块控制在200-400token左右，太长的段落再按句号或者换行硬拆，这样召回率明显比纯固定长度稳。至于embedding，bge-large-zh对通用语料还行，但专业术语确实容易懵，我试过拿领域语料微调bge，效果提升不少，但成本高。另一个偷懒的办法是混合检索，把BM25和向量结果做rerank，术语模糊时关键词能兜底。你如果不想太折腾，可以先试试把段落切小一点，然后检索时把相邻几个块一起返回，再让LLM自己拼上下文，这招对长短混合文档挺管用的。模型的话，最近看社区有人拿Qwen3-Embedding替换bge，说术语理解好一些，你可以小批量测测对比下。

分段建议按语义块来，别死磕固定长度，专业术语不准可以试试混用bge-m3或者重排模型兜底。

分段这事真没有标准答案，我试下来按语义段落切，再给每段补个上下文摘要，效果比固定长度稳多了。
模型的话bge对垂直领域确实一般，可以试试混用粗排+精排，或者微调一下，别急着换大模型。