Ziya-LLaMA-13B-V1中医古籍问答：加载、微调与避坑指南

简介：基于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。这个影响很隐蔽：加载时一切正常，生成时某个药名变成“未登录字”，病人拿去抄方就可能出错。

下表是打开压缩包后建议核对的信息清单：

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_dtype=torch.float16, device_map="auto", trust_remote_code=True, ) print("模型加载完成")

逻辑说明：AutoTokenizer负责把古籍问句转成token序列，AutoModelForCausalLM加载的是自回归生成模型。torch_dtype=torch.float16把权重切成半精度，13B模型在fp16下权重约占26GB显存；device_map="auto"让transformers根据可用显存自动分配层，单卡时全部放GPU，双卡时自动切分；trust_remote_code=True允许执行仓库里的自定义代码，Ziya这类派生模型常带自定义模型类，不放开可能会报“unknown model class”。

参数说明：如果你的显卡只有16GB显存，这个脚本很可能直接OOM。常见做法是做两级降级：一是用load_in_8bit=True加载，需要安装bitsandbytes；二是用load_in_4bit=True，显存占用能压到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_dtype=torch.float16, device_map="auto", ) def ask(question, max_new_tokens=256, temperature=0.3, top_p=0.8): prompt = f"问：{question}\n答：" inputs = tokenizer(prompt, return_tensors="pt").to(model.device) outputs = model.generate( inputs.input_ids, max_new_tokens=max_new_tokens, temperature=temperature, top_p=top_p, repetition_penalty=1.10, do_sample=True, pad_token_id=tokenizer.eos_token_id, ) answer = tokenizer.decode(outputs[0][inputs.input_ids.shape[1]:], skip_special_tokens=True) 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_id=tokenizer.eos_token_id不能省，很多Ziya系模型的tokenizer没有默认pad_token，generate时偶尔会报padding警告，给出来能消除大部分隐蔽问题。

3.2 三个生成参数怎么调：temperature、top_p与repetition_penalty

古籍问答里，生成质量不是单个参数的事，是三个参数叠加的结果。我按经验给三档配置：

为什么中医古籍问答不适合直接用默认temperature=1.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与学习率的经验值

微调脚本里通常会放一组默认超参，我自己的基准值如下：

一个常见误区是盲目套用大模型默认的learning_rate=1e-5。LoRA微调只更新低秩矩阵，学习率太低会让adapter学不动；我做过对比，2e-4比1e-5的效果明显好。但也不能直接上5e-4，中医古籍数据量少，学习率过高会导致灾难性遗忘——模型把Ziya原有的中文能力覆盖掉，输出变成一堆文言碎片。

LoRA配置示例：

from peft import LoraConfig lora_config = LoraConfig( r=16, lora_alpha=32, lora_dropout=0.05, target_modules=["q_proj", "k_proj", "v_proj", "o_proj"], bias="none", task_type="CAUSAL_LM", )

参数说明：target_modules指定要加低秩矩阵的模块，Ziya系模型常见做法是作用到attention四件套q/k/v/o；bias="none"表示不训练偏置项，这是LoRA默认行为，能省一部分显存。如果你的仓库脚本里已经写好了target_modules，尊重它的配置即可，不必强行改成通用大模型教程里的值。

4.3 训练与合并导出的显存控制

13B基座加LoRA训练，单卡至少建议24G显存。如果只有16G，把per_device_train_batch_size降到1后仍可能OOM，此时可以开gradient_accumulation_steps=8，模拟8的batch size来稳定梯度；再把梯度检查点gradient_checkpointing=True打开，以少量训练时间为代价换取显存空间。

微调完成后，保存的不是完整模型而是adapter权重。加载时先加载基座模型，再用PeftModel加载adapter：

from peft import PeftModel base_model = AutoModelForCausalLM.from_pretrained( "./Huang-Di/models", torch_dtype=torch.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_map="auto"加载模型后，推理脚本里又写了model.to("cuda:0")，结果报“input tensor is not on the same device as the model”。

原因：device_map已经做了自动设备分配，model.to("cuda:0")会把模型搬到默认设备，但设备映射表还留在旧位置，input_ids和权重不在同一设备上。

解决：固定一种设备分配方式。我通常只写device_map="auto"，推理时用model.device定位当前主设备，不再手动to("cuda")。这条对刚接触transformers的开发者最容易翻车，报错信息又多，看半天才发现是两个设备策略打架。

5.4 现象四：一本古籍效果好，换本书就明显变差

现象：在《伤寒论》问答上效果不错，换成《温病条辨》或《本草纲目》的题，模型立刻答非所问。

原因：典型的过拟合。微调数据多来自某一部古书，模型记住了那本书的句式和药方，却没有泛化到其他医书。

解决：建模时把数据集按“已见古籍/未见古籍”划分验证集，保证不在训练集里放太多同书重复文本；更稳妥的做法是给每条数据加“伤寒/温病/本草”分类前缀，比如“【伤寒】请解释……”让模型在输入阶段就知道该调用哪一套知识。

6. 进阶：用ROUGE-L和人工抽查做问答质量验收

不管你是买来仓库直接跑，还是用LoRA微调了自己的医案，最后都要回答一个问题：效果到底行不行。常见做法是准备一份“标准答案集”，先用ROUGE-L看文本重叠度，再按规则人工打分。

ROUGE-L适合快速排查“同一问句是否答了同样的要点”。但我必须提醒：它的缺点很明显，中医古籍允许白话改写和近义替换，ROUGE-L偏低不等于错。所以我习惯的验收标准是：ROUGE-L低于0.3的样本全部人工复核，高于0.7且人工读起来通顺的记为“通过”，中间的样本按下面这张表逐条打分。

我个人的教训是：拿到这类模型仓库后，先跑通经典病案问答再上手微调，不要一上来就追求“全部古籍都能答”；把“原文优先”的低温度参数写死在配置里，再做一套药材别名的多轮追问测试，确认模型不会因为一个别名就切换成幻觉模式。这个流程走完，这套AI大模型应用才算真正落到生产线上。希望帮到你。

本文还有配套的精品资源，点击获取