简介基于Ziya-LLaMA-13B-V1的中医古籍知识问答大模型仓库面向AI大模型应用开发者、自然语言处理研究人员及中医信息化从业者旨在解决中医古籍智能问答、模型微调与部署落地等问题。压缩包共54个文件约150KB以Python脚本22个.py与22个.pyc为主体覆盖SFT、PPO、PT等多种训练模式训练与推理脚本齐备数据预处理与评估工具也一应俱全并提供了多种交互方式另有5个Shell一键脚本预训练、评估等、2个YAML配置、JSON示例、License和说明文档目录结构清晰便于按模块复用。已有673人学习下载适合希望快速上手中医大模型项目的中高级开发者。通过该仓库可完整看到从数据准备、模型训练、推理评估到服务部署的中医古籍问答工程链路随手调整配置即可运行是实践大模型领域应用的高性价比参考。1. 为什么一份基于Ziya-LLaMA-13B-V1的中医古籍问答模型仓库值得拆开看把《伤寒论》里“太阳病项背强几几反汗出恶风者桂枝加葛根汤主之”输进通用大模型你能得到一段看似通顺的解释但没人能确认它到底读过原文还是从百科词条里临时拼出来的。基于Ziya-LLaMA-13B-V1的中医古籍知识问答大模型也就是这套黄帝(Huang-Di)模型仓库想解决的正是这类垂直问答里“要原文、要出处、要专业感”的痛点。对中医药信息化开发者、高校古籍数字化项目、以及不想把病历数据传云的私有化部署团队来说这份zip代表了一条可复现的路径在中文巨型基座上做古籍指令微调再用一套可调的生成参数约束输出。下面按“选型→加载→推理→微调→排错→验收”的顺序把这套方案拆开讲。2. 打开黄帝模型仓库目录结构、基座加载与显存边界2.1 选型依据从LLaMA的中文短板到Ziya的中文增量预训练中医古籍问答属于典型的中文长文本加文言语料场景。原始LLaMA-13B以英文为主词表对中文覆盖不够直接拿来做古籍问答会出现两个问题一是“太阳”“阳旦”“伤寒”这类词被分词器切得零零散散二是古文里高频的“者”“也”“之”在生成时概率偏低模型更容易给出“大白话”而不是条文原句。Ziya-LLaMA-13B-V1走的路线是在LLaMA基础上继续做中文增量预训练再用指令数据做有监督微调。它的价值在于保留了13B参数量的生成容量同时把中文词表和语义空间补齐了。选它做中医古籍问答的基座核心理由是“已经懂中文的模型再学古籍”比“让英文模型从零学中文古文”要稳得多。黄帝模型仓库在此基础上继续喂中医古籍语料等于在“已经会中文”的模型上做第二次专业迁移。从AI大模型应用开发的常见选择看13B也是一个折中点它比7B更能容纳古籍里复杂的上下文依赖又没有65B/70B那么吃显存配合LoRA微调和半精度推理一张24G卡能勉强训练32G卡能相对从容地推理。如果你只有单张消费级显卡这个规模是本地部署配置里比较现实的上限。2.2 拆开仓库模型权重、微调脚本和数据样例的检查路径拿到“黄帝(Huang-Di)模型仓库.zip”先别急着解压就跑。常见的压缩包内部会分层我一般按三个维度检查。先看目录结构是否完整。典型布局里有模型权重目录、数据目录、脚本目录三块权重目录放config.json和权重分片数据目录放微调用的问答对样例脚本目录放推理和训练脚本。如果只有权重文件没有脚本说明仓库只提供了模型推理逻辑要自己补。再看权重文件格式。如果是pytorch_model.bin或pytorch_model-00001-of-0000X.bin分片按transformers常规方式加载如果是GGUF或llama.cpp格式说明发布者做了量化加载方式完全不同。这两者不要混用。Ziya-LLaMA-13B-V1的13B参数在fp16下半精度权重约26GB加上推理时的激活值开销实际显存需求在28GB以上。如果仓库里给了4bit或8bit量化版权重显存需求会明显下降但你的推理脚本也需要相应调整。最后看tokenizer配置。中医古籍里繁体字、异体字很常见要确认tokenizer是简体优先还是繁简同存。Ziya家族的tokenizer对常见繁体覆盖还行但遇到罕见异体字仍可能切成unk。这个影响很隐蔽加载时一切正常生成时某个药名变成“未登录字”病人拿去抄方就可能出错。下表是打开压缩包后建议核对的信息清单检查项看什么出问题时的表现文件格式是bin分片还是GGUF加载方式完全不同词表大小tokenizer_config里的vocab_size中文分词异常指令格式数据样例里“问/答”的模板生成风格与预期不符是否merged有没有合并后的完整权重加载PeftModel时报错2.3 加载最小化参数torch_dtype、device_map与trust_remote_code检查完结构我一般先用最小脚本验证权重能不能被transformers正确识别from transformers import AutoTokenizer, AutoModelForCausalLM import torch model_path ./Huang-Di/models tokenizer AutoTokenizer.from_pretrained(model_path) model AutoModelForCausalLM.from_pretrained( model_path, torch_dtypetorch.float16, device_mapauto, trust_remote_codeTrue, ) print(模型加载完成)逻辑说明AutoTokenizer负责把古籍问句转成token序列AutoModelForCausalLM加载的是自回归生成模型。torch_dtypetorch.float16把权重切成半精度13B模型在fp16下权重约占26GB显存device_mapauto让transformers根据可用显存自动分配层单卡时全部放GPU双卡时自动切分trust_remote_codeTrue允许执行仓库里的自定义代码Ziya这类派生模型常带自定义模型类不放开可能会报“unknown model class”。参数说明如果你的显卡只有16GB显存这个脚本很可能直接OOM。常见做法是做两级降级一是用load_in_8bitTrue加载需要安装bitsandbytes二是用load_in_4bitTrue显存占用能压到8GB以内但推理速度会变慢。我的经验是纯问答场景4bit影响不大但做LoRA微调时尽量保持半精度量化训练会引入额外误差。3. 跑通中医古籍问答推理脚本、生成参数与效果预期加载通过后下一步是跑生成。这里有个很容易踩的误区直接搬通用大模型的推理代码不做参数约束。中医古籍问答的输出有“原文引用白话解释”双重属性温度设置不当模型会把条文背得七零八落。3.1 单轮问答推理脚本与“问/答”模板# -*- coding: utf-8 -*- import torch from transformers import AutoTokenizer, AutoModelForCausalLM tokenizer AutoTokenizer.from_pretrained(./Huang-Di/models) model AutoModelForCausalLM.from_pretrained( ./Huang-Di/models, torch_dtypetorch.float16, device_mapauto, ) def ask(question, max_new_tokens256, temperature0.3, top_p0.8): prompt f问{question}\n答 inputs tokenizer(prompt, return_tensorspt).to(model.device) outputs model.generate( inputs.input_ids, max_new_tokensmax_new_tokens, temperaturetemperature, top_ptop_p, repetition_penalty1.10, do_sampleTrue, pad_token_idtokenizer.eos_token_id, ) answer tokenizer.decode(outputs[0][inputs.input_ids.shape[1]:], skip_special_tokensTrue) return answer.strip() if __name__ __main__: q 《伤寒论》太阳病提纲是什么 print(ask(q))逻辑说明ask函数把问题按“问/答”的指令格式拼进去这个格式必须与微调时用的prompt模板一致否则模型的响应风格会明显偏移。max_new_tokens控制回答长度条文加白话解释一般256到512之间够用temperature控制随机性0.3偏低适合需要原文引用的场景top_p把采样范围缩小到累计概率达到0.8的token里减少口语化杂质repetition_penalty设为1.1防止古文虚词重复刷屏。参数说明如果回答经常说到一半断掉说明max_new_tokens太短如果同一个问题抽七次得到好几个完全不同的答案把temperature降到0.2。这段代码里的pad_token_idtokenizer.eos_token_id不能省很多Ziya系模型的tokenizer没有默认pad_tokengenerate时偶尔会报padding警告给出来能消除大部分隐蔽问题。3.2 三个生成参数怎么调temperature、top_p与repetition_penalty古籍问答里生成质量不是单个参数的事是三个参数叠加的结果。我按经验给三档配置场景temperaturetop_prepetition_penalty适用情况原文优先0.20.61.15条文串讲、方剂组成解释适中0.50.851.05名词解释、病机分析自由发挥0.80.951.0鉴别诊断讨论慎用为什么中医古籍问答不适合直接用默认temperature1.0因为默认设置会引入过多非预期token而古籍字数少一个错字可能把“桂枝汤”变成“桂枝加葛根汤”方剂含义全变了。凡是涉及方名、药名、剂量的回答我习惯强制低随机度。另一个容易被忽视的参数是no_repeat_ngram_size设成3可以阻止三连字重复。比如生成“太阳之为病脉浮头项强痛而恶寒”时模型如果不小心重复“脉浮脉浮”调这个参数比反复压温度更直接。3.3 能答什么、不能答什么效果边界与免责提示即使模型加载和生成参数都调好了也需要明确效果边界。它能做的事包括条文出处定位、方剂组成默写、药物功效解释、病机白话翻译。它做不好的事包括个性化辨证、真实处方推荐、非常见医籍的考证性问答——尤其是训练语料里没有覆盖的冷门古籍容易一本正经地编造条文。部署时我习惯在system prompt里加一句“以上内容仅供中医学习与研究参考不构成医疗建议”。这不是形式主义而是多轮对话场景下模型可能顺着用户的话越说越笃定。AI大模型本地部署的价值在于数据可控但“可控”不等于“可用来替代诊断”。4. 接入自有古籍数据LoRA微调数据格式、超参与合并导出模型仓库既然给了基座权重真正的价值就不只是跑通推理而是把模型拉到自己的古籍范围里。常见做法是把自制问答对整理成指令微调格式用LoRA做低成本微调。4.1 指令数据格式把古籍QA整理成Alpaca三字段LoRA微调数据一般整理成Alpaca风格的三字段JSON[ { instruction: 请解释《伤寒论》第31条太阳病证治。, input: , output: 第31条为太阳病项背强几几反汗出恶风者桂枝加葛根汤主之。 }, { instruction: 桂枝加葛根汤的药物组成是什么, input: , output: 桂枝加葛根汤由桂枝、芍药、甘草、生姜、大枣、葛根组成。 } ]逻辑说明instruction是用户问题input用来放上下文比如“条文原文如下……”output是标准答案。做古籍问答时output里应当优先写条文原句再补白话解释这和第三章的低随机度配置是配套的。数据准备阶段有两个细节要注意。一是繁体问题如果你的标准答案从古籍影印本整理而来建议统一转成简体再进训练除非你的应用场景明确要求输出繁体混用繁简会显著增加模型的困惑度。二是标点问题古籍原文如果没有标点不要用自动标点工具直接生成否则模型会在“太阳病”和“太阳、病”之间摇摆。4.2 LoRA超参rank、alpha、dropout与学习率的经验值微调脚本里通常会放一组默认超参我自己的基准值如下参数建议值说明rrank16太低欠拟合太高过拟合lora_alpha32alpha与r保持2倍关系lora_dropout0.05古籍数据量小不宜过高learning_rate2e-4配合paged_adamw优化器num_train_epochs3数据不足千条时2到3轮per_device_train_batch_size113B模型显存优先一个常见误区是盲目套用大模型默认的learning_rate1e-5。LoRA微调只更新低秩矩阵学习率太低会让adapter学不动我做过对比2e-4比1e-5的效果明显好。但也不能直接上5e-4中医古籍数据量少学习率过高会导致灾难性遗忘——模型把Ziya原有的中文能力覆盖掉输出变成一堆文言碎片。LoRA配置示例from peft import LoraConfig lora_config LoraConfig( r16, lora_alpha32, lora_dropout0.05, target_modules[q_proj, k_proj, v_proj, o_proj], biasnone, task_typeCAUSAL_LM, )参数说明target_modules指定要加低秩矩阵的模块Ziya系模型常见做法是作用到attention四件套q/k/v/obiasnone表示不训练偏置项这是LoRA默认行为能省一部分显存。如果你的仓库脚本里已经写好了target_modules尊重它的配置即可不必强行改成通用大模型教程里的值。4.3 训练与合并导出的显存控制13B基座加LoRA训练单卡至少建议24G显存。如果只有16G把per_device_train_batch_size降到1后仍可能OOM此时可以开gradient_accumulation_steps8模拟8的batch size来稳定梯度再把梯度检查点gradient_checkpointingTrue打开以少量训练时间为代价换取显存空间。微调完成后保存的不是完整模型而是adapter权重。加载时先加载基座模型再用PeftModel加载adapterfrom peft import PeftModel base_model AutoModelForCausalLM.from_pretrained( ./Huang-Di/models, torch_dtypetorch.float16, ) model PeftModel.from_pretrained(base_model, ./lora_out) merged_model model.merge_and_unload() merged_model.save_pretrained(./Huang-Di-merged)这里有个容易翻车的点直接拿微调后的adapter当完整模型推理结果生成风格在正常与异常之间反复横跳。我习惯先merge_and_unload()导出真正的合并权重再跑一遍验证集。合并导出后的模型体积和原模型差不多占满26GB磁盘空间部署时要提前留出余量。5. 避坑中医古籍问答里最常见的四类问题与排查这里按“现象→原因→解决”记录四个高频问题都是这个方向上反复出现的血泪经验。5.1 现象一输出里“者”“也”刷屏答非所问现象模型生成一段回答时文言虚词不断重复“……者也……者也”连续出现十几次像死循环。原因古籍语料里“者”“也”出现频率极高如果LoRA数据里原文占比过大而未配白话解释模型会对这些高频字过度拟合另一种可能是推理时repetition_penalty没传进去命令行脚本里写了但API调用时没生效。解决先确认repetition_penalty确实传给了generate调到1.2再试如果还重复回数据侧排查让“原文讲解”配对比达到1:1左右不要让纯原文样本压倒性占多数。5.2 现象二能背条文但没法解释病机现象问“何谓少阴病”模型能完整背出“少阴之为病脉微细但欲寐也”但追问“这和亡阳有什么区别”时回答变得泛泛而谈。原因微调数据里只有“条文→白话翻译”的平行语料没有“概念间关系”的问答对模型只学会了映射没学会推理。解决在数据集中增加“概念解释”“鉴别比较”两类问题比如“少阴病与太阴病的鉴别要点是什么”“为什么少阴病会出现但欲寐”。这类跨条文题干能显著增强模型的解释能力也是让中医古籍问答从“背书”走向“答疑”的关键。5.3 现象三设备映射冲突导致推理报错现象用device_mapauto加载模型后推理脚本里又写了model.to(cuda:0)结果报“input tensor is not on the same device as the model”。原因device_map已经做了自动设备分配model.to(cuda:0)会把模型搬到默认设备但设备映射表还留在旧位置input_ids和权重不在同一设备上。解决固定一种设备分配方式。我通常只写device_mapauto推理时用model.device定位当前主设备不再手动to(cuda)。这条对刚接触transformers的开发者最容易翻车报错信息又多看半天才发现是两个设备策略打架。5.4 现象四一本古籍效果好换本书就明显变差现象在《伤寒论》问答上效果不错换成《温病条辨》或《本草纲目》的题模型立刻答非所问。原因典型的过拟合。微调数据多来自某一部古书模型记住了那本书的句式和药方却没有泛化到其他医书。解决建模时把数据集按“已见古籍/未见古籍”划分验证集保证不在训练集里放太多同书重复文本更稳妥的做法是给每条数据加“伤寒/温病/本草”分类前缀比如“【伤寒】请解释……”让模型在输入阶段就知道该调用哪一套知识。6. 进阶用ROUGE-L和人工抽查做问答质量验收不管你是买来仓库直接跑还是用LoRA微调了自己的医案最后都要回答一个问题效果到底行不行。常见做法是准备一份“标准答案集”先用ROUGE-L看文本重叠度再按规则人工打分。ROUGE-L适合快速排查“同一问句是否答了同样的要点”。但我必须提醒它的缺点很明显中医古籍允许白话改写和近义替换ROUGE-L偏低不等于错。所以我习惯的验收标准是ROUGE-L低于0.3的样本全部人工复核高于0.7且人工读起来通顺的记为“通过”中间的样本按下面这张表逐条打分。维度满分扣分条件条文出处20没有引用原文或出处错误药名方名30出现错字、异体字错误解释一致性30与古籍通行解释冲突危险信息20包含毒性结论、用药剂量等绝对化表述我个人的教训是拿到这类模型仓库后先跑通经典病案问答再上手微调不要一上来就追求“全部古籍都能答”把“原文优先”的低温度参数写死在配置里再做一套药材别名的多轮追问测试确认模型不会因为一个别名就切换成幻觉模式。这个流程走完这套AI大模型应用才算真正落到生产线上。希望帮到你。本文还有配套的精品资源点击获取