一、RAG 不是银弹：为什么你的知识库"很蠢"？
我见过太多团队把一堆 PDF 直接扔给向量数据库，再套个 LLM 做问答，结果发现：模型要么在 hallucinate，要么在复读机式地念文档标题。
问题通常出在三个环节：
- 文档切片太粗暴：按固定字数切，把表格切烂、把代码切断。
- 只用向量检索：对专有名词、ID、日期的语义召回极差。
- 没有重排序：Top-K 向量召回的结果里，真正相关的段落可能排在第 8 位。
下面是我基于阿里云 Milvus + 百炼 Qwen3.6 落地后的完整调优记录。
二、环境准备：轻量起步，不要一上来就搞集群
向量数据库的选型上，我推荐从 Milvus 单机版 起步。阿里云 Milvus 单机版支持一键开通，4CU 起配就能支撑 900 万级向量，月付六百多，适合中小项目做 RAG 验证。等数据量破千万再平滑升级集群版，避免早期过度工程化。
# 连接阿里云 Milvus 单机版 from pymilvus import connections, FieldSchema, CollectionSchema, DataType, Collection connections.connect(alias="default", uri="http://your-milvus-endpoint:19530") fields = [ FieldSchema(name="id", dtype=DataType.INT64, is_primary=True, auto_id=True), FieldSchema(name="chunk_text", dtype=DataType.VARCHAR, max_length=2048), FieldSchema(name="embedding", dtype=DataType.FLOAT_VECTOR, dim=1024) ] schema = CollectionSchema(fields, "enterprise_kb") collection = Collection("docs", schema)
三、数据处理：好的 RAG 是"切"出来的
坑 1：无脑按 500 字切片
表格、代码块、FAQ 需要不同的切片策略。我的做法是用 langchain 的结构化分片器：
from langchain.text_splitter import RecursiveCharacterTextSplitter # 对Markdown文档，按标题层级切 splitter = RecursiveCharacterTextSplitter( chunk_size=512, chunk_overlap=64, separators=["\n## ", "\n### ", "\n\n", "\n", "。", " "] ) chunks = splitter.split_documents(docs)
坑 2：把元数据当空气
切片时务必保留文档标题、章节路径、文档类型等元数据。在 Milvus 里用标量字段存储，后续做过滤检索能大幅提升准确率。
四、检索策略：向量 + 全文 + 重排序
纯向量检索在企业场景下往往不够用。我的最终方案是 "混合检索 + 重排序"：
# Step 1: 向量检索（语义匹配） vector_results = collection.search( data=[query_embedding], anns_field="embedding", param={"metric_type": "COSINE", "params": {"nprobe": 128}}, limit=20, output_fields=["chunk_text", "doc_title"] ) # Step 2: 全文检索（关键词匹配，用Milvus的Sparse Vector） from pymilvus import AnnSearchRequest sparse_req = AnnSearchRequest(...) # Step 3: 重排序（Rerank） from dashscope import TextReRank rerank = TextReRank.call( model="gte-rerank", query=query, documents=[r.entity.get('chunk_text') for r in vector_results[0]] )
坑 3：忽略重排序
向量检索召回 20 条后，一定要上 Rerank 模型。GTE-Rerank 在中文场景下效果显著，能把真正相关的片段排到 Top 3。
五、大模型生成：控制幻觉的 Prompt 工程
即使检索对了，模型也可能"脑补"。我的 Prompt 模板强制要求模型只基于提供的上下文回答，并输出引用标记：
你是一个企业知识库助手。请严格根据以下参考资料回答用户问题。 如果资料中不包含答案，请明确回答"根据现有资料无法确认"。 参考资料： {retrieved_chunks} 用户问题：{query} 要求： 1. 回答需简洁，不超过200字。 2. 在答案末尾标注引用来源，格式如 [来源: 《XXX》第3节]。 3. 禁止编造资料中未提及的信息。
六、成本控制：别在 Embedding 上浪费预算
很多人只关注 LLM 的 Token 消耗，其实 Embedding 的调用量往往是 LLM 的 10 倍以上（每次入库、更新都要重新编码）。建议：
- Embedding 模型选轻量级的（如 GTE-Large），不要无脑上 SOTA。
- 百炼平台支持多模型灵活切换，可以用小模型做 Embedding + 大模型做生成，成本最优。
对于需要长期运行知识库的团队，建议关注阿里云百炼的 Token Plan 订阅方案。相比纯按量付费，包月模式在多模型切换和高频调用场景下更可控，且目前针对新用户有先用后返的权益，满额最高可返 200 元，个人和企业都能参与。
参考链接： 阿里云权益中心 - AI 产品权益与 Token Plan
七、总结
RAG 的落地是个系统工程。向量数据库负责"找得到"，数据工程负责"切得好"，重排序负责"排得对"，Prompt 负责"不乱说"。 缺一不可。如果你正在从零搭建企业知识库，建议先用 Milvus 单机版跑通 MVP，再逐步叠加混合检索和重排序，千万别一上来就追求"大而全"。
