先说结论：用RAG搭建一个Demo原型确实不算困难，但真要将其部署到生产环境，各种挑战会接踵而至。这篇文章重点讨论三个最典型的生产落地难题，并给出相应的解决思路。
一、用户查询不规范怎么处理？
生产环境中的用户查询千奇百怪，很多人开口就是“推荐酒店”、“苹果的好处”，甚至只输入两个字——“足球”。这类短Query、模糊Query对RAG系统的检索能力构成了严峻考验。
通常有三种应对策略可供选择。
1. 意图识别分析
首先明确用户意图，缩小召回范围，再进行检索。具体实现方式有以下四种：
a. 基于规则或关键词，利用正则表达式做匹配。这种方法简单直接，但随着规则数量增加，维护成本会急剧上升。
b. 使用经典小型模型进行分类，例如Naive Bayes或BERT。你需要预先训练一个分类器，然后对每条查询进行意图判断。下面是BERT分类的伪代码示例：
# BERT分类训练示意
from transformers import BertForSequenceClassification
model = BertForSequenceClassification.from_pretrained('bert-base-uncased')
# 训练流程略...
c. 执行Query相似性检索。将预定义的意图转化为向量，用户查询进来后同样做向量化处理，再通过相似度匹配找出最接近的意图类别。
d. 直接让LLM承担这个任务。编写一个Prompt，将意图分类的工作交给大模型，同时可以把用户的历史对话一并提供，准确率往往更高。例如：
You are an advanced AI language model tasked with identifying the intent behind user queries. Given a user input, you need to classify the intent into one of the predefined categories.
## Categories
1. Fruit: ...
2. Technology: ...
3. Entertainment: ...
4. Sports: ...
5. Other: ...
## Example
User Input: "How many calories are in an orange?"
Historical Context: "Give me some low-calorie fruits."
Identified Intent: Fruit
## Now it's Your Turn
User Input: {user_input}
Historical Context: {historical_context}
Identified Intent:
一旦确定意图范围，检索知识库的规模就能缩小，那些容易产生混淆的查询自然减少了干扰。
2. 关键词抽取
直接提取查询中的核心关键词，然后基于关键词进行检索。方法同样有三种：
a. TF-IDF。先分词、去除停用词，再计算每个词的IDF和TF-IDF分数，按分数排序后，排名靠前的即为关键词。
b. 使用KeyBERT这类现成模型，直接提取关键词列表，省时省力。
c. 借助LLM提取关键词。流程如下图所示：
关键词检索可以与普通检索结合，之后统一进行重排序，效果往往更佳。
3. 澄清与追问
与其猜测，不如直接向用户发问。例如用户询问“苹果的好处”，系统可以反问：“您指的是水果苹果，还是科技公司苹果？”
这种策略在查询极度模糊时尤为有效。传统做法是：先识别模糊点（可通过关键词提取或意图分析），然后用预定义模板或生成式回复来追问，待用户回答后继续处理。而使用LLM时，只需在Prompt中增加一句提示：“如果你无法根据知识回答用户，可以向用户追问，但最多问4个问题。”
当然，这三种方法并非互斥。意图分析可以借助关键词提取来补充，澄清追问也能与意图分析配合使用。
二、结构化数据如何融入RAG？
常见的RAG教程主要介绍如何处理PDF、Markdown这类非结构化文档。但在实际生产环境中，仅依靠非结构化数据完成整个流程几乎不可能。企业内部大量有价值的数据依然存储在关系数据库甚至Excel表格里。
将结构化数据整合进来，大致有三条路径：
a. 把数据库每张表的每一行作为一个Chunk，然后进行嵌入。但这样做会破坏表的整体结构以及行与行之间的关联性，导致检索效果通常很差。
b. 不对行数据进行嵌入，而是嵌入元数据——例如表描述、视图描述、字段信息。用户查询进来后，先匹配到对应的表或字段，再通过预先写好的SQL函数去执行查询。这种方案前期编写SQL的工作量较大，但胜在稳定性高。
c. Text2SQL。让LLM直接将用户问题转换成SQL语句，然后去后端数据库执行，获取结果后再交给LLM生成最终答案。这种方法看似优雅，简单查询效果也很好，但一旦用户问题变得复杂，结果的稳定性就会下降。
三、私有化部署需要注意什么？
许多客户对数据保密性有硬性要求，必须在内部网络私有化部署。此时有几个关键点需要特别关注：
1. 模型参数大小的选择。如果LLM仅用于归纳和生成，7B或13B的规模基本够用。但如果涉及知识推理、逻辑推理、多步推理等需求，参数自然是越大越好，建议从33B或70B起步。
2. 离线环境的依赖准备。如果客户环境无法访问外部互联网，那么PyTorch、Transformers等Python库的所有依赖包必须在部署前一次性打包下载完毕。切忌在现场才发现缺少各种依赖。
3. 容器化与模型量化。使用Docker等容器技术来简化环境配置是标准操作。模型量化可以显著提升推理速度并降低资源消耗。此外，还需要选择一个高效的LLM服务框架来承载RAG系统。如果开源框架无法满足需求，那么该自行编写的模块就必须动手实现。
总体来看，RAG从Demo走向生产，跨越的不是单个技术点，而是一整套工程化思维。从查询预处理到数据源整合，再到部署架构设计，每一步都需要细致的工作。希望这篇梳理能帮助正在踩坑的同行们找到方向。