大模型应用开发：RAG实现与实际落地经验

最新推荐文章于 2025-06-25 18:26:28 发布

我爱学大模型

最新推荐文章于 2025-06-25 18:26:28 发布

阅读量880

点赞数 16

CC 4.0 BY-SA版权

文章标签：人工智能 AI大模型什么是大模型大模型应用大模型开发 RAG 大模型应用开发

本文链接：https://blog.youkuaiyun.com/python1234_/article/details/146039094

今天想聊聊最近两年我在几个项目中实践RAG（检索增强生成）的一些心得。坦白说，当初看到OpenAI发布GPT系列模型时，我和很多人一样兴奋得睡不着觉，仿佛看到了新一代应用开发的曙光。但实际落地过程中才发现，理想很丰满，现实很骨感。尤其是当我们希望大模型能够基于企业内部知识来回答问题时，各种挑战接踵而至。

RAG是什么，为什么我们需要它？

简单来说，RAG就是在大语言模型生成回答前，先检索相关知识，然后将这些知识作为上下文提供给模型，以生成更准确、更可靠的回答。

为什么需要RAG？主要有这几个原因：

知识时效性：无论是GPT-4还是国内的文心一言，训练数据都有截止日期，对新信息一无所知
专有信息：企业内部文档、产品手册等专有信息，模型根本没见过
减少幻觉：给模型提供可靠信息源，大幅降低"胡说八道"的几率
可控性：通过控制检索内容，间接控制模型回答的方向和范围

我记得去年给一家制造业客户做知识库问答系统时，他们CEO测试了一个关于公司最新产品参数的问题，结果模型自信满满地给出了完全错误的答案。那一刻，我看到CEO脸上的表情从好奇变成了怀疑，差点让整个项目泡汤。这就是为什么RAG如此重要。

RAG的基本架构

一个典型的RAG系统包括这几个核心组件：

文档处理管道：负责摄取、清洗和分块文档
向量化模块：将文本转换为向量表示
向量数据库：存储和索引文本向量
检索模块：根据查询检索相关文档
提示工程模块：将检索结果与用户问题组合成提示
LLM接口：调用大语言模型生成最终回答

看起来很简单对吧？但魔鬼藏在细节里。

实战踩坑与解决方案

1. 文档分块策略

最开始我天真地认为，把文档按固定字符数（比如512字符）切分就完事了。结果发现这种方式会把语义完整的段落生硬切断，导致检索效果极差。

解决方案：我现在采用多级分块策略：

def hierarchical_chunking(document):
    # 第一级：按章节分块
    chapters = split_by_headers(document)
    
    chunks = []
    for chapter in chapters:
        # 第二级：按段落分块
        paragraphs = split_by_paragraphs(chapter)
        
        # 第三级：处理过长段落
        for para in paragraphs:
            if len(para) > MAX_CHUNK_SIZE:
                # 使用滑动窗口，保留上下文重叠
                sub_chunks = sliding_window_split(para, 
                                                 window_size=MAX_CHUNK_SIZE,
                                                 overlap=100)
                chunks.extend(sub_chunks)
            else:
                chunks.append(para)
    
    return chunks

另外，我发现保留文档的层级信息对后续检索非常有价值。比如在一个API文档中，知道这段文本来自"认证模块"的"错误处理"部分，比单纯的文本块要有用得多。

2. 向量化模型选择

这块踩过的坑太多了。一开始为了省事，直接用了OpenAI的embedding模型。结果某天API突然不稳定，整个生产系统就歇菜了。

后来转向开源模型，试了好几个：

text-embedding-ada-002：效果好但依赖OpenAI
BAAI/bge-large-zh：中文效果不错，但资源消耗大
sentence-transformers/all-MiniLM-L6-v2：轻量级选手，速度快但效果一般

最终在生产环境，我们采用了混合策略：

class HybridEmbedder:
    def __init__(self):
        # 主力模型
        self.primary = SentenceTransformer("BAAI/bge-large-zh")
        # 备用轻量级模型
        self.backup = SentenceTransformer("sentence-transformers/all-MiniLM-L6-v2")
        
    def embed(self, text, use_primary=True):
        try:
            if use_primary:
                return self.primary.encode(text)
            else:
                return self.backup.encode(text)
        except Exception as e:
            logger.error(f"Embedding failed: {e}")
            # 失败时降级到备用模型
            return self.backup.encode(text)

这样既保证了效果，又提高了系统弹性。

3. 向量数据库的选择

我先后尝试了Pinecone、Milvus、Qdrant和Faiss。说实话，各有千秋：

Pinecone：开箱即用，但价格感人
Milvus：功能全面，但部署复杂
Qdrant：平衡了易用性和功能性
Faiss：轻量高效，但功能相对简单

对于初创公司，我通常推荐Qdrant，它提供了Docker部署方式，上手容易：

docker run -p 6333:6333 \
    -v $(pwd)/qdrant_storage:/qdrant/storage \
    qdrant/qdrant

对于特别关注成本的项目，Faiss+自建索引管理也是不错的选择：

import faiss
import numpy as np

class SimpleVectorDB:
    def __init__(self, dimension):
        self.index = faiss.IndexFlatL2(dimension)
        self.texts = []
        
    def add(self, vectors, texts):
        self.index.add(np.array(vectors, dtype=np.float32))
        self.texts.extend(texts)
        
    def search(self, query_vector, k=5):
        distances, indices = self.index.search(
            np.array([query_vector], dtype=np.float32), k
        )
        return [(self.texts[idx], distances[0][i]) 
                for i, idx in enumerate(indices[0])]

不过随着数据量增长，这种简易方案很快会遇到瓶颈。

4. 混合检索策略

单纯依赖向量检索是不够的，尤其是处理专业领域问题时。我现在采用的是混合检索策略：

def hybrid_search(query, top_k=5):
    # 1. 关键词检索（BM25）
    keyword_results = bm25_search(query, top_k=top_k*2)
    
    # 2. 向量检索
    query_embedding = embedder.embed(query)
    vector_results = vector_db.search(query_embedding, top_k=top_k*2)
    
    # 3. 结果融合（简单的按分数归一化后加权）
    combined_results = combine_search_results(
        keyword_results, vector_results, 
        keyword_weight=0.3, vector_weight=0.7
    )
    
    return combined_results[:top_k]

这种方式既能捕获关键词匹配，又能理解语义相似性，大幅提升了检索准确率。

5. 提示工程的艺术

最初我天真地以为，把检索结果直接塞进提示模板就完事了：

基于以下信息回答问题:
{retrieved_docs}

问题: {query}

结果发现问题一大堆：

模型会忽略部分检索内容
回答中混入了不相关信息
模型不确定时会"编造"答案

经过无数次调优，我现在的提示模板变成了这样：

def create_rag_prompt(query, retrieved_docs, metadata=None):
    # 格式化检索文档，添加来源信息
    formatted_docs = []
    for i, (doc, score) in enumerate(retrieved_docs):
        source = metadata.get(doc, "未知来源")
        formatted_docs.append(f"[文档{i+1}] (来源: {source})\n{doc}\n")
    
    context = "\n".join(formatted_docs)
    
    prompt = f"""你是一个专业的知识助手。请基于提供的参考文档回答用户问题。

参考文档:
{context}

重要说明:
1. 仅使用参考文档中的信息回答
2. 如果参考文档中没有相关信息，请直接说"抱歉，我没有找到相关信息"
3. 不要编造信息或使用你自己的知识
4. 引用信息时，请标明是来自哪个文档
5. 回答要简洁、准确、全面

用户问题: {query}

回答: """
    
    return prompt

这个提示模板有几个关键点：

明确指示模型仅使用提供的信息
要求标明信息来源，增强可追溯性
给出明确的"不知道"策略，避免编造
设定回答风格和格式要求

6. 评估与迭代

RAG系统不是一次性工作，而是需要持续评估和优化的。我建立了一套评估框架：

def evaluate_rag_system(test_cases, system):
    results = []
    for case in test_cases:
        query = case['query']
        ground_truth = case['ground_truth']
        
        # 获取系统回答
        response = system.answer(query)
        
        # 评估指标
        retrieval_precision = evaluate_retrieval(
            system.last_retrieved_docs, ground_truth
        )
        answer_relevance = evaluate_answer_relevance(
            response, ground_truth
        )
        factual_accuracy = evaluate_factual_accuracy(
            response, ground_truth
        )
        
        results.append({
            'query': query,
            'response': response,
            'retrieval_precision': retrieval_precision,
            'answer_relevance': answer_relevance,
            'factual_accuracy': factual_accuracy
        })
    
    return results

通过这种方式，我们可以量化系统的表现，并有针对性地改进薄弱环节。