FDE实战：用大模型打造本地股票分析系统-CSDN博客

【FDE前沿部署实战】 用大模型打造你的专属股票分析系统 AI编程

这次我们来聊一个比较实际的落地场景 把大模型和股票数据分析结合起来 做一个真正能辅助决策的本地系统。

股票数据分析这件事 传统做法是写一堆指标计算脚本 从 K 线、成交量、财务数据里算各种因子 然后人工看报表。这套流程本身没问题 但有一个痛点 数据拿到手之后 它是结构化表格 不是自然语言。你想让大模型帮你判断“当前趋势是不是变了” 就得先把数据翻译成模型能理解的信息。这个“翻译—分析—输出”的链路 就是 FDE 前沿部署实战要解决的问题。

FDE Frontier Deployment Engineering 可以简单理解成一套面向大模型应用的部署工程方法 从数据整理、模型选型、AI 编程辅助开发 到接口服务、批量任务、性能观察 一整条链路都跑通。不是只调一个 API 完事 而是要把系统当工程来做。

本文的路线是这样的 先确认系统的核心能力和硬件门槛 再讲数据怎么从 MySQL 加工成大模型能读懂的结构化文本 然后给出本地大模型部署方案 接着用 AI 编程工具快速搭建分析系统 最后测试接口、跑批量任务、观察资源占用。整套流程做完 你会得到一个可以长期使用的股票分析工作台 而不是一堆零散的 Prompt。

如果你关心本地部署、显存占用、接口 API、批量任务和 AI 编程效率 这篇文章可以直接收藏。

1. 核心能力速览

能力项

说明

项目类型

大模型驱动的股票数据分析系统 属于 FDE 工程化落地项目

数据来源

MySQL / PostgreSQL / CSV / 第三方行情接口

主要功能

自然语言查询行情、趋势分析、多维度财务解读、风险提示、批量报告生成

大模型能力

文本理解、结构化数据转述、多轮对话、条件判断

部署方式

本地模型推理 API 服务 也可接入云模型 API

显存需求

需按实际模型版本测试 7B 量级模型通常建议 12G 以上显存 量化模型可降低要求

是否支持 CPU

支持 但速度会明显下降 推荐 GPU 推理

是否支持 API

支持 通过 FastAPI 封装统一接口

是否支持批量任务

支持 可对多只股票、多个时间区间批量生成分析报告

AI 编程辅助

支持使用 Cursor 等 AI 编程工具加速开发

适合人群

有一定 Python 基础、想做量化分析工具、想了解 FDE 部署流程的开发者

这里要说明一点 显存占用不是固定值 它取决于你选的模型参数量、量化方式、上下文长度和批处理大小。文章后面会专门讲怎么观察和调整。

2. 适用场景与使用边界

2.1 适合干什么

这个系统适合三类任务

第一类 行情数据问答。输入“最近 30 天上证指数走势如何” 系统从数据库里读取数据 结合大模型分析后输出趋势总结和关键点位。

第二类 多股票批量分析。把股票池里的 50 只股票全部生成一份日度简报 每份包含涨跌幅、成交量变化、技术指标信号和风险提示。这个任务如果人工做 每天要花一两个小时 用批量任务跑只需要几分钟。

第三类 深度研究辅助。把某只股票的历史 K 线、财务数据、新闻摘要一起塞给模型 让模型输出一份结构化的财报解读。这里模型不是算数字的 而是帮你把数字背后的业务逻辑串起来。

2.2 不能干什么

先说清楚一个边界 大模型本身不具备实时行情能力 它不知道今天的收盘价是多少。所有行情数据必须由你通过数据接口或数据库提供 模型只负责分析你喂给它的数据。

再有 大模型的分析结果不是投资建议。股票市场受政策、资金、情绪、突发事件等多重因素影响 模型只能基于历史数据做统计意义上的归纳 不能预测未来。任何输出结果都需要人工复核 不能直接作为自动交易信号。这也是本文所有落地示范的基本前提 系统输出的是辅助分析结论 不是下单指令。

3. 环境准备与前置条件

3.1 硬件环境

做 FDE 部署前 先确认自己的机器配置

硬件项

推荐配置

最低配置

GPU

NVIDIA RTX 4060 及以上

NVIDIA 显卡 显存 8G 以上

显存

12G 以上 跑 7B 模型

8G 跑量化小模型

内存

32G

16G

磁盘

100G 以上剩余空间

50G

操作系统

Windows 11 / Ubuntu 22.04

Windows 10 / macOS CPU 推理

如果是纯 CPU 推理 7B 模型的生成速度会非常慢 每分钟可能只能生成几十个 token。建议至少有一张支持 CUDA 的 NVIDIA 显卡。如果你用的是 50 系显卡 需要注意驱动和 CUDA 版本的兼容性 具体用

nvidia-smi

查看驱动支持的 CUDA 版本。

3.2 软件环境

需要安装以下内容

Python 3.10 或 3.11

MySQL 8.x 或 PostgreSQL 用于存储行情数据

CUDA Toolkit 和 cuDNN GPU 推理用

PyTorch 2.x

Ollama 或 vLLM 用于大模型部署

FastAPI Uvicorn 用于接口层

SQLAlchemy Pandas 用于数据读取和处理

Cursor 或其他 AI 编程插件 用于辅助开发

建议用 Anaconda 或 venv 创建独立环境 避免依赖冲突

conda create -n stock-ai python 3.11

conda activate stock-ai

安装核心依赖

pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu121

pip install fastapi uvicorn sqlalchemy pymysql pandas matplotlib requests

4. 数据获取与预处理 把数据库加工成大模型能读懂的数据

这是整个系统最关键的一步。很多人在这一步犯错 直接把原始 DataFrame 拼成 JSON 塞给大模型 结果模型输出一堆错误结论。为什么 因为大模型擅长处理自然语言 不擅长从密密麻麻的数字里找规律。你要做的是把数据“翻译”成模型能理解的表达方式。

4.1 数据表结构设计

假设我们有一张行情表 字段如下

CREATE TABLE stock_daily (

trade_date DATE NOT NULL,

stock_code VARCHAR(10) NOT NULL,

stock_name VARCHAR(20),

open_price DECIMAL(10,2),

close_price DECIMAL(10,2),

high_price DECIMAL(10,2),

low_price DECIMAL(10,2),

volume BIGINT,

amount DECIMAL(20,2),

PRIMARY KEY (trade_date, stock_code)

);

实际项目中通常还会有

stock_news

新闻表、

stock_financial

财务指标表、

stock_industry

行业分类表。表越多 能做的分析越丰富 但预处理复杂度也越高。

4.2 数据加工流程

从数据库读数据后 不能直接丢给模型。先做一步“特征提取” 把原始行情转成关键描述。

import pandas as pd

from sqlalchemy import create_engine

def load_stock_data(stock_code, start_date, end_date):

engine create_engine( mysql pymysql://user:password 127.0.0.1:3306/stock_db )

query

SELECT trade_date, open_price, close_price, high_price, low_price, volume, amount

FROM stock_daily

WHERE stock_code %s AND trade_date BETWEEN %s AND %s

ORDER BY trade_date

df pd.read_sql(query, engine, params (stock_code, start_date, end_date))

return df

def build_market_summary(df):

将原始行情转成大模型友好的文本描述

latest df.iloc[-1]

prev df.iloc[-2]

pct_change (latest[ close_price ] - prev[ close_price ]) / prev[ close_price ] * 100

high_20 df[ close_price ].max()

low_20 df[ close_price ].min()

summary f

股票代码: {latest[ stock_code ]}

分析周期: {df[ trade_date ].iloc[0]} 至 {df[ trade_date ].iloc[-1]}

周期内收盘价最高: {high_20:.2f}

周期内收盘价最低: {low_20:.2f}

最新交易日收盘价: {latest[ close_price ]:.2f}

较前一日涨跌幅: {pct_change:.2f}%

最新成交量: {latest[ volume ] / 10000:.2f}万手

return summary

这段代码的核心思路是 从原始数据中抽取高密度的关键指标 再把指标组织成自然语言段落。模型看到的是结论性描述 而不是几百行原始数字。

4.3 多表拼接生成分析上下文

如果你想做更深入的个股分析 需要把行情、财务、新闻信息拼在一起

def build_analysis_context(stock_code, start_date, end_date):

# 行情数据

market_df load_stock_data(stock_code, start_date, end_date)

market_summary build_market_summary(market_df)

# 财务数据 假设已有财务表

fin_df load_financial_data(stock_code)

fin_summary f

最新报告期营收: {fin_df[ revenue ].iloc[-1]:.2f}亿

同比增长: {fin_df[ revenue_yoy ].iloc[-1]:.2f}%

净利润: {fin_df[ net_profit ].iloc[-1]:.2f}亿

同比增长: {fin_df[ profit_yoy ].iloc[-1]:.2f}%

毛利率: {fin_df[ gross_margin ].iloc[-1]:.2f}%

# 拼接成统一上下文

context f 【行情摘要】\n{market_summary}\n【财务摘要】\n{fin_summary}

return context

这一步做完 你就有了一套标准的“数据到上下文”的转换管道。后续不管接入哪个大模型 输入格式都是统一的。

5. 大模型选型与本地部署

5.1 模型选择思路

做股票分析不需要最强的大模型 但需要具备三个能力 指令跟随、中文财务术语理解、结构化输出。纯本地部署推荐选择以下量级

7B 量级 Qwen2.5-7B-Instruct、ChatGLM3-6B

13B 量级 Qwen2.5-14B-Instruct

量化为 4bit 的 14B 模型 显存占用约 10G 兼顾质量和硬件门槛

这里优先推荐 Qwen 系列 原因有两个 中文能力稳定 对数字和指标的理解在同类模型中表现较好 生态完善 Ollama 和 vLLM 都支持 部署简单。

5.2 使用 Ollama 本地部署

Ollama 是目前最省事的本地模型部署工具。安装后拉取模型即可

# 安装 ollama Linux/macOS

curl -fsSL https://ollama.com/install.sh | sh

# 拉取 qwen2.5 7b 量化模型

ollama pull qwen2.5:7b

# 启动模型并验证

ollama run qwen2.5:7b 请用一句话介绍你自己

Windows 用户直接从 Ollama 官网下载安装包 双击安装 然后在命令行执行同样的

ollama pull

命令就行。

ollama pull

完成后 你本机就有可用的模型推理服务了。默认端口是 11434 可以通过

/api/generate

接口调用。

5.3 使用 vLLM 部署

如果要跑高并发 API 服务或处理更长的上下文 vLLM 是更合适的选择

pip install vllm

启动服务

python -m vllm.entrypoints.openai.api_server \

--model Qwen/Qwen2.5-7B-Instruct \

--port 8000 \

--gpu-memory-utilization 0.9 \

--max-model-len 8192

vLLM 启动后 暴露的是 OpenAI 兼容接口 可以直接用 OpenAI SDK 调用

from openai import OpenAI

client OpenAI(

base_url http://localhost:8000/v1 ,

api_key EMPTY

response client.chat.completions.create(

model Qwen/Qwen2.5-7B-Instruct ,

messages [

{ role : user , content : 分析一下这份行情摘要 }

print(response.choices[0].message.content)

需要注意 vLLM 需要显存容量充足 如果显存不足 可以降低

--max-model-len

或换更小的模型。第一次启动时模型权重文件会自动下载 网络稳定即可。

6. 利用 AI 编程快速搭建系统框架

这是 FDE 实战中很重要的一环 让 AI 编程工具帮你写重复代码 把精力集中在业务逻辑上。

6.1 准备需求文档

用 Cursor 类的 AI 编程工具之前 先把需求拆成可执行的子任务

数据层 数据库读取、数据预处理

提示词层 构建分析 Prompt

模型层 调用本地模型接口

服务层 FastAPI 接口封装

展示层 WebUI 或命令行输出

6.2 让 AI 生成服务端代码

在 Cursor 中打开项目目录 输入以下指令

请帮我用 FastAPI 写一个股票分析服务 包含以下功能

1. 一个 GET 接口 /analyze 接收 stock_code、start_date、end_date 参数

2. 接口内部先从 MySQL 读取行情数据

3. 调用本地大模型 API Ollama 或 vLLM 生成分析报告

4. 返回 JSON 包含原始摘要和模型分析结果

5. 接口需要处理参数缺失、数据为空、模型调用超时三种异常

AI 编程工具会生成一个基本可运行的 main.py。生成后 你需要人工检查三个关键点

数据库连接串是否错误

Prompt 模板是否准确传达了你想要的分析维度

异常处理是否覆盖了边界情况

AI 编程替代的是编码中的体力活 不是业务设计和技术判断。

6.3 检查点 代码评审清单

AI 生成的代码必须过一遍这几项

检查项

说明

SQL 注入风险

参数是否使用参数化查询

敏感信息

数据库账号密码是否从环境变量读取

超时设置

模型调用是否有明确的 timeout 参数

响应格式

返回 JSON 是否包含状态码、消息、数据三要素

可观测性

是否有日志输出 便于定位问题

7. 提示词工程 让大模型真正理解行情数据

数据准备好了 模型部署好了 接下来是最关键的一层 Prompt。

7.1 结构化提示词模板

一个合格的股票分析 Prompt 要包含四个部分 角色设定、输入数据、分析要求、输出格式。

analysis_prompt 你是一名专业的股票分析师 请基于以下数据进行分析。

【输入数据】

{context}

【分析要求】

1. 从趋势、成交量、价格位置三个维度分析当前状态

2. 指出可能存在的风险 例如价格接近近期高点、成交量异常放大

3. 判断当前处于上升、下降还是震荡阶段 并说明理由

4. 不要预测未来具体价格 只做客观归因

【输出格式】

请按以下 Markdown 格式输出

## 趋势判断

结论

## 核心观察

分点列出

## 风险提示

分点列出

注意 如果数据不足或信息不完整 请直接说明「数据不足」 不要编造。

这里特意加了“不要预测未来具体价格”“数据不足不要编造”两条约束。大模型在信息不完整时容易产生幻觉 必须用指令强行压制。

7.2 多轮对话设计

如果要支持用户在 WebUI 上追问 需要把对话状态管理起来

from langchain.memory import ConversationBufferMemory

from langchain.chains import LLMChain

memory ConversationBufferMemory(return_messages True)

chain LLMChain(

llm get_llm(),

prompt analysis_prompt,

memory memory

def chat_with_analysis(context, user_question):

response chain.run(

context context,

question user_question

return response

多轮对话让用户可以在初次分析后继续追问 比如“最近成交量相比前两周有什么变化”“毛利率连续下降的原因可能有哪些”。但是要注意上下文长度 轮次太多会占满模型的 context window 建议只保留最近五轮历史。

8. 功能测试与效果验证

8.1 基础生成能力测试

先跑一次最简单的问答 确认模型能正常返回结果

curl http://localhost:11434/api/generate \

-d { model : qwen2.5:7b , prompt : 请分析以下数据: 某股近20日收盘价从10元上涨到12元 成交量同步放大 涨幅20%。给出趋势判断。 , stream : false}

判断成功的标准

返回内容完整 不是空字符串

回答中有明确的“上升”或“上涨”趋势判断

没有出现明显的数字计算错误

8.2 多只股票批量分析测试

从 MySQL 股票池中选择 10 只股票 逐只生成分析报告

import asyncio

import aiohttp

stocks [ 600519 , 000858 , 300750 , 601318 , 600036 ]

async def analyze_stock(stock_code):

async with aiohttp.ClientSession() as session:

async with session.get(

http://127.0.0.1:8000/analyze ,

params { stock_code : stock_code, start_date : 2024-01-01 , end_date : 2024-03-31 }

) as resp:

return await resp.json()

async def batch_analyze():

tasks [analyze_stock(code) for code in stocks]

results await asyncio.gather(*tasks, return_exceptions True)

for code, result in zip(stocks, results):

print(f {code}: {result[ status ]} )

asyncio.run(batch_analyze())

批量任务的成功标准

所有股票都返回

status: success

返回内容包含完整的分析模块

没有因某一只股票数据异常导致整个任务崩溃

耗时在可接受范围内

8.3 判断效果的三个维度

模型输出效果不能只看生成是否成功 要从三个维度评估

第一 准确性。模型对涨跌幅、最高价、最低价等数字的理解是否正确。可以在 Prompt 中加入“请复述最新收盘价”来验证。

第二 一致性。同一只股票、同一段数据 多次分析结果是否稳定。如果模型经常给出相反的判断 说明 Prompt 或者模型参数设置有问题。

第三 可用性。分析报告是否真的能帮助用户快速理解当前市场状态。如果输出的全是套话 没有实质信息 就要调整 Prompt 的数据维度。

9. 接口 API 与批量任务

9.1 Docker Compose 快速部署 可选

如果有多机部署需求 可以用 Docker 编排

version: 3.8

services:

ollama:

image: ollama/ollama:latest

restart: always

ports:

- 11434:11434

volumes:

- ./ollama_models:/root/.ollama

deploy:

resources:

reservations:

devices:

- driver: nvidia

count: 1

capabilities: [gpu]

stock-api:

build: .

restart: always

ports:

- 8000:8000

environment:

- DATABASE_URL mysql pymysql://user:password mysql:3306/stock_db

- LLM_BASE_URL http://ollama:11434

depends_on:

- ollama

mysql:

image: mysql:8.0

restart: always

ports:

- 3306:3306

environment:

- MYSQL_ROOT_PASSWORD your_password

- MYSQL_DATABASE stock_db

volumes:

- ./mysql_data:/var/lib/mysql

docker compose up -d

启动后 三个服务就一起跑起来了。这个方案的好处是依赖隔离、环境统一 适合部署到服务器上长期运行。注意安全要求 生产环境不要用默认密码 数据库端口不要暴露到公网。

9.2 接口 API 调用示例

API 服务层设计参考

from fastapi import FastAPI, HTTPException, Query

from pydantic import BaseModel

import requests

app FastAPI()

class AnalyzeRequest(BaseModel):

stock_code: str

start_date: str

end_date: str

class AnalyzeResponse(BaseModel):

status: str

stock_code: str

summary: str

analysis: str

app.post( /api/analyze , response_model AnalyzeResponse)

async def analyze(req: AnalyzeRequest):

# 1. 读取数据

market_df load_stock_data(req.stock_code, req.start_date, req.end_date)

if market_df.empty:

raise HTTPException(status_code 404, detail 未找到该股票在指定时间内的数据 )

# 2. 构建摘要

context build_analysis_context(req.stock_code, req.start_date, req.end_date)

# 3. 调用大模型

try:

analysis call_llm(context)

except requests.exceptions.Timeout:

raise HTTPException(status_code 503, detail 模型服务超时 请稍后重试 )

# 4. 返回结果

return AnalyzeResponse(

status success ,

stock_code req.stock_code,

summary context,

analysis analysis

# 批量分析接口

app.post( /api/analyze/batch )

async def analyze_batch(stock_codes: List[str], start_date: str, end_date: str):

results []

for code in stock_codes:

try:

result await analyze(AnalyzeRequest(stock_code code, start_date start_date, end_date end_date))

results.append(result)

except HTTPException as e:

results.append({ stock_code : code, status : failed , error : str(e.detail)})

return results

9.3 批量任务队列设计

真实场景中 一次分析 50 只股票 每只可能需要 30 秒到 2 分钟。直接同步循环效率低 用异步协程能加速 但如果并发太高 会撑爆显存或导致模型服务不稳定。

建议做法

限制最大并发数为 2

任务执行时记录开始时间和结束时间

失败任务自动重试最多 2 次

所有结果写入 MySQL 的

analysis_log

表 方便后续追溯

async def batch_with_limit(task_list, limit 2):

sem asyncio.Semaphore(limit)

async def worker(task):

async with sem:

return await task()

return await asyncio.gather(*[worker(t) for t in task_list], return_exceptions True)

10. 资源占用与性能观察

10.1 显存占用如何观察

模型推理过程中 用

nvidia-smi

观察显存占用

watch -n 2 nvidia-smi

重点观察的是

Memory-Usage

GPU-Util

两列。

Memory-Usage

稳定在一个值附近 说明模型权重加载完毕。

GPU-Util

在推理时飙升 空闲时回落 属于正常现象。

如果显存占用接近上限且 GPU-Util 持续很低 说明批处理批次太大或存在内存瓶颈。

10.2 CPU 推理 vs GPU 推理

同样的 7B 模型 在 GPU 上生成 200 个 token 可能需要 5 到 15 秒 在 CPU 上可能要 60 到 120 秒 差距接近一个数量级。

如果你只有 CPU 建议换更小的模型或量化程度更高的版本 并且把

max_tokens

限制在 500 以内 否则每一次生成都像在“拉进度条”。

10.3 如何降低显存占用

方法

效果

代价

使用 4bit 量化模型

显存降低 40% 以上

输出质量略微下降

限制

max_tokens

减少长文本输出的显存压力

输出长度受限

缩小

max_model_len

减少 KV Cache 占用

无法处理超长上下文

单批并发改为 1

避免多请求同时抢占显存

吞吐量下降

分段分析

把长数据切成多段分别分析

需要做结果合并

11. 常见问题与排查方法

问题现象

可能原因

排查方式

解决方案

Ollama 启动后接口超时

模型未加载完成或网络占用

看 Ollama 日志

等待 30 秒后重试

模型生成内容全是乱码

模型权重下载不完整

核对模型哈希或重新 pull

ollama rm

后重新拉取

生成的内容只有一段废话

Prompt 指令不够明确

检查是否告诉模型“要输出什么”

增加输出格式约束

本地模型调用报 CUDA 错误

GPU 驱动或 PyTorch 版本不匹配

nvidia-smi

查看驱动版本

按 CUDA 版本重装 PyTorch

显存不足 OOM

模型过大或并发过高

看进程显存占用

换小模型或降低并发数

vLLM 启动失败提示端口占用

8000 端口被其他进程占用

lsof -i:8000

换端口或结束占用进程

使用 vLLM 时请求 429

并发限制触发

查看服务日志

降低并发或增加

max_num_seqs

批量任务中途卡住

等不到的请求未设置超时

查看日志中的耗时记录

请求加 timeout 增加失败重试

股价数据加载为空

MySQL 连接串或表名错误

单独跑一条 SQL 验证

修正连接配置或表名

11.1 一个典型排查案例

假设你启动 API 服务后 调用

/api/analyze

返回 500 错误 日志显示

requests.exceptions.ConnectionError: HTTPConnectionPool(host localhost , port 8000): Max retries exceeded

这个错误的意思是 API 服务在尝试调用 8000 端口的模型服务 但 8000 端口没有服务在监听。原因通常是 vLLM 服务没有启动 或者启动失败。

排查顺序

curl http://localhost:8000/v1/models

检查模型服务是否存活

查看 vLLM 进程日志 确认是否因显存不足退出

如果 vLLM 正常 检查项目代码里配置的

LLM_BASE_URL

是否指向了 8000 端口

修改配置后重启 API 服务

这类问题的根本原因往往不是代码逻辑 而是服务依赖关系没有启动完整。FDE 部署的一个重要习惯就是把所有服务的启动状态、端口、日志统一管理起来。

12. 最佳实践与使用建议

12.1 开发阶段

第一 第一次跑通时用小样本。先用一只股票、一个月数据把整条链路跑通 确认没问题再扩展到全量数据。这样能大幅缩短问题排查时间。

第二 保留一套最小可运行配置。在项目根目录维护一份

.env.example

文件 把所有关键的连接串、端口、模型名写清楚。新环境部署时直接复制修改即可 不用重新踩一遍坑。

第三 模型文件、输入素材、输出结果分目录管理

stock-ai/

├── data/

│ ├── raw/ # 原始行情 CSV

│ └── processed/ # 处理后的摘要特征

├── models/ # 本地模型权重

├── logs/ # 运行日志

├── output/ # 分析结果

├── prompts/ # Prompt 模板

├── services/ # API 服务代码

└── scripts/ # 数据预处理脚本

12.2 接口服务阶段

接口服务对外暴露时 要注意访问控制。最简单的方式是给 API 加一个 Bearer Token

from fastapi import Depends, HTTPException, Header

def verify_token(authorization: str Header(...)):

if authorization ! f Bearer {API_TOKEN} :

raise HTTPException(status_code 401, detail Unauthorized )

app.post( /api/analyze , dependencies [Depends(verify_token)])

async def analyze(req: AnalyzeRequest):

...

12.3 合规与隐私提醒

股票分析系统涉及金融数据 要特别注意三点

第一 数据来源必须合规。使用行情数据接口前 确认数据授权范围 不要私自采集和传播未授权数据。

第二 分析结果不能直接作为投资建议输出给用户。建议在系统界面或报告中加入“以上内容仅供研究参考 不构成投资建议”的提示。

第三 如果系统涉及个人账户数据、自选股列表 要做隐私隔离 防止数据泄露。

13. 总结与下一步

整个 FDE 实战下来 核心收获不是“用大模型分析股票”这个单点功能 而是建立了一套完整的大模型应用部署方法论

数据层 从关系数据库加工成模型友好的结构化上下文

模型层 本地部署 Qwen2.5 或类似模型 兼顾成本与隐私

开发层 利用 AI 编程工具把接口层代码写出来 减少重复劳动

服务层 封装成 FastAPI 接口 支持单次分析和批量任务

运维层 通过资源观察、日志、错误排查来保证服务稳定

最先应该验证的功能 是“行情摘要 趋势判断”这条基础链路。只要这只链路跑通 后面添加财务分析、新闻分析、多股票报告都是线性扩展。最容易踩的坑 一个是数据预处理不到位导致模型输出质量差 另一个是显存不足导致服务不稳定。

后续可以继续扩展的方向包括

接入更多数据源 比如实时行情接口 让系统具备更强的时效性

增加技术指标计算层 比如 MACD、KDJ、RSI 把这些指标也喂给模型

引入向量数据库 让模型可以检索历史研究报告

做 Web 前端可视化 把分析报告和 K 线图放在同一个页面

建议把本文提到的数据预处理脚本和 Prompt 模板保存下来 作为后续其他大模型应用项目的基础模板。FDE 的核心思想就是让大模型应用的部署变得可复制、可验证、可运维 把这个流程掌握好 以后做任何行业的大模型应用 都能少走很多弯路。