Langchain-Chatchat航班信息查询：整合时刻表与票价数据

Langchain-Chatchat航班信息查询：整合时刻表与票价数据

在航空公司客服中心，一个常见的场景是：客户来电询问“明天北京飞上海最早一班经济舱多少钱”，坐席人员需要依次打开航班时刻表、运价文件、促销公告等多个文档进行比对。这个过程不仅耗时，还容易因人为疏忽导致报价错误。而如今，借助 Langchain-Chatchat 这类本地化知识库问答系统，只需一句话提问，系统就能秒级返回准确答案，并附带来源依据——这一切都不依赖云端服务，所有数据始终留在企业内网。

这背后的技术组合正悄然改变着传统行业对AI的认知：不是非得用大模型“猜”答案，而是让大模型基于真实文档“读”出答案。以航班信息查询为例，我们将深入探讨如何通过 Langchain-Chatchat 实现结构化与非结构化数据的统一语义检索，构建高可信度的智能问答能力。

整个系统的基石在于检索增强生成（RAG）架构。它不像纯生成式模型那样“凭空编造”，而是先从私有文档中找出最相关的片段，再由大语言模型结合上下文生成回答。这种方式既保留了LLM强大的自然语言理解能力，又规避了其“幻觉”问题，在航空、金融等对准确性要求极高的领域尤为重要。

要实现这一目标，Langchain-Chatchat 提供了一套完整的端到端流程。首先是文档加载环节。系统支持多种格式输入，比如PDF版的航班时刻表、Word写的票价政策通知、Excel中的临时调价记录等。这些文件会被统一解析为纯文本内容：

from langchain.document_loaders import PyPDFLoader, Docx2txtLoader, UnstructuredExcelLoader # 多类型文档加载 loaders = [ PyPDFLoader("flight_schedule.pdf"), Docx2txtLoader("fare_policy.docx"), UnstructuredExcelLoader("promo_rates.xlsx") ] documents = [] for loader in loaders: documents.extend(loader.load())

接下来是文本切分。由于原始文档往往很长，直接嵌入会导致语义丢失或计算负担过重。因此需要将文本按语义边界合理分块。常用的RecursiveCharacterTextSplitter会优先按照段落、句子进行切割，并设置一定的重叠区域（chunk_overlap），确保关键信息不会被截断：

from langchain.text_splitter import RecursiveCharacterTextSplitter text_splitter = RecursiveCharacterTextSplitter( chunk_size=500, chunk_overlap=50, separators=["\n\n", "\n", "。", "！", "？", "；", " ", ""] ) texts = text_splitter.split_documents(documents)

值得注意的是，对于航班时刻这类高度结构化的表格数据，简单的字符分割可能破坏行间逻辑。此时可考虑使用UnstructuredChunkingStrategy或自定义解析器，先提取表格结构再转化为自然语言描述，例如：“2024年6月18日，CA1831航班，北京首都T3 → 上海虹桥T2，起飞时间07:30，到达时间09:45，经济舱票价¥1080”。

完成文本预处理后，进入向量化阶段。这里的关键是选择适合中文语境的嵌入模型。BAAI开源的bge-small-zh-v1.5在多个中文 benchmarks 中表现优异，且资源消耗较低，非常适合部署在本地服务器：

from langchain.embeddings import HuggingFaceEmbeddings embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-small-zh-v1.5")

随后，将所有文本块编码为向量并存入本地向量数据库。FAISS 是 Facebook 开源的高效相似性搜索库，能够在毫秒级完成百万级向量的近似最近邻查找，非常适合中小规模知识库：

from langchain.vectorstores import FAISS db = FAISS.from_documents(texts, embeddings) db.save_local("vectorstore/faiss_index") # 保存索引供后续加载

当用户发起查询时，系统首先将问题本身也转换为向量，然后在向量空间中寻找语义最接近的几个文档片段。这种“语义搜索”能力远超传统的关键词匹配——即便用户问的是“京沪线最早的那趟飞机几点走”，也能准确命中“北京至上海 起飞时间 07:30”的记录。

最终的答案生成依赖于本地部署的大语言模型。以 ChatGLM3 为例，可通过 llama.cpp 将其量化后运行在 CPU 上，大幅降低硬件门槛：

# 将 Hugging Face 模型转换为 GGUF 格式 python convert_hf_to_gguf.py THUDM/chatglm3-6b --outfile chatglm3-6b.gguf --quantize q4_0 # 启动本地推理服务 ./server -m ./chatglm3-6b.gguf -c 2048 --port 8000

Python 端通过 LangChain 接口调用该服务：

from langchain.llms import ChatGLM llm = ChatGLM( endpoint_url="http://127.0.0.1:8000", max_token=8192, temperature=0.1 )

为了让模型更专注于“查文档”而非“自由发挥”，我们需要精心设计提示词模板（Prompt Engineering）。一个好的 Prompt 应明确指示模型的行为边界：

from langchain.prompts import PromptTemplate custom_prompt_template = """ 你是一个专业的航班信息查询助手。 请根据以下上下文回答问题，不要编造信息。 如果无法从中找到答案，请回答“暂无相关信息”。 上下文: {context} 问题: {question} 答案: """ PROMPT = PromptTemplate(template=custom_prompt_template, input_variables=["context", "question"])

最后，将各组件串联成一条完整的问答链：

from langchain.chains import RetrievalQA qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", retriever=db.as_retriever(search_kwargs={"k": 3}), chain_type_kwargs={"prompt": PROMPT}, return_source_documents=True ) # 执行查询 query = "明天北京飞上海的最早航班是几点？" result = qa_chain({"query": query}) print("答案:", result["result"]) print("来源文档:", [doc.metadata['source'] for doc in result["source_documents"]])

这套流程看似简单，但在实际工程中仍有不少细节值得推敲。例如，在航班业务中，“明天”是一个动态时间概念，必须结合当前日期解析为具体年月日。若不加处理，模型可能会误解为字面意义的“明”天。为此，可以在预处理阶段引入时间归一化模块：

import datetime def normalize_time_in_query(query: str) -> str: today = datetime.date.today() tomorrow = today + datetime.timedelta(days=1) return query.replace("明天", tomorrow.strftime("%Y年%m月%d日")) # 查询前处理 normalized_query = normalize_time_in_query(user_query)

另一个常见问题是多条件联合查询，如“广州飞成都下周三最低价”。这类问题涉及两个独立信息维度：航班时刻和运价策略，可能分散在不同文档中。为了提升召回率，可以采用多路检索融合策略：分别针对“航线+日期”和“票价类型”生成多个查询向量，合并检索结果后再送入模型综合判断。

此外，考虑到航班数据更新频繁，静态索引难以满足时效性需求。建议建立自动化更新机制：

import schedule import time def refresh_knowledge_base(): # 定时重新加载最新文档并重建索引 print("开始更新知识库...") rebuild_vectorstore() print("知识库更新完成") # 每日凌晨2点执行 schedule.every().day.at("02:00").do(refresh_knowledge_base) while True: schedule.run_pending() time.sleep(60)

对于性能敏感的场景，还可进一步优化：
- 使用 GPU 加速嵌入模型推理（如 Sentence-BERT on CUDA）
- 对高频问题启用 Redis 缓存，避免重复检索
- 采用增量更新策略，仅处理新增或修改的文件

权限控制也不容忽视。不同角色应访问不同级别的信息：普通客服只能查看公开票价，而管理人员可查询协议客户折扣。这可通过过滤器实现：

def get_retriever_by_role(role): if role == "admin": return db.as_retriever() else: return db.as_retriever( search_kwargs={ "filter": {"source": ["public_fares.pdf", "general_policy.docx"]} } }

回看整个系统架构，其核心价值不仅在于技术先进性，更在于解决了企业在拥抱AI时的根本顾虑：数据不出门、响应够快、结果可信。相比调用公有云API，本地部署杜绝了隐私泄露风险；相比传统信息系统，语义理解能力显著提升了交互效率。

未来，随着轻量化模型（如 Qwen-Max、Phi-3）和高效向量引擎（如 Chroma、LanceDB）的发展，这类系统的部署成本将进一步降低。我们甚至可以看到更多创新应用：
- 结合语音识别，实现电话客服自动应答
- 集成到企业微信/钉钉，作为员工日常查询工具
- 与CRM系统联动，根据客户等级动态调整回答粒度

这种高度集成的设计思路，正引领着垂直行业智能化升级的方向——不再追求通用智能，而是聚焦特定任务，打造安全、精准、可解释的专业AI助手。