基于Ziya-LLaMA-13B-V1与LoRA微调构建中医古籍问答大模型实践

简介大语言模型通过在海量文本数据上进行预训练获得了强大的语言理解和生成能力。其核心原理是基于Transformer架构的自注意力机制能够捕捉长距离的语义依赖关系。这种技术价值在于能够将通用语言能力迁移到特定垂直领域实现知识的自动化问答与辅助分析。在医疗、法律、金融等专业知识密集型场景中领域大模型可以显著提升信息检索和知识服务的效率。本文聚焦于中医古籍这一独特领域探讨如何利用参数高效微调技术将通用基座模型转化为精通《黄帝内经》、《伤寒论》等典籍的专用模型。通过构建高质量的指令微调数据集并采用LoRA技术进行轻量化适配有效提升了模型对古汉语术语和中医辨证逻辑的理解。结合检索增强生成RAG架构进一步确保了回答的准确性与文献依据为传统文化典籍的数字化传承与智能化研究提供了可行的工程实践路径。1. 项目缘起当大模型遇见千年医典最近在整理本地模型仓库时翻出了一个挺有意思的项目——黄帝模型。这名字听着就很有分量它本质上是一个基于Ziya-LLaMA-13B-V1基座模型专门针对中医古籍知识进行微调后得到的问答大模型。简单来说就是让一个现代AI去学习《黄帝内经》、《伤寒论》、《金匮要略》这些流传千年的典籍然后尝试回答我们关于中医理论、方剂、经络、养生等方面的问题。这个想法其实由来已久。AI大模型在通用领域的表现已经让人惊叹但在垂直专业领域尤其是像中医这样蕴含深厚哲学思想、术语体系独特、且知识高度非结构化的领域通用模型往往力不从心。它们可能会生成一些看似通顺、实则似是而非甚至包含现代医学概念混杂的“幻觉”答案。这对于严肃的知识传承和应用来说是致命的。因此构建一个“懂行”的、扎根于中医原典知识体系的大模型就成了一件既有挑战又有价值的事情。黄帝模型正是这个方向上的一个具体实践。它不是一个凭空创造的新架构而是选择了在中文理解上表现不错的Ziya-LLaMA-13B-V1作为起点。13B的参数量在保证一定推理能力的同时对算力资源的要求相对友好更适合个人研究者或中小团队进行本地化部署和探索。项目的核心在于如何将浩如烟海、文辞古奥的中医古籍知识“喂”给模型并让它真正理解而非简单记忆。2. 基座选择为什么是Ziya-LLaMA-13B-V1在启动一个垂直领域大模型项目时基座模型的选择是第一个关键决策。市面上开源的中文大模型不少为何在这个中医古籍项目里Ziya-LLaMA-13B-V1成为了起点这背后有几个很实际的考量。首先中文原生能力是硬门槛。中医古籍全是文言文虽然现代人做了很多白话翻译和注解但模型要深度理解必须对古汉语的语法、词汇、句式有良好的先验知识。Ziya系列模型基于LLaMA架构但在高质量的中文语料上进行了充分的继续预训练Continue Pre-training。这意味着它的词表中包含了更丰富的中文字符和词语分布在理解“阴阳”、“五行”、“营卫”、“津液”这类专业术语以及“之乎者也”等文言虚词时比那些主要用英文语料训练、再通过翻译数据适配中文的模型有着天然的底层优势。实测中直接用原始LLaMA或某些侧重代码的模型去读古文经常会出现断词错误、语义混淆的问题。其次13B参数量是一个“甜点”区间。参数量太小如7B模型的理解和推理能力可能不足以处理中医典籍中复杂的逻辑关系如辨证论治的推理链条。参数量太大如33B、70B虽然能力更强但对显存的要求呈指数级增长训练和推理成本高昂不利于快速迭代和本地部署。13B的模型在24GB显存的消费级显卡如RTX 4090上已经可以进行量化后的高效推理甚至进行轻量级的参数高效微调PEFT这让个人开发者和小型团队有了动手实践的可能性。再者Ziya-LLaMA-13B-V1的社区生态和工具链相对成熟。作为国内较早开源的中文LLaMA衍生模型其模型格式通常是Hugging Face Transformers兼容的、相关的训练和推理脚本、以及量化方案等都有较多的社区讨论和实践案例可循。这对于一个需要大量实验和调试的领域微调项目来说能节省大量在环境配置、代码适配上的“踩坑”时间。你可以更专注于核心的数据处理和微调策略本身。当然这个选择并非没有妥协。相比于一些更新的、在数学或代码上更强的专用模型Ziya在逻辑推理和复杂指令跟随上可能不是最强的。但对于中医古籍问答这个任务核心是知识的准确提取、关联和符合典籍原意的表述而非复杂的数学计算或编程。因此优秀的中文语言先验知识和适中的规模使其成为一个务实且有效的起点。3. 数据工程给AI“喂”什么它才能成为“老中医”模型的能力上限很大程度上由训练数据决定。要让一个现代AI理解中医古籍数据工程是整个项目最耗时、也最见功力的部分。这远不是简单地把古籍TXT文件扔给模型就能解决的。3.1 数据来源与清洗数据主要来源于两个部分一是中医经典原典的数字化文本如《黄帝内经》素问、灵枢、《伤寒杂病论》含伤寒论、金匮要略、《温病条辨》、《神农本草经》等。这些是核心知识源必须保证版本的权威性和文字的准确性。通常可以从专业古籍数据库或经过校勘的电子版获取。二是高质量的现代释义与问答对。包括权威中医院校的教材、名老中医的医案解读、以及针对古籍条文的高质量问答数据。这部分数据的作用是构建“桥梁”帮助模型建立古文与现代语义、以及问题与答案之间的映射关系。清洗过程异常繁琐去除非正文内容去除古籍中的页码、校勘记、纯格式符号等。统一文字格式将繁体字统一转为简体或保留繁体但需一致处理异体字统一标点符号古书常无标点需进行智能断句和标点补充这是一项专业工作。分篇章与段落按照原书的篇章结构进行分割形成有语义的独立段落。这对于后续构建检索和上下文理解至关重要。构建结构化知识尝试从文本中提取实体如药材“桂枝”、方剂“桂枝汤”、穴位“足三里”、病证“太阳中风”和关系如“桂枝汤主治太阳中风”、“桂枝性味辛甘温”形成知识图谱的雏形。这可以作为辅助信息注入训练但非必需。3.2 数据格式与任务构建微调阶段我们主要采用指令微调Instruction Tuning的方式。这意味着我们需要将知识包装成“指令-输入-输出”的格式。指令Instruction明确告诉模型任务是什么。例如“请根据《黄帝内经》的知识回答以下问题。”或“请解释以下中医术语的含义。”输入Input具体的问题或上下文。例如“什么是‘正气存内邪不可干’”或“请分析《伤寒论》中‘桂枝汤’的组成、功效和主治证型。”输出Output高质量的、基于典籍的答案。答案应尽量引用原文然后给出准确的现代文解释避免臆测和添加现代医学概念。构建高质量的问答对是关键。一种方法是基于篇章的自问自答给定一段古籍原文让专家或利用一些规则生成可能的问题和答案。例如针对“帝曰阴阳者天地之道也万物之纲纪变化之父母生杀之本始神明之府也。治病必求于本。”这段可以生成问题“《素问·阴阳应象大论》中如何论述阴阳的重要性”答案则引用原文并解释“本”即指阴阳。另一种方法是利用现有的医案和教材。医案通常包含“症状-辨证-治法-方药”的完整逻辑链可以构建多轮问答。教材中的章节小结和思考题也是很好的问答对来源。注意数据质量远大于数据数量。1000条由领域专家精心构建的问答对其效果可能远好于10万条从互联网爬取的、质量参差不齐的数据。中医领域尤其忌讳“数据垃圾进模型垃圾出”一个错误的药性描述可能会造成严重后果。3.3 应对“AI幻觉”的数据策略“AI幻觉”是大模型生成不符合事实或输入内容的信息的通病。在中医领域幻觉可能表现为混淆不同典籍的观点、杜撰不存在的方剂或药性、用现代西医理论强行解释中医概念。为了抑制幻觉在数据层面我们采取了以下措施答案锚定在输出中强烈鼓励甚至强制要求模型在给出解释前先引用最相关的原始典籍原文。例如“根据《伤寒论》第12条‘太阳中风阳浮而阴弱阳浮者热自发阴弱者汗自出……桂枝汤主之。’ 因此桂枝汤主治太阳中风证其病机是营卫不和...” 这样就把模型的输出“锚定”在了确切的原文上减少了信口开河的空间。设置知识边界在指令中明确模型的角色和知识范围。例如在指令开头加入“你是一个专注于中医古籍知识问答的助手你的知识严格来源于以下经典《黄帝内经》、《伤寒论》、《金匮要略》、《神农本草经》。对于经典中未明确记载的内容你应回答‘根据所载典籍暂未明确提及’或引导用户咨询专业医师。” 这相当于给模型划定了“作业范围”。负样本训练故意构造一些包含常见错误或幻觉的答案作为负样本在训练中让模型学会区分。例如输入一个关于“黄芪”功效的问题正样本是基于《神农本草经》的描述负样本则混入“黄芪有直接的降压作用”这是现代药理研究结论古籍无载这样的错误信息让模型学会拒绝生成这类超出古籍范围的断言。4. 模型微调让通用模型“专精”古籍问答有了高质量的数据下一步就是通过微调将Ziya-LLaMA-13B-V1这个“通才”变成精通中医古籍的“专才”。微调的核心目标是让模型掌握两项能力精准的古文理解能力和符合典籍规范的问答生成能力。4.1 微调方法选择对于13B量级的模型全参数微调Full Fine-tuning消耗的资源依然很大。因此参数高效微调PEFT是更主流和实用的选择。具体来说LoRALow-Rank Adaptation技术因其高效和便捷成为了本项目的首选。LoRA的原理是在原始模型的大型权重矩阵旁添加一个低秩Low-Rank的适配器矩阵。在微调时冻结原始模型的所有参数只训练这些新增的、参数量很小的适配器。这样做的优势非常明显显存占用低通常只需训练原模型参数量的0.1%-1%使得在单张高端消费级显卡上微调13B模型成为可能。训练速度快需要更新的参数少训练周期大幅缩短。模型切换灵活训练得到的LoRA权重文件很小几十到几百MB可以像插件一样轻松加载或卸载方便我们针对不同典籍或任务训练不同的LoRA模块按需组合使用。在Hugging Face的PEFT库中实现LoRA微调已经非常方便。关键的超参数设置包括r秩决定适配器矩阵的大小通常设置在8-64之间。对于中医文本我们尝试了r16和32发现r32时模型对复杂古文的理解和生成稳定性稍好。lora_alpha缩放因子一般设置为r的两倍左右如32或64。target_modules指定将LoRA适配器添加到哪些类型的模型层。通常选择注意力Attention机制中的查询q_proj、键k_proj、值v_proj和输出o_proj投影层有时也会包括全连接层如MLP中的gate_proj, down_proj, up_proj。我们的实验表明在中医文本上对q_proj和v_proj进行适配效果最为显著。4.2 训练流程与技巧训练代码框架主要基于Transformers和PEFT库。一个典型的训练循环包括加载基座模型和分词器加载Ziya-LLaMA-13B-V1。配置LoRA参数通过PEFT的LoraConfig类进行设置。准备数据集将清洗好的指令数据通过分词器处理成模型输入所需的input_ids、attention_mask等格式。这里需要注意统一对话模板例如采用类似[INST] SYS\n{系统指令}\n/SYS\n\n{用户问题} [/INST] {模型答案}的格式与基座模型预训练时的格式保持一致能获得更好的效果。设置训练参数使用TrainingArguments关键参数包括per_device_train_batch_size根据显存调整24G显存下可设为2-4。gradient_accumulation_steps通过梯度累积来模拟更大的批次大小。learning_rateLoRA微调的学习率通常设置得较小如1e-4到5e-5。num_train_epochs3-5个epoch通常足够需要监控验证集损失防止过拟合。warmup_steps设置一定的预热步数有助于训练稳定。开始训练使用TrainerAPI进行训练。在实际训练中有几个针对中医文本的技巧损失函数侧重除了标准的语言建模损失预测下一个词可以尝试对答案中引用原文的部分给予更高的权重或者在计算损失时只计算答案部分忽略指令和问题部分这能迫使模型更专注于生成高质量的答案内容。长文本处理中医古籍的上下文可能很长。需要合理设置max_length并确保模型能够处理长序列。Ziya-LLaMA本身支持4K上下文但对于更长的医案分析可能需要采用滑动窗口或检索增强生成RAG的策略这在推理阶段更为重要。阶段性训练可以先在“古文-现代文”平行语料上进行一轮轻量微调提升模型的古文翻译和理解能力然后再在问答数据上进行指令微调。这种两阶段法有时比直接混合训练效果更好。5. 本地部署与推理实践模型训练好后最终要落地使用。对于个人或内部研究场景本地部署是最直接、可控的方式。这里分享基于Ollama和LangChain搭建本地问答服务的实践。5.1 模型量化与转换原始的13B FP16模型需要约26GB显存远超大多数个人电脑的显卡容量。因此量化Quantization是必须的步骤。我们将训练好的模型基座模型 LoRA权重合并并转换为量化格式。常用的量化方案有GGUF格式搭配llama.cpp和GPTQ/AWQ格式。这里我们选择GGUF格式因为它对CPU推理更友好且在不同硬件上兼容性好。使用llama.cpp项目中的convert.py和quantize工具可以将模型量化为4位Q4_K_M或5位Q5_K_M精度。Q4_K_M模型大小约7-8GBQ5_K_M约9-10GB在保证精度损失可接受的前提下能顺畅地在16GB内存的电脑上运行如果有一张8GB以上显存的显卡速度会更快。转换合并的关键命令如下示意# 1. 合并LoRA权重到基座模型 python scripts/merge_peft_adapters.py --base_model path/to/ziya-13b --peft_model path/to/lora-checkpoint --output_dir path/to/merged-model # 2. 将合并后的模型转换为GGUF支持的FP16格式 python llama.cpp/convert.py path/to/merged-model --outfile path/to/merged-model/ggml-model-f16.gguf --outtype f16 # 3. 量化以Q4_K_M为例 ./llama.cpp/quantize path/to/merged-model/ggml-model-f16.gguf path/to/huangdi-model-q4_k_m.gguf Q4_K_M5.2 使用Ollama创建模型服务Ollama是一个强大的本地大模型运行和管理的工具它简化了模型加载、服务暴露的过程。首先我们需要为合并量化后的模型创建一个Ollama Modelfile。这是一个定义模型配置的文本文件FROM ./huangdi-model-q4_k_m.gguf # 设置系统提示词强化模型角色和知识边界 SYSTEM 你是一位精通《黄帝内经》、《伤寒论》、《金匮要略》、《神农本草经》等中医经典的古籍知识专家。你的回答必须严格基于这些经典的原意。对于经典中未明确记载的内容你应如实说明。请先引用相关原文再进行解释。 # 设置温度等参数 PARAMETER temperature 0.2 # 较低的温度使输出更确定、更少随机性适合知识问答 PARAMETER top_p 0.9 PARAMETER num_ctx 4096 # 上下文长度 TEMPLATE [INST] SYS {{ .System }} /SYS {{ .Prompt }} [/INST]然后使用Ollama创建并运行模型ollama create huangdi -f ./Modelfile ollama run huangdi这样一个名为“huangdi”的模型服务就在本地运行起来了它通过API默认在11434端口提供服务。5.3 构建基于LangChain的问答应用单纯运行模型还不够我们需要一个更智能的应用来处理用户问题尤其是当问题涉及模型知识库之外或需要精确检索时。检索增强生成RAG是解决这个问题的利器。LangChain框架能很好地编排整个流程。整个应用的架构如下知识库构建将所有中医古籍原文分段后进行向量化嵌入Embedding。我们选用text-embedding-3-small或开源的BGE-M3模型将每一段文本转换为一个高维向量存入向量数据库如ChromaDB、Milvus。问答流程用户提问例如“风寒感冒初期有什么经典的方子”检索将用户问题也转换为向量在向量数据库中搜索与之最相关的几段古籍原文例如《伤寒论》中关于“太阳病头痛发热身疼腰痛骨节疼痛恶风无汗而喘者麻黄汤主之”的条文。构建增强提示将检索到的相关原文作为“上下文”和用户原始问题一起构造成新的提示词发送给本地运行的“黄帝模型”。模型生成模型基于增强后的提示包含了确切的原文依据生成答案。输出返回给用户一个既有原文引用又有准确解释的答案。使用LangChain核心代码逻辑非常清晰from langchain_community.vectorstores import Chroma from langchain_community.embeddings import HuggingFaceEmbeddings from langchain_community.llms import Ollama from langchain.chains import RetrievalQA # 1. 加载向量数据库 embedding_model HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) vectorstore Chroma(persist_directory./huangdi_chroma_db, embedding_functionembedding_model) # 2. 连接本地Ollama模型 llm Ollama(modelhuangdi, base_urlhttp://localhost:11434) # 3. 创建检索问答链 qa_chain RetrievalQA.from_chain_type( llmllm, chain_typestuff, # 简单地将所有检索到的文档拼接到提示中 retrievervectorstore.as_retriever(search_kwargs{k: 3}), # 检索最相关的3段 return_source_documentsTrue # 返回来源文档方便查验 ) # 4. 提问 question 风寒感冒初期有什么经典的方子 result qa_chain.invoke({query: question}) print(回答, result[result]) print(\n参考来源) for doc in result[source_documents]: print(f- {doc.page_content[:200]}...) # 打印来源片段这个流程极大地缓解了模型的“幻觉”问题因为答案有了确切的文献支撑。同时它也扩展了模型的知识边界理论上只要向量数据库中有的内容模型都能参考回答而不局限于其训练数据。6. 效果评估与典型问题分析模型部署后需要进行系统的评估。对于领域模型不能只看通顺度更要看准确性、专业性和安全性。6.1 构建评估集我们从几个维度构建测试集原文释义直接询问某句经文的含义。评估模型是否准确理解并解释。方剂问答询问方剂的组成、功效、主治。评估模型是否混淆相似方剂如桂枝汤 vs 桂枝加葛根汤。辨证推理给出一组症状询问可能的证型和治法。评估模型的逻辑推理能力。术语解释询问“卫气营血”、“六经辨证”等专业术语。边界测试询问现代医学疾病如“高血压”、或古籍中肯定没有的概念如“新冠病毒”评估模型是否会胡编乱造或给出不安全的医疗建议。6.2 效果展示与问题分析在测试中黄帝模型展现出了不错的专业素养优点对于有明确原文依据的问题回答准确能熟练引用原文。例如问“桂枝汤的组成”它能准确回答“桂枝、芍药、甘草炙、生姜、大枣”并引用《伤寒论》条文。对古文的理解到位能准确将“恶寒”、“发热”、“汗出”等术语与现代语义对应。在系统提示词的约束下对于超出古籍范围的问题大部分时候能克制地回答“此内容在所学经典中未有明确记载”避免了严重幻觉。存在的问题与挑战推理深度有限对于需要多步复杂辨证的问题模型有时会流于表面抓不住主症。例如面对一组寒热错杂的症状它可能只是罗列了多种可能性而缺乏一个有力的、符合“辨证论治”逻辑的推理链条。这受限于13B模型的推理能力和训练数据的深度。方剂加减不灵活当被问到“如果患者有汗出但还有项背强几几该用什么方”时理想的答案应联想到“桂枝加葛根汤”。模型有时能答对但有时只会重复“桂枝汤”的主治缺乏灵活的方剂加减思维。这需要更大量的、包含方剂变化逻辑的医案数据进行训练。对“以方测证”等高级思维掌握不足中医思维如“以方测证”通过方剂反推病机、“异病同治”等是高级的抽象和类比能力。当前模型在这类任务上表现不稳定这可能是未来需要突破的方向。长上下文依赖虽然采用了RAG但当问题需要综合多篇条文才能回答时简单的检索拼接可能导致上下文过长或信息冗余影响生成质量。需要更智能的检索和信息压缩技术。6.3 与通用模型的对比我们对比了黄帝模型与通用版Ziya-LLaMA-13B-V1在相同中医问题上的表现。通用模型经常出现以下问题混淆时代用明清时期才成熟的理论去解释《内经》的概念。中西混搭在解释“上火”时可能会提到“炎症因子”。杜撰内容可能会生成一个听起来合理、但典籍中根本不存在的“古方”。安全性风险在未明确提示的情况下可能对疾病给出具体的治疗建议这是非常危险的。黄帝模型通过领域微调和RAG在这些方面有质的改善。它更像一个“严谨的古籍研究员”而通用模型则像一个“知识广博但口无遮拦的杂家”。7. 总结与未来展望构建“黄帝模型”的过程是一次将现代AI技术与传统中医知识深度结合的尝试。整个过程下来最深的体会是在垂直领域数据质量、领域知识和任务定义的重要性远大于模型本身的规模。一个精心设计的、高质量的、贴合领域思维模式的数据集配合适当的微调方法能让一个中等规模的模型焕发出巨大的专业潜力。本地部署的RAG方案为知识密集型垂直大模型的应用提供了一个务实且高效的范式。它既利用了预训练大模型强大的语言理解和生成能力又通过外部知识库保证了信息的准确性和时效性还降低了对模型参数量的硬性要求。这个项目目前仍是一个“仓库”中的原型有许多可以深化的方向知识图谱融合将中医的实体和关系结构化构建一个真正的知识图谱。在问答时可以先通过图谱进行精确的逻辑查询和推理再将结果用大模型润色生成可进一步提升答案的准确性和逻辑性。多模态扩展中医包含舌象、脉象、药材图像等丰富信息。未来可以探索多模态大模型实现“舌象图片症状描述”到“辨证分析”的跨越。交互式辨证训练构建模拟医患问答的交互环境训练模型通过多轮提问来收集信息逐步完成辨证这更贴近真实的临床思维过程。轻量化与移动端部署探索更极致的量化如3bit和模型压缩技术让这个“AI老中医”能够跑在手机或边缘设备上提供随时随地的古籍查询辅助。最后必须强调无论模型表现多么出色它都绝不能替代真正的医师。它的定位始终是辅助学习、提供古籍检索和初步分析的智能工具是连接古老智慧与现代学习者的桥梁而非决策主体。在涉及任何实际健康问题时务必咨询专业医疗人员。技术探索的乐趣在于过程而知识的传承与应用永远需要怀有敬畏之心。本文还有配套的精品资源点击获取