基于RAG与LLM的港股智能对话分析工具：架构、实现与优化-深圳市維司達科技有限公司

1. 项目概述：一个面向港股市场的智能对话分析工具

最近在金融科技圈子里，一个名为“TradeHKChat”的开源项目引起了我的注意。它来自YOHOAI，定位是一个专门针对港股市场的智能对话分析工具。简单来说，你可以像和专家聊天一样，用自然语言询问港股相关的信息，比如“腾讯今天股价怎么样？”、“最近有哪些新股要上市？”、“帮我分析一下美团最近的财报”，它就能给你结构化的答案，甚至附上图表。这听起来像是把ChatGPT的能力垂直应用到了港股投资这个细分领域。

我自己做量化交易和数据分析有年头了，深知信息获取和处理的效率对投资决策有多关键。港股市场信息繁杂，财报、公告、新闻、实时行情、技术指标……传统方式需要投资者在不同平台、软件间切换，手动查询、整理、计算，耗时耗力。TradeHKChat这类工具的出现，本质上是用自然语言处理（NLP）和大型语言模型（LLM）技术，为投资者提供了一个统一的、智能的交互入口，试图把“信息检索-数据处理-初步分析”这个链条自动化、智能化。

这个项目适合谁呢？首先是对港股感兴趣的散户投资者，尤其是那些希望提升信息处理效率、但又没有编程基础的朋友。其次，是金融科技开发者或研究者，可以把它当作一个垂直领域AI应用的参考案例，学习如何将通用大模型与专业金融数据结合。当然，对于我这样的从业者，更关心的是它的实现思路、技术选型、数据源可靠性以及在实际场景中的边界和局限。接下来，我就结合自己的经验，对这个项目进行一次深度拆解。

2. 核心架构与技术栈解析

2.1 整体设计思路：从“聊天”到“答案”的管道

TradeHKChat的核心目标很明确：理解用户关于港股的提问，然后给出准确、有用的回答。这背后是一个典型的“检索增强生成”（Retrieval-Augmented Generation, RAG）管道，但针对金融领域做了大量定制。我把它拆解成几个核心环节：

用户意图理解与查询解析：这不是简单的关键词匹配。当用户问“小米集团最近表现强不强？”时，系统需要理解“小米集团”对应股票代码01810.HK，“最近”可能指最近一周或一个月，“表现强不强”则涉及股价涨跌幅、相对大盘表现等量化指标。这一步通常依赖LLM的意图识别和实体链接能力。
多源金融数据检索与融合：这是项目的基石。系统需要根据解析后的查询，从多个数据源获取信息。可能包括：
- 实时行情：最新价、涨跌幅、成交量、分时数据。
- 基本面数据：公司简介、财务指标（PE、PB、ROE）、财报摘要。
- 市场数据：指数行情、板块涨跌、资金流向。
- 新闻与公告：公司公告、行业新闻、分析师报告。
- 历史数据：用于计算技术指标（如MA、MACD、RSI）或进行历史回测。
信息加工与推理：获取原始数据后，需要进行计算和推理。比如用户问“市盈率低于行业平均的科技股有哪些？”，系统需要计算各科技股的市盈率，再与行业平均值比较，最后筛选出结果。这需要内置金融公式计算引擎或调用LLM的推理能力。
答案生成与格式化：将处理后的信息，以人类可读的自然语言形式组织起来，并可能附带表格、图表（如K线图、柱状图）。这里LLM负责语言的流畅和逻辑的组织。

这个管道设计的关键在于准确性与时效性的平衡。金融数据容错率极低，一个数字错误可能导致完全不同的结论。因此，核心计算（如指标计算）绝不能完全依赖LLM的“幻觉”，必须由确定性的程序或经过严格验证的金融库来完成。

2.2 关键技术组件选型考量

从项目名称和常见实践推断，TradeHKChat的技术栈很可能围绕以下几个核心组件构建：

后端框架：FastAPI或Django。FastAPI以其异步高性能和自动API文档生成著称，非常适合构建需要快速响应的对话API。Django则提供了更全面的后台管理能力，如果项目涉及复杂的数据管理后台，Django是更稳妥的选择。我个人在快速原型阶段更倾向FastAPI。
核心LLM：开源模型微调或大模型API结合。直接使用GPT-4、Claude等闭源API虽然省事，但成本高、数据隐私存疑，且对港股特定知识（如繁体字术语、本地市场规则）理解可能不足。更可能的方案是使用Llama 3、Qwen或ChatGLM这类开源大模型作为基座，使用港股相关的财报、公告、研报数据进行领域适应微调（Domain Adaptation Fine-Tuning），或者至少进行高质量的检索增强（RAG）。这能显著提升模型对专业术语和上下文的理解。
向量数据库与检索：Chroma、Milvus或Weaviate。用户的许多问题（如“找找关于港股通扩容的新闻”）需要语义搜索，而非精确匹配。这就需要将非结构化的文本数据（新闻、公告内容）转化为向量（Embeddings），存入向量数据库。当用户提问时，将问题也转化为向量，在数据库中查找最相似的文本片段，作为生成答案的参考。选择哪款向量数据库，需权衡易用性、性能和分布式能力。
金融数据源：这是项目的命脉。可能整合的数据源包括：
- 免费/开源数据：yfinance（雅虎财经，港股数据有限且不稳定）、akshare（AkShare，A股数据丰富，港股部分在完善）、各大券商公开API（通常有频率和权限限制）。
- 专业数据供应商：Wind、Bloomberg、Refinitiv Eikon，数据全面准确但价格昂贵，个人或小团队难以承受。
- 网络爬虫：自建爬虫从港交所披露易、公司官网、财经媒体抓取公告和新闻，但需处理反爬、数据清洗和合法性风险。
注意：在金融领域使用爬虫需格外谨慎，必须严格遵守robots.txt协议，避免对目标网站造成压力，并关注数据使用的合规性。最好优先考虑有明确授权或免费提供的数据接口。
计算与可视化：Pandas、NumPy用于数据清洗和计算；Ta-Lib或pandas-ta用于技术指标计算；Plotly、Matplotlib用于生成交互式或静态图表，并可能通过base64编码嵌入到对话回复中。

为什么是这样一个技术栈？首先，它平衡了开发效率与专业性。FastAPI+开源LLM+向量数据库是当前构建智能对话应用的“标配”，社区活跃，资源丰富。其次，它突出了金融领域的特殊性——对确定性计算和数据准确性的高要求，因此必须引入专业的金融计算库和可靠的数据管道，而不是完全押宝在LLM的生成能力上。

3. 核心功能模块深度拆解

3.1 智能问答引擎的实现细节

这是用户直接感知的核心。实现一个可靠的港股智能问答，远不止是“问-答”那么简单。

1. 查询理解与路由：系统首先需要对用户query进行分类。是问实时行情、财务指标、新闻，还是要求进行对比分析或计算？这可以通过一个轻量级的文本分类模型（如基于BERT微调）或通过Prompt工程引导大模型来判断。例如，识别到“股价”、“涨跌”、“开盘”等词，路由到行情模块；识别到“营收”、“净利润”、“毛利率”，路由到财报模块；识别到“对比”、“vs”、“哪个更好”，则进入分析比较模块。

2. 精准的数据获取与校验：每个模块背后对应着不同的数据获取策略。

行情模块：需要对接低延迟的数据流或高频轮询API。对于“当前股价”，必须确保数据是几秒内的最新数据。这里有一个坑：不同数据源的价格可能略有差异（如收盘价是last price还是adjusted close），必须统一标准并在回复中注明数据来源和时间戳。

# 示例：获取股票最新行情（伪代码） async def get_realtime_quote(symbol: str): # 1. 尝试从缓存中获取（如Redis，缓存1-5秒） # 2. 缓存失效，调用数据源API # 3. 数据清洗：检查字段完整性，处理异常值（如价格突然为0） # 4. 更新缓存并返回 quote_data = await data_provider.fetch_quote(symbol) if not quote_data or quote_data.price <= 0: # 降级策略：返回最近的有效数据，并明确提示 return {"price": last_valid_price, "note": "数据暂未更新，显示最近有效价格"} return quote_data

财务模块：数据通常非实时，来自定期财报。关键是要理解用户问的指标口径。比如“市盈率”，是静态PE（股价/最近年报EPS）还是滚动PE（股价/最近四个季度EPS之和）？系统需要内置一个金融指标知识库，将自然语言映射到具体的计算公式和数据字段。

3. 混合检索增强生成（Hybrid RAG）：对于开放性问题（如“分析一下比亚迪电子近期面临的风险”），单纯靠LLM容易胡编乱造。这时需要启动RAG流程：

关键词检索：从query中提取实体（“比亚迪电子”）和关键词（“风险”），在新闻、公告库中进行全文检索，找到相关文档。
语义检索：将query转化为向量，在向量数据库中搜索语义最相近的文本片段（例如，关于供应链风险、毛利率压力的分析师评论段落）。
结果重排序与融合：将两种检索方式的结果合并，根据相关性、时效性进行重排序，选取Top-K个最相关的片段。
提示词工程：将这些片段作为上下文，连同精心设计的Prompt（例如：“你是一名港股分析师，请基于以下提供的真实信息，总结比亚迪电子近期面临的主要风险点。仅使用提供的信息，不要编造。”）一起发送给LLM生成答案。

实操心得：在金融RAG中，引用溯源至关重要。生成的答案最好能注明“根据XX公司于YYYY-MM-DD发布的公告”或“源自XX券商MM月DD日的研报”，这能极大增加可信度，也方便用户追溯核实。可以在Prompt中强制要求LLM在答案中提及信息来源的关键信息。

3.2 数据管道的构建与维护

数据是这类项目的“水电煤”，其管道设计决定了系统的上限。

1. 多源数据接入与归一化：不同的数据源有不同的API格式、更新频率和数据结构。需要为每个数据源编写适配器（Adapter），将原始数据转换为内部统一的数据模型。例如，将所有来源的股票行情数据，都映射为包含symbol,name,price,change,change_percent,volume,timestamp等字段的标准对象。

2. 增量更新与实时性保障：

行情数据：采用WebSocket或长轮询进行订阅，变化时实时推送至消息队列（如Redis Pub/Sub, Kafka），再由消费服务更新缓存和数据库。
基本面数据：财报季更新频繁，可设置定时任务（如每日凌晨）检查并拉取最新公告。
新闻数据：通过RSS订阅或爬虫监控特定页面，发现新内容后触发处理流程。

3. 数据质量监控：必须建立数据质量检查规则。例如：

价格数据是否在合理范围内？（例如，单日涨跌幅超过50%需触发告警人工复核）
财务数据字段是否缺失？
新闻/公告的发布时间是否逻辑正确（未来时间？）可以编写监控脚本，定期运行这些检查，并将异常记录到日志或告警系统。

4. 历史数据存储与回溯：为了支持“过去一年走势”这类查询，需要高效存储历史行情。通常使用时序数据库（如InfluxDB、TimescaleDB）或优化的关系型数据库分区表来存储。这里要考虑数据粒度（1分钟线、日线、周线）和存储成本之间的平衡。

3.3 对话管理与上下文维持

一个实用的对话系统不能是“一问一答”就失忆。用户可能会进行多轮对话，例如：

用户：“腾讯的股价？” 系统：“腾讯控股（00700.HK）当前报价350.2港元，今日上涨2.1%。” 用户：“和美团对比一下呢？” 这时系统需要记住上一轮对话的实体是“腾讯控股”，并在新的上下文中理解用户是想对比“腾讯”和“美团”。

实现方式通常是在后端为每个会话（Session）维护一个上下文窗口。将历史对话（包括用户query和系统answer）以一定方式组织（如拼接成字符串，或存储为消息列表），在每次新的请求时，将最近N轮历史连同新问题一起发送给LLM。需要注意的是，上下文长度有限（如4K、8K、32K tokens），对于长对话需要采用摘要或滑动窗口等策略来压缩历史，保留最关键信息。

4. 从零搭建一个简易原型的实操指南

理解了原理，我们动手搭建一个极度简化的“TradeHKChat”原型，专注于“港股实时行情问答”这个核心功能。这个原型将使用FastAPI、开源LLM（这里用ChatGLM3-6B的API模拟）和雅虎财经数据。

4.1 环境准备与依赖安装

首先，创建一个新的项目目录并初始化虚拟环境。

# 创建项目目录 mkdir tradehkchat_demo && cd tradehkchat_demo # 创建虚拟环境（Python 3.9+） python -m venv venv # 激活虚拟环境 # Windows: venv\Scripts\activate # Linux/Mac: source venv/bin/activate

安装核心依赖。我们使用yfinance获取港股数据（注意：其港股数据可能不全或延迟，仅用于演示），fastapi构建API，uvicorn作为ASGI服务器，requests用于调用LLM API，pydantic用于数据验证。

pip install fastapi uvicorn yfinance requests pydantic python-dotenv

如果计划使用本地部署的ChatGLM等模型，还需要安装对应的库，这里我们简化，假设有一个提供兼容OpenAI API的本地LLM服务端点。

4.2 核心代码实现

我们创建三个主要文件：main.py（主应用）、data_fetcher.py（数据获取）、llm_client.py（LLM交互）。

1. 数据获取层 (data_fetcher.py)这个模块负责从雅虎财经获取股票基本信息。

import yfinance as yf from pydantic import BaseModel from typing import Optional class StockQuote(BaseModel): """统一的股票报价数据模型""" symbol: str name: str current_price: Optional[float] = None change: Optional[float] = None # 涨跌额 change_percent: Optional[float] = None # 涨跌幅 currency: Optional[str] = None last_update: Optional[str] = None def fetch_stock_data(symbol: str) -> Optional[StockQuote]: """ 根据港股代码获取实时行情数据。 注意：yfinance对港股代码需要添加后缀，如‘0700.HK’代表腾讯。 """ try: # 确保代码格式正确 if not symbol.endswith('.HK'): symbol = f"{symbol}.HK" ticker = yf.Ticker(symbol) # 获取快照信息，这里可能不是真正的实时，有延迟 info = ticker.info history = ticker.history(period="1d", interval="1m") if history.empty: return None latest = history.iloc[-1] prev_close = history.iloc[-2]['Close'] if len(history) > 1 else latest['Close'] quote = StockQuote( symbol=symbol, name=info.get('longName', info.get('shortName', symbol)), current_price=round(latest['Close'], 3), change=round(latest['Close'] - prev_close, 3), change_percent=round((latest['Close'] - prev_close) / prev_close * 100, 2), currency=info.get('currency', 'HKD'), last_update=latest.name.strftime('%Y-%m-%d %H:%M:%S') # 时间戳 ) return quote except Exception as e: print(f"Error fetching data for {symbol}: {e}") return None

2. LLM客户端层 (llm_client.py)这个模块负责与LLM API交互，并构造用于理解用户意图和生成答案的Prompt。

import os import requests from typing import Dict, Any # 假设你的本地LLM服务（如Ollama、OpenLLM）地址 LLM_API_BASE = os.getenv("LLM_API_BASE", "http://localhost:11434/v1") LLM_MODEL = os.getenv("LLM_MODEL", "qwen:7b") API_KEY = "your-api-key-if-needed" # 如果是需要密钥的云端服务 class LLMClient: def __init__(self): self.api_base = LLM_API_BASE self.model = LLM_MODEL self.headers = { "Content-Type": "application/json", "Authorization": f"Bearer {API_KEY}" if API_KEY else "" } def generate_response(self, prompt: str, system_prompt: str = None) -> str: """调用LLM生成回复""" messages = [] if system_prompt: messages.append({"role": "system", "content": system_prompt}) messages.append({"role": "user", "content": prompt}) payload = { "model": self.model, "messages": messages, "temperature": 0.1, # 金融回答要求准确性，温度调低 "max_tokens": 500 } try: response = requests.post(f"{self.api_base}/chat/completions", json=payload, headers=self.headers, timeout=30) response.raise_for_status() result = response.json() return result['choices'][0]['message']['content'].strip() except requests.exceptions.RequestException as e: return f"LLM服务调用失败: {e}" except (KeyError, IndexError) as e: return f"解析LLM响应失败: {e}" def extract_stock_symbol(self, user_query: str) -> str: """从用户query中提取港股代码或名称""" system_prompt = """你是一个专业的港股信息处理助手。你的任务是从用户的提问中，精准识别出提到的港股上市公司。 用户可能使用公司简称、全称或代码。你需要输出最可能的港股标准代码（格式如：0700.HK）。 如果无法确定，请输出空字符串。 只输出代码，不要任何解释。""" prompt = f"用户提问：{user_query}\n请提取港股代码：" code = self.generate_response(prompt, system_prompt) # 简单清理，确保是类似`0700.HK`的格式 code = code.strip().upper() if code and not code.endswith('.HK'): # 这里可以加一个映射表，将‘腾讯’映射到‘0700.HK’，简化演示我们直接返回 # 实际项目这里需要一个公司名称-代码的映射数据库 pass return code

3. 主应用与API层 (main.py)这里我们将数据层和LLM层整合，通过FastAPI提供Web服务。

from fastapi import FastAPI, HTTPException from pydantic import BaseModel from typing import Optional from data_fetcher import fetch_stock_data from llm_client import LLMClient import logging logging.basicConfig(level=logging.INFO) app = FastAPI(title="TradeHKChat Demo API", description="港股智能问答原型") llm_client = LLMClient() class QueryRequest(BaseModel): question: str session_id: Optional[str] = None # 用于维持多轮对话，简化版暂未使用 class QueryResponse(BaseModel): answer: str data: Optional[dict] = None # 结构化数据，便于前端展示 symbol: Optional[str] = None @app.post("/query", response_model=QueryResponse) async def handle_query(request: QueryRequest): """ 处理用户关于港股的问答。 1. 用LLM提取股票代码 2. 获取股票数据 3. 组织Prompt让LLM生成友好回答 """ user_question = request.question logging.info(f"收到查询: {user_question}") # 步骤1: 意图识别与代码提取 extracted_symbol = llm_client.extract_stock_symbol(user_question) if not extracted_symbol: # 如果没提取到具体股票，尝试通用回答或告知无法处理 answer = "我目前主要专注于查询港股个股的实时行情信息。您的问题中没有识别到明确的港股公司名称或代码，请尝试像‘腾讯股价多少？’或‘00700.HK今天涨了吗？’这样的提问。" return QueryResponse(answer=answer) # 步骤2: 获取股票数据 stock_quote = fetch_stock_data(extracted_symbol) if not stock_quote: answer = f"未能获取到股票代码 '{extracted_symbol}' 的行情数据，可能是代码有误或数据源暂时不可用。" return QueryResponse(answer=answer, symbol=extracted_symbol) # 步骤3: 生成自然语言回答 system_prompt_for_answer = """你是一个专业的港股投资助手，语气亲切、专业且简洁。根据提供的股票数据，用一两句话回答用户的问题。如果数据中有涨跌幅，请明确说明是上涨还是下跌。务必提及数据更新时间。不要编造任何数据中不存在的信息。""" data_context = f""" 股票名称：{stock_quote.name} 股票代码：{stock_quote.symbol} 当前价格：{stock_quote.current_price} {stock_quote.currency} 涨跌额：{stock_quote.change} {stock_quote.currency} 涨跌幅：{stock_quote.change_percent}% 最后更新时间：{stock_quote.last_update} """ user_prompt_for_answer = f"用户的问题是：{user_question}\n\n相关的股票数据如下：\n{data_context}\n\n请根据以上数据回答用户：" final_answer = llm_client.generate_response(user_prompt_for_answer, system_prompt_for_answer) return QueryResponse( answer=final_answer, data=stock_quote.dict(), symbol=extracted_symbol ) @app.get("/health") async def health_check(): return {"status": "ok"} if __name__ == "__main__": import uvicorn uvicorn.run(app, host="0.0.0.0", port=8000)

4.3 运行与测试

启动LLM服务：确保你的本地LLM服务（例如使用Ollama运行了qwen:7b模型）已经在运行，并提供了兼容OpenAI的API端点（通常是http://localhost:11434/v1）。如果没有，可以暂时注释掉LLM相关代码，用固定回复测试数据流。
启动FastAPI服务：在项目根目录下运行python main.py。
测试API：使用浏览器访问http://localhost:8000/docs查看自动生成的API文档，并在其中测试/query接口。或者使用curl命令：
```
curl -X POST "http://localhost:8000/query" \ -H "Content-Type: application/json" \ -d '{"question": "腾讯控股现在的股价是多少？"}'
```
预期返回：你会得到一个JSON响应，包含由LLM生成的文本回答（如“腾讯控股（00700.HK）当前价格为350.2港元，较前一日上涨2.1%。数据更新于2023-10-27 15:59:59。”）以及结构化的股票数据。

这个原型虽然简陋，但清晰地展示了“用户问句 -> LLM理解意图 -> 获取精准数据 -> LLM组织答案”的核心流程。它离一个真正的“TradeHKChat”还有巨大差距，但构成了最基础的骨架。

5. 生产环境部署与优化考量

一个玩具原型和可供实际使用的服务之间，隔着性能、可靠性、安全性和成本四座大山。

5.1 性能优化策略

缓存无处不在：
- LLM响应缓存：对于相同或高度相似的query（如“腾讯股价”），其答案在短时间内是相同的。可以使用Redis等内存数据库，对LLM的最终输出或中间提取的代码进行缓存，设置合理的TTL（例如行情缓存1分钟，基本面数据缓存1小时）。
- 数据缓存：行情数据、公司基本信息等，都需要多层缓存。在内存（如lru_cache）、Redis、数据库之间形成缓存层级。
异步与非阻塞：FastAPI天生支持异步。所有I/O密集型操作，如网络请求（调用数据API、LLM API）、数据库查询，都应使用async/await，避免阻塞事件循环，从而在高并发下保持高吞吐。
LLM调用优化：
- 流式响应：对于长答案，采用Server-Sent Events (SSE)实现流式输出，让用户边看边等，提升体验。
- 上下文长度管理：严格控制送入LLM的上下文长度。对历史对话进行智能摘要，只保留核心信息。使用更高效的tokenizer。
- 模型蒸馏与量化：考虑使用参数更少、推理更快的蒸馏模型，或对模型进行量化（如GPTQ、AWQ），在精度损失可接受的前提下大幅提升推理速度。

5.2 可靠性保障与监控

降级与熔断：
- 数据源降级：当主数据源（如付费API）不可用时，自动切换到备用源（如免费API或缓存数据），并明确提示用户数据可能延迟。
- LLM服务熔断：如果LLM API连续失败或超时，触发熔断机制，暂时停止调用，返回预设的兜底回答（如“智能分析服务暂时不可用，当前股价为XXX”），并告警。
完备的日志与监控：记录每一个用户query、提取的代码、调用的数据源、LLM请求与响应、处理耗时、错误信息。使用Prometheus+Grafana监控API的QPS、延迟、错误率。监控关键数据源的可用性。
数据一致性校验：定期运行数据校验任务，对比不同数据源对同一只股票的关键指标（如收盘价）是否一致，偏差过大则告警。

5.3 安全与合规要点

这是金融类应用的生命线。

输入验证与净化：对所有用户输入进行严格的验证和净化，防止SQL注入、Prompt注入等攻击。例如，限制query长度，过滤特殊字符。
访问控制与限流：实现API密钥认证，并对不同用户等级进行限流（如免费用户每分钟10次请求，VIP用户每分钟100次）。防止恶意爬取和DDoS攻击。
内容安全审核：对LLM生成的内容进行二次审核，过滤任何不当、误导性或可能涉及市场操纵的言论。可以接入一个轻量级的文本审核模型或规则引擎。
合规声明：在应用显著位置添加免责声明，明确指出数据来源、可能存在延迟，所有分析仅供参考，不构成投资建议。确保符合相关地区的金融信息服务法规。

5.4 成本控制

LLM API成本：如果使用按token收费的云端LLM API，成本是主要考量。可以通过以下方式控制：
- 优化Prompt：设计更精准、简短的Prompt，减少不必要的上下文。
- 缓存：如前所述，缓存是节省成本最有效的手段。
- 使用小型/专用模型：对于简单的意图识别、实体提取任务，可以使用参数量小得多的模型（如BERT），而不是每次都调用通才大模型。
数据源成本：专业金融数据极其昂贵。在项目早期，可以混合使用免费/开源数据与关键付费数据。明确核心功能对数据质量的要求，将钱花在刀刃上。

6. 常见问题与实战避坑指南

在实际开发和运营这类系统的过程中，我踩过不少坑，也总结了一些经验。

6.1 数据准确性陷阱

问题：不同数据源对同一指标（如总股本、调整后收盘价）的计算口径不同，导致结果不一致。
排查：建立数据交叉验证机制。定期用Wind/ Bloomberg（如果可用）的数据作为基准，对比自家数据。对于关键指标，记录数据来源和计算公式。
技巧：在向用户展示数据时，如果条件允许，可以注明数据来源和更新频率（如“数据来源：XX数据，每15秒更新”），管理用户预期。

6.2 LLM的“幻觉”与胡说八道

问题：LLM可能编造不存在的财务数据、杜撰新闻事件，或者对市场走势做出毫无根据的预测。
策略：
1. 严格RAG：坚持“答案尽可能源于检索到的文档”原则。在Prompt中强烈约束模型：“仅使用以下提供的信息回答问题，如果信息不足，请明确说‘根据已有信息无法回答’。”
2. 确定性计算优先：对于量化问题（如“涨了多少”、“市盈率多少”），用代码计算好结果，让LLM只负责“转述”和“格式化”，而不是“计算”。
3. 后处理校验：对LLM生成的答案，尝试从中反向提取关键数据点（如价格、百分比），与原始数据核对是否一致。

6.3 处理模糊与歧义查询

问题：用户问“苹果怎么样？”可能指苹果公司（AAPL）或水果，在港股语境下也可能指“苹果概念股”。
策略：实现一个澄清机制。当系统置信度不高时，可以反问用户：“您是指苹果公司（AAPL，美股），还是港股相关的苹果供应链公司呢？”这比给出一个错误答案体验更好。可以通过LLM生成几个最可能的选项供用户选择。

6.4 性能瓶颈定位

问题：用户反馈回答慢。
排查流程：
1. 查看监控，确定是普遍慢还是个别query慢。
2. 分析日志，统计各环节耗时：意图识别、数据获取、LLM生成。
3. 最常见的瓶颈是LLM调用。检查LLM服务的响应时间，考虑增加超时设置、启用缓存、升级模型实例。
4. 如果是数据获取慢，检查数据源API状态，考虑增加本地缓存层级。

6.5 港股市场的特殊处理

代码转换：用户可能输入“9988”、“09988”、“9988.HK”或“阿里巴巴”，系统内部需要统一映射到“09988.HK”。维护一个包含股票代码、名称、常用简称的映射表至关重要。
繁体字与术语：港股信息很多是繁体中文。LLM需要能正确处理繁简体混合输入和输出。在微调或Prompt中，可以加入相关示例。
市场规则：如港股通交易时间、印花税、一手股数等。在回答相关问题时（如“买一手腾讯要多少钱？”），需要准确计算并提示相关规则，这需要将市场规则知识固化到系统中。

开发一个像TradeHKChat这样的项目，是一个典型的“端到端”AI系统工程，它考验的不仅是机器学习算法能力，更是对业务（港股市场）的理解、数据工程、软件架构和产品思维的全面融合。从简单的原型到稳定可靠的服务，每一步都需要扎实的工程化和持续的迭代优化。希望这份拆解能为你提供一些有价值的思路和避坑参考。