千问怎么实现检索增强生成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。

如果需要混合检索或细粒度权限，那就得上Wea viate。它可以同时挂载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正确。

这一步操作起来其实很简单，直接把文件拖进去就行。