检索增强生成RAG实战：千问Embedding模型与向量库推荐

要在企业内部文档中精准调用千问模型回答问题，关键在于构建并打通“文档切分→向量编码→语义检索→上下文拼接→增强生成”的完整流程。任意一环出现断层，都容易引发答案偏差或来源无法追溯的问题。

用Qwen3-Embedding构建语义向量索引

这一步远非简单API调用，它决定了后续所有检索质量的基准。Qwen3-Embedding-4B堪称当前中文语义保真度最高的嵌入模型之一——在MTEB中文榜单上Recall@10达86.3%，明显领先于bge-small-zh的79.1%和gte-small的75.6%。

具体操作分四步：首先安装transformers和torch，确认CUDA是否可用。若没有GPU，需切换到cpu设备并开启flash_attention_2以提升推理速度。接着，从Hugging Face加载模型时必须使用配套tokenizer，混用其他分词器会引发向量漂移——这是个常踩的坑。然后对文本块进行批量编码，每块控制在300字左右，重叠区设为30字：过小会割裂语义，过大会造成冗余召回。最后，将生成的768维向量连同source、page_num等元数据写入ChromaDB，调用persist()落地为本地文件，避免重启后索引丢失。

选Embedding模型：看三组硬指标，不看排行榜名次

别被“SOTA”这类标签迷惑。真正决定业务效果的，是三个实测指标：向量维度、平均L2范数、Recall@5真实查询命中率。

轻量验证阶段可以用all-MiniLM-L6-v2，适合原型快速跑通，768维，单次编码耗时不到15毫秒（CPU）。但它的中文长句语义压缩较重，遇到像“年假审批需经部门负责人+HRBP双签”这类复合条件查询时，容易漏检“HRBP”这个关键词。

中文场景的强项选手是bge-m3，支持多粒度检索（dense/sparse/hybrid），对PDF中的表格文字、页眉页脚噪声鲁棒性强。不过需要额外配置rerank模块才能释放全部能力。

生产级首选还是Qwen3-Embedding-4B。其输出向量为1024维，L2范数集中在1.8到2.2区间，与Qwen3-4B-Instruct-2507的输入空间天然对齐——省去跨模型归一化步骤，直接复用同一套tokenizer，可减少3%以上的语义偏移。

向量数据库选型：按数据量和更新频率决策

Chroma是否够用？取决于实际场景。如果单机部署、日增文档不超过500份、无需权限分级、也不要求毫秒级扩容，那么Chroma完全胜任。

数据量在10万块以下时，直接用Chroma。零配置启动，一行代码即可初始化，插入吞吐可达1200 docs/s（RTX 3060）。但需警惕：超过20万块后，搜索延迟会陡增到800毫秒以上，此时必须切换到Milvus。

当数据量在10万到500万块之间时，应当选择Milvus 2.4。启用IVF_SQ8量化索引，nlist设为4096，内存占用比Chroma低47%，还支持按collection设置副本数。关键操作：建表时必须指定consistency_level="Strong"，否则高并发写入时可能丢失最新chunk。

若需要混合检索或细粒度权限，则必须上Weaviate。它可以同时挂载BM25关键词索引和向量索引，适合FAQ加技术手册的混合知识库；还支持RBAC权限模型，能精确控制某个部门仅可见其所属的项目文档。

把检索结果喂给千问模型生成答案

并非简单粗暴地将Top 3文档原文拼在一起即可。Qwen3-4B-Instruct-2507要求使用结构化Prompt，否则它会忽略context自行编造答案。

一种方法是借助LangChain的RetrievalQA链，设置retriever为ChromaVectorStoreRetriever(k=3)，然后传入自定义prompt：“你是一个严谨的知识问答助手，所有回答必须严格基于以下参考资料。若资料未覆盖问题内容，请明确回答‘未在知识库中找到相关信息’。”

更推荐手动拼接逻辑。将重排序后的每段文档用...包裹，插入到用户问题前面；调用model.apply_chat_template()时启用add_generation_prompt=True，确保生成起始token正确。

实际操作极其简便：直接将文件拖入即可完成拼接。

来源：互联网