HENGSHI SENSE AI助手RAG架构实战：向量化检索与多模型适配技术实现

Article body

正文

15 分钟阅读

导语：在企业级BI平台中，AI助手的核心价值不是”能聊天”，而是”能查准数据”。当用户用自然语言提问时，系统需要在毫秒级别完成意图理解→知识检索→SQL生成→结果验证的完整链路。HENGSHI SENSE的AI助手架构选择了一条技术硬核路线：基于多语言向量模型的RAG（Retrieval-Augmented Generation）架构，配合可扩展的多模型适配层，在保证查询准确性的同时实现灵活的模型选型。本文将从向量库服务部署、RAG检索链路、多模型适配配置三个维度，全面拆解HENGSHI SENSE AI助手的工程实现。

一、为什么需要RAG？ChatBI的准确率困境

1.1 纯LLM方案的固有局限

在深入HENGSHI SENSE的AI架构之前，需要先理解一个核心工程问题：为什么纯LLM方案在BI场景中无法达到生产级准确率？

企业级数据分析场景有以下几个独特的约束条件：

约束维度	通用LLM场景	企业BI场景
知识范围	通用知识库，覆盖面广	私有数仓schema、业务口径、行业术语
准确性要求	容忍一定的创造性回答	要求100%确定性的SQL和查询结果
Schema复杂度	输入文本通常几百字	数仓可能包含数百张表、数千字段
上下文窗口	可以截断或摘要	完整的表结构、字段说明、指标定义不能省略
时效性	知识截止日期可接受	数据实时变化，schema频繁变更

纯LLM方案的核心问题在于：它试图用”参数化知识”（训练时学到的知识）来处理”非参数化知识”（企业私有数仓的schema和业务口径）。这两者的本质是不兼容的——数仓的表名、字段名、业务含义是任意的、企业独有的，LLM不可能在训练阶段学到。

1.2 RAG架构的技术优势

RAG（Retrieval-Augmented Generation，检索增强生成）架构的核心思想是：不要让LLM去”记住”企业私有知识，而是在推理时把相关知识”喂”给它。

在BI场景中，RAG的典型工作流如下：

用户提问："上个月华东区的GMV是多少？"
        │
        ▼
┌─────────────────────────────────────────┐
│ Step 1: 问题向量化                        │
│   将自然语言问题编码为高维向量             │
└──────────────┬──────────────────────────┘
               ▼
┌─────────────────────────────────────────┐
│ Step 2: 向量检索                         │
│   在知识库中检索与问题语义最相关的         │
│   表结构、字段说明、指标定义               │
└──────────────┬──────────────────────────┘
               ▼
┌─────────────────────────────────────────┐
│ Step 3: 上下文组装                        │
│   将检索到的知识+用户问题组装为prompt      │
└──────────────┬──────────────────────────┘
               ▼
┌─────────────────────────────────────────┐
│ Step 4: LLM生成SQL                       │
│   基于精准上下文生成确定性的SQL语句        │
└──────────────┬──────────────────────────┘
               ▼
┌─────────────────────────────────────────┐
│ Step 5: 执行与验证                        │
│   执行SQL并返回查询结果给用户             │
└─────────────────────────────────────────┘

这种架构的工程优势在于：

知识实时更新：数仓schema变更后，只需重新向量化知识库，无需重新训练模型
知识精准注入：只检索与当前问题相关的schema片段，避免上下文爆炸
可追溯可审计：每次查询使用的知识来源可追溯，便于问题诊断

二、向量库服务架构：从组件选型到生产部署

2.1 HENGSHI SENSE向量库的架构设计

HENGSHI SENSE的向量检索服务由两个核心组件构成：

┌──────────────────────────────────────────────────────────┐
│                  HENGSHI SENSE AI Architecture            │
│                                                          │
│  ┌────────────┐    ┌──────────────────┐                   │
│  │ vector-    │    │ vector-postgres  │                   │
│  │ serve      │◄──►│ (pgvector)       │                   │
│  │            │    │                  │                   │
│  │ Embedding  │    │ 向量存储 &       │                   │
│  │ Service    │    │ 相似度检索        │                   │
│  └─────┬──────┘    └────────┬─────────┘                   │
│        │                    │                             │
│        │ HTTP API           │ JDBC                        │
│        │ /v1/embeddings     │                             │
│        ▼                    ▼                             │
│  ┌─────────────────────────────────────┐                  │
│  │         HENGSHI SENSE Core           │                  │
│  │                                     │                  │
│  │  AI Assistant Module                 │                  │
│  │  ├── Question Understanding          │                  │
│  │  ├── Knowledge Retrieval (RAG)       │                  │
│  │  ├── SQL Generation (LLM)            │                  │
│  │  └── Result Validation               │                  │
│  └─────────────────────────────────────┘                  │
└──────────────────────────────────────────────────────────┘

vector-serve：负责文本向量化（Embedding）的推理服务。它接收文本输入，调用嵌入模型生成高维向量表示。

vector-postgres：基于PostgreSQL + pgvector扩展的向量数据库。负责存储数据集元数据、指标定义、字段说明等知识的向量表示，并提供高效的近似最近邻（ANN）检索能力。

2.2 嵌入模型选型：为什么选multilingual-e5-base

HENGSHI SENSE的向量服务默认使用 intfloat/multilingual-e5-base 模型，这是一个基于Transformer架构的多语言文本嵌入模型。选型考量如下：

选型维度	multilingual-e5-base	OpenAI text-embedding-3	BGE-large-zh
多语言支持	✅ 支持中英日韩等15+语言	✅ 但中文效果偏弱	⚠️ 主要优化中文
私有部署	✅ 可完全离线部署	❌ 必须调用云API	✅ 可离线部署
向量维度	768维	1536/3072维	1024维
推理速度	中等（~50ms/句）	快（云端推理）	慢（~80ms/句）
检索效果	中上（MTEB排名靠前）	优秀	优秀（中文场景）
硬件要求	1-2GB GPU内存	无（云服务）	2-4GB GPU内存

对于企业级BI PaaS场景，multilingual-e5-base的选择是合理的：

企业客户通常有数据不出域的合规要求，私有部署是刚需
多语言能力满足跨国企业的需求
768维向量在检索精度和存储/计算成本之间取得了良好的平衡

2.3 部署方式一：脚本部署（单机/Docker Compose）

对于中小规模部署或开发测试环境，HENGSHI提供了基于Docker Compose的一键部署脚本：

# 克隆部署配置
git clone <hengshi-vector-deploy-repo>
cd hengshi-vector-deploy

# 启动向量服务（vector-serve + vector-postgres）
bash deploy.sh -m start

# 查看运行状态
bash deploy.sh -m status

# 停止服务
bash deploy.sh -m stop

# 清理容器并停止
bash deploy.sh -m down

部署成功后，系统将启动两个Docker容器：

容器	端口	功能
vector-serve	3000	嵌入模型推理服务
vector-postgres	54321	向量数据库（pgvector）

2.4 部署方式二：Kubernetes集群部署

对于生产环境，推荐使用Kubernetes部署，以获得更好的高可用性和弹性伸缩能力：

Step 1：应用K8s资源

# vectorize-pg.yaml — 向量数据库
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: vector-postgres
  namespace: hengshi
spec:
  serviceName: vector-postgres
  replicas: 1
  selector:
    matchLabels:
      app: vector-postgres
  template:
    metadata:
      labels:
        app: vector-postgres
    spec:
      containers:
      - name: postgres
        image: pgvector/pgvector:pg16
        ports:
        - containerPort: 5432
        env:
        - name: POSTGRES_DB
          value: postgres
        - name: POSTGRES_USER
          value: postgres
        - name: POSTGRES_PASSWORD
          valueFrom:
            secretKeyRef:
              name: vector-db-secret
              key: password
        volumeMounts:
        - name: pg-data
          mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:
  - metadata:
      name: pg-data
    spec:
      accessModes: ["ReadWriteOnce"]
      storageClassName: longhorn  # 根据集群存储系统修改
      resources:
        requests:
          storage: 50Gi
---
apiVersion: v1
kind: Service
metadata:
  name: vector-postgres
  namespace: hengshi
spec:
  ports:
  - port: 5432
    targetPort: 5432
  selector:
    app: vector-postgres

# vector-serve.yaml — 嵌入服务
apiVersion: apps/v1
kind: Deployment
metadata:
  name: vector-serve
  namespace: hengshi
spec:
  replicas: 2
  selector:
    matchLabels:
      app: vector-serve
  template:
    metadata:
      labels:
        app: vector-serve
    spec:
      containers:
      - name: vector-serve
        image: hengshi/vector-serve:latest
        ports:
        - containerPort: 3000
        resources:
          requests:
            memory: "2Gi"
            cpu: "1"
          limits:
            memory: "4Gi"
            cpu: "2"
        volumeMounts:
        - name: model-cache
          mountPath: /root/.cache/huggingface/hub
      volumes:
      - name: model-cache
        persistentVolumeClaim:
          claimName: model-cache-pvc
---
apiVersion: v1
kind: Service
metadata:
  name: vector-serve
  namespace: hengshi
spec:
  type: ClusterIP
  ports:
  - port: 3000
    targetPort: 3000
  selector:
    app: vector-serve

kubectl -n hengshi apply -f vectorize-pg.yaml -f vector-serve.yaml

Step 2：加载模型文件

# 复制模型文件到vector-serve Pod
kubectl -n hengshi cp models--intfloat--multilingual-e5-base.tar.gz \
  vector-serve-xxxx:/root/.cache/huggingface/hub/

# 在Pod内解压
kubectl -n hengshi exec -t vector-serve-xxxx -- \
  bash -c "cd /root/.cache/huggingface/hub && tar xf models--intfloat--multilingual-e5-base.tar.gz"

2.5 HENGSHI SENSE Core对接向量服务

部署完成后，需要在HENGSHI SENSE核心服务中配置向量服务的连接信息：

单节点部署：

# 编辑环境配置文件
vi /opt/hengshi/conf/hengshi-sense-env.sh

# 添加以下配置
export VECTOR_DB_URL="jdbc:postgresql://<VECTOR_PG_HOST>:54321/postgres"
export VECTOR_ENDPOINT="http://<VECTOR_SERVE_HOST>:3000/v1/embeddings"

Docker Compose部署：

# 在.env文件中添加
VECTOR_DB_URL=jdbc:postgresql://vector-postgres:5432/postgres
VECTOR_ENDPOINT=http://vector-serve:3000/v1/embeddings

Kubernetes部署：

# 编辑configmap
kubectl -n hengshi edit configmap hengshi-sense

apiVersion: v1
kind: ConfigMap
metadata:
  name: hengshi-sense
  namespace: hengshi
data:
  VECTOR_DB_URL: "jdbc://vector-postgres:5432/postgres"
  VECTOR_ENDPOINT: "http://vector-serve:3000/v1/embeddings"

2.6 部署验证与故障排查

部署完成后，需要验证向量服务的连通性：

验证vector-serve嵌入服务：

curl -X POST http://localhost:3000/v1/embeddings \
  -H 'Content-Type: application/json' \
  -d '{"input": ["上个月华东区的销售额"], "model": "intfloat/multilingual-e5-base"}'

期望返回类似如下JSON：

{
  "object": "list",
  "data": [
    {
      "object": "embedding",
      "embedding": [0.0123, -0.0456, 0.0789, ...],
      "index": 0
    }
  ],
  "model": "intfloat/multilingual-e5-base",
  "usage": {
    "prompt_tokens": 12,
    "total_tokens": 12
  }
}

验证vector-postgres向量检索：

-- 进入PostgreSQL
psql -h localhost -p 54321 -U postgres -d postgres

-- 验证pgvector扩展
SELECT * FROM pg_extension WHERE extname = 'vector';

-- 测试向量检索
SELECT vectorize.transform_embeddings(
  input => '测试嵌入',
  model_name => 'intfloat/multilingual-e5-base'
);

常见故障排查：

错误信息	可能原因	解决方案
`query vector db fail`	vector-serve和vector-postgres通信故障	分别验证两个服务的健康状态和网络连通性
`connection refused`	端口未开放或防火墙限制	检查防火墙规则和网络策略
`model not found`	模型文件未正确加载	重新执行模型文件复制和解压步骤
`out of memory`	GPU内存不足	减少vector-serve副本数或增加GPU资源

三、多模型适配层：从云服务到私有化部署的灵活配置

3.1 模型适配架构设计

HENGSHI SENSE的AI助手并非绑定单一LLM供应商，而是设计了一套灵活的多模型适配层：

┌─────────────────────────────────────────────────────┐
│              HENGSHI SENSE AI Model Adapter           │
│                                                      │
│  ┌───────────────────────────────────────────┐        │
│  │           Unified OpenAI-Compatible API    │        │
│  │    (统一请求/响应格式)                     │        │
│  └─────────────┬─────────────────────────────┘        │
│                │                                      │
│     ┌──────────┼──────────┐                          │
│     ▼          ▼          ▼                          │
│  ┌──────┐  ┌──────┐  ┌──────┐                       │
│  │云服务 │  │云服务 │  │私有化│                       │
│  │DeepSeek│  │OpenAI│  │Ollama│                      │
│  └──────┘  └──────┘  └──────┘                       │
│     │          │          │                          │
│     ▼          ▼          ▼                          │
│  ┌──────┐  ┌──────┐  ┌──────┐                       │
│  │Bedrock│  │Groq  │  │通义千问│                      │
│  └──────┘  └──────┘  └──────┘                       │
│                                                      │
└─────────────────────────────────────────────────────┘

核心设计理念是OpenAI API兼容：任何兼容OpenAI API请求/响应格式的模型服务，都可以无缝接入HENGSHI SENSE。这意味着企业可以根据自身的合规要求、成本预算和性能需求，灵活选择模型供应商。

3.2 支持的模型供应商矩阵

HENGSHI SENSE目前已适配12+模型供应商：

供应商	部署方式	推荐场景	API格式
DeepSeek	云服务	高性价比中文场景	OpenAI兼容
OpenAI	云服务	全球化部署、英文场景	原生OpenAI API
Azure OpenAI	云服务	企业合规、数据驻留	OpenAI兼容
AWS Bedrock	云服务	已在AWS生态的企业	自定义适配
通义千问	云服务/私有化	中文场景、阿里云生态	OpenAI兼容
Moonshot AI	云服务	长上下文场景（128K+）	OpenAI兼容
MiniMax	云服务/私有化	高性价比MoE模型	OpenAI兼容
百川AI	云服务/私有化	中文大模型	OpenAI兼容
Groq Cloud	云服务	极低延迟推理	OpenAI兼容
MistralAI	云服务	欧洲数据合规	OpenAI兼容
Nvidia	云服务	GPU加速推理	OpenAI兼容
TogetherAI	云服务	开源模型托管	OpenAI兼容
Ollama	私有化	完全离线部署	OpenAI兼容

3.3 私有化部署模型推荐

对于数据安全要求高、需要完全离线部署的企业，HENGSHI推荐以下私有化模型配置：

工作流模式（结构化任务处理）

适合需要高指令遵循能力、结构化输出的场景：

模型	参数量	架构	推荐GPU配置	特点
Qwen3.5-27B	27B	Dense	2× NVIDIA A100 80G 或 4× A800 40G	指令遵循优秀，中文能力强

Agent模式（多步推理+工具调用）

适合需要复杂推理、长上下文和工具调用的BI Agent场景：

模型	参数量	架构	推荐GPU配置	特点
Kimi-K2.5	1T (1000B) / 32B (MoE)	MoE	8× NVIDIA H100 80G 或 16× A100 80G	超长上下文，复杂推理
MiniMax-M2.5	230B / 10B (MoE)	MoE	4× NVIDIA A100 80G 或 8× A800 40G	性价比高，中文优化
GLM-5	744B / 40B (MoE)	MoE	8× NVIDIA H100 80G 或 16× A100 80G	工具调用能力强

量化部署建议：

如果GPU资源有限，可以考虑使用INT4/INT8量化版本：

量化方式	内存节省	精度影响	适用场景
BF16（全精度）	基准	无	生产环境、高精度要求
INT8量化	~50%	轻微	资源受限的生产环境
INT4量化	~75%	中等	开发测试、边缘部署

3.4 模型配置实战

云服务模型配置（以DeepSeek为例）

# 在系统管理后台配置
# 请求地址
API_ENDPOINT=https://platform.deepseek.com/chat/completions

# API密钥
API_KEY=sk-xxxxxxxxxxxxxxxx

# 模型名称
MODEL_NAME=deepseek-chat

# 温度参数（BI场景建议设低，减少幻觉）
TEMPERATURE=0.1

# 最大token数
MAX_TOKENS=4096

私有化模型配置（以Ollama为例）

# 安装Ollama
curl -fsSL https://ollama.ai/install.sh | sh

# 拉取模型
ollama pull qwen2.5:27b

# 启动API服务（默认兼容OpenAI API格式）
ollama serve

# HENGSHI SENSE配置
API_ENDPOINT=http://localhost:11434/v1/chat/completions
API_KEY=ollama  # Ollama不需要真实密钥，但字段必须填写
MODEL_NAME=qwen2.5:27b

AWS Bedrock配置（以Claude 3.5为例）

# HENGSHI SENSE配置
API_ENDPOINT=https://bedrock-runtime.us-east-1.amazonaws.com/model/anthropic.claude-3-5-sonnet-20241022-v2:0/invoke

# AWS凭证通过环境变量或IAM Role传入
AWS_ACCESS_KEY_ID=AKIAxxxxxxxx
AWS_SECRET_ACCESS_KEY=xxxxxxxxxxxx
AWS_REGION=us-east-1

四、AI助手的版本演进：从基础问数到智能解读

4.1 AI能力版本演进时间线

HENGSHI SENSE的AI能力经历了清晰的渐进式演进：

版本	AI能力	技术实现
5.1.x	基础AI助手	Text-to-SQL、自然语言查询
5.4.0	Claude 3集成	AWS Bedrock接入、多模型支持
5.4.8	Nova模型	AWS Bedrock Nova模型支持
6.0.0	AI入口集成	指标分析页AI提问入口、一键生成看板、SDK支持
6.0.4	Agent增强	Copilot SDK显示思考过程、MOVA模型兼容
6.0.5	Agent草稿纸	Agent启用”草稿纸”工具，增强多步推理
6.1.0	智能解读	AI智能解读BI报表、Data Agent悬浮按钮
6.2.x	ChatBI优化	SSO默认角色、表格保留排序、生成表格添加到仪表盘

4.2 关键架构优化：从串行到并行

6.0.0版本对AI助手的prompt指令执行架构进行了重大优化——步骤执行从串行改为并行：

// v5.x 串行执行（总耗时 = 各步骤耗时之和）
Step 1: Schema检索 ──► Step 2: 意图理解 ──► Step 3: SQL生成 ──► Step 4: 结果格式化
     200ms                150ms                300ms                100ms
                                                         总耗时: ~750ms

// v6.0 并行执行（总耗时 ≈ 最长步骤耗时）
Step 1: Schema检索 ──────┐
     200ms                │
Step 2: 意图理解 ────────┼──► Step 3: SQL生成（等待前两步完成）
     150ms                │         300ms
Step 4: 权限校验 ────────┘
     100ms
                                        总耗时: ~500ms

这一优化将AI助手的平均响应时间缩短了约30-40%，显著提升了用户体验。

4.3 AI助手SDK与Copilot集成

HENGSHI SENSE提供了React JS版的AI助手SDK，支持第三方系统深度集成：

// 示例：在React应用中嵌入HENGSHI AI Copilot
import { HengshiCopilot } from '@hengshi/ai-sdk';

function App() {
  return (
    <div className="app-container">
      <HengshiCopilot
        endpoint="https://your-hengshi-instance.com"
        token="your-api-token"
        theme="light"
        showThinking={true}  // 显示思考过程
        position="bottom-right"
        onQuerySubmit={(query) => {
          console.log('User query:', query);
        }}
        onResultReady={(result) => {
          console.log('AI result:', result);
        }}
      />
    </div>
  );
}

4.4 智能解读功能（6.1.0+）

6.1.0版本引入的”AI智能解读”功能，允许用户点击按钮触发AI对当前BI报表进行智能分析：

自动分析报表中的趋势、异常和关键发现
分析结果可与图表联动——点击分析中的某个发现，图表自动跳转到对应的维度筛选
支持中文自然语言输出

这一功能的技术实现基于报表元数据的结构化提取+LLM分析生成，而非简单的图表描述。

五、工程最佳实践

5.1 向量库运维建议

实践项	建议	原因
知识库更新频率	Schema变更后立即重新向量化	避免检索到过时的表结构信息
向量索引类型	使用IVFFlat或HNSW索引	平衡检索精度和查询延迟
监控指标	向量检索延迟、检索召回率、嵌入服务QPS	及时发现性能瓶颈
数据备份	定期备份vector-postgres	向量数据重建成本高

5.2 模型选型建议

场景	推荐模型	原因
高并发简单查询	DeepSeek / Groq	低延迟、高吞吐
复杂分析任务	Claude 3.5 / GPT-4o	强推理能力
完全离线部署	Qwen2.5-27B / GLM-5	私有化支持好
预算有限	MiniMax-M2.5	MoE架构性价比高
中文场景	DeepSeek / 通义千问	中文理解和生成质量高

5.3 准确率优化策略

指标语义层对齐：确保向量知识库中的指标定义与指标平台保持同步
业务术语映射：为行业术语建立标准化的同义词表，提升检索召回率
Few-shot示例库：为常见查询模式准备示例问答对，在prompt中提供上下文
结果校验层：在SQL执行后增加结果合理性校验，拦截明显的异常结果
用户反馈闭环：记录用户对AI回答的评价，持续优化prompt和检索策略

六、总结

HENGSHI SENSE的AI助手架构体现了企业级BI平台在AI集成上的工程化思考：

RAG架构保证了知识实时性和查询准确性，通过多语言向量模型+pgvector实现了高效的语义检索
多模型适配层提供了灵活的部署选择，从云服务到私有化、从通用模型到专业模型都可以灵活切换
渐进式版本演进确保了AI能力的稳定落地，从基础问数到智能解读、从串行到并行执行，每一步都经过了工程验证
SDK化的集成方式让AI能力可以轻松嵌入第三方业务系统，符合衡石”BI PaaS引擎”的核心定位

对于正在构建AI+BI能力的企业而言，HENGSHI SENSE的这套架构提供了一个值得参考的工程实践样本——不是追求最前沿的模型能力，而是追求最可靠的工程落地。