博士论文 | Towards Domain Adaptation, Deployment, and Interpretability in Large Language Models

导读

通用大语言模型的能力来自“广泛性”：它们在大规模语料上学习语言规律，因此可以写代码、摘要、翻译、对话，也能在很多开放任务上给出流畅回答。但真实应用往往不是“广泛”的，而是“处境化”的。农民需要本地作物、病虫害、土壤和季节相关建议；企业需要把自然语言接到内部文档、数据库和工具；神经科学研究者不仅希望模型预测脑响应，还希望理解模型到底用什么语义特征完成预测。 UC Berkeley 2026 年博士论文《Towards Domain Adaptation, Deployment, and Interpretability in Large Language Models》讨论的正是这个落差：如何把一个通用 LLM 变成真正可用、可部署、可解释的领域系统。论文作者 Vinamra Benara 的核心观点很清晰：领域适配不是在 RAG 与微调之间做单选，也不是只调一个模型参数，而是一个端到端系统工程问题，涉及文档解析、数据构建、知识注入、检索、评测、部署架构、工具插件和可解释表示。 全文由四项工作组成：第一，围绕农业问答构建端到端领域适配管线，系统比较 RAG 与微调；第二，提出边缘-云层次化模型部署架构，让领域助手能在弱网、低延迟和隐私约束下工作；第三，将农业管线抽象为可复用的语言模型 Copilot 开发框架；第四，提出 QA-Emb，用“向 LLM 提一组是/否问题”的方式构造可解释文本嵌入，并用于语言神经科学中的 fMRI 响应预测。 这篇论文的价值不只在于单点方法，而在于给出一种“全栈 LLM 领域系统”的视角：有用的模型，必须连接正确知识，用正确指标评估，在真实约束下服务，并在高风险或科学场景中提供可解释性。

论文信息

论文标题：Towards Domain Adaptation, Deployment, and Interpretability in Large Language Models 作者：Vinamra Benara 机构：University of California, Berkeley, Electrical Engineering and Computer Sciences 报告编号：UCB/EECS-2026-233 导师：Ion Stoica 委员会成员：Joseph Gonzalez、Aditya Parameswaran、Chandan Singh 时间：2026 年 7 月 6 日 论文链接：https://www2.eecs.berkeley.edu/Pubs/TechRpts/2026/EECS-2026-233.pdf

1 Introduction 引言

从通用模型到具体世界

论文开篇指出，互联网规模训练得到的 LLM 通常是通用系统。它们可以遵循多种指令，但并不会自动具备高专业度、高风险、资源受限场景所需的能力。农业顾问、企业 Copilot、科学解释模型都需要的不只是一个强 base model，而是一个能吸收领域知识、适应部署约束、并暴露可解释结构的完整系统。 作者把问题概括为“通用模型与具体世界之间的差距”。一个农业助手如果只给出“春天适合种树”这样的通用回答，即使听起来合理，也无法替代地方专家。正确答案可能依赖州、国家、土壤、作物品种、病虫害、法规和季节。因此，领域适配要处理的不是一个提示词问题，而是从原始资料到可用服务的整条链路。

三个核心问题

第一是知识问题。领域知识可能缺失、过时、散落在 PDF、网页、表格或内部文档中，也可能以复杂版式存在。系统必须先把这些资料变成可训练、可检索、可评估的结构化资源。 第二是部署问题。领域用户未必处在稳定云环境中。以农业为例，用户可能在田间、农村或弱网环境中使用助手。云端大模型能力强，但不可用时就没有价值；本地小模型能力有限，却能在离线或低延迟条件下继续提供服务。 第三是可解释问题。在科学和高风险领域，模型不能只是给出高分预测。研究者还要知道表征维度对应什么语义、哪些特征影响预测、模型是否学到可解释结构。论文第 5 章的 QA-Emb 正是围绕这个问题展开。

主要贡献

论文的贡献可以概括为四点。其一，建立农业领域 LLM 适配基准与管线，比较 RAG、微调及其组合。其二，提出可在设备、边缘服务器和云之间动态路由的层次化部署架构。其三，提出可复用的 Copilot 开发框架，将数据资源构建与运行时插件调用分离。其四，提出可解释的问答嵌入 QA-Emb，让每个嵌入维度都对应一个自然语言问题。

2 RAG vs Fine-tuning: Pipelines, Tradeoffs, and a Case Study on Agriculture

问题背景

第 2 章围绕一个实际问题展开：如果要把 LLM 适配到农业领域，应该使用检索增强生成，还是微调？直觉上，RAG 更适合接入外部知识，微调更适合让模型内化领域风格与知识。但在真实领域中，二者的边界并不清楚，也缺少系统比较。 论文以美国、巴西和印度的农业资料为基础，构建领域数据集。农业是一个很好的测试场，因为它具有强烈地域性：同一个问题在不同地区可能有不同答案。例如种植时间、病虫害治理、土壤修复和作物管理都依赖本地知识。

端到端适配管线

作者构建的管线包括五步：收集领域文档；解析 PDF 和文档结构；生成问答对；用问答数据进行微调；在有无 RAG 的条件下，用 GPT-4 作为评测器进行多指标评估。这里的重点不是简单把文档放进向量库，而是先把复杂文档中的内容与结构抽取出来，再生成可用于训练和评测的高质量问答。

这一管线还引入了基于 rubric 的评测方式。对于开放问答，简单字符串匹配、BLEU 或 ROUGE 很难判断回答是否真正包含关键事实。因此论文使用问题、参考答案和评价准则，让 GPT-4 按相关性、覆盖度、流畅性、扎实性、简洁度等维度评分。这种做法为开放式领域问答提供了更接近专家判断的自动化评估路径。

关键实验结果

实验显示，RAG 和微调不是竞争关系，而是互补关系。在农业问答中，GPT-4 基础模型准确率为 75%，加 RAG 后达到 80%；GPT-4 微调后达到 81%，微调再加 RAG 后达到 86%。也就是说，微调大约带来 6 个准确率点提升，RAG 在此基础上又贡献约 5 个点。

更重要的是，论文发现微调不只是改变回答风格，也能把新知识写入模型。对于模型未在训练中见过的区域特定问题，GPT-4 只能学到约 47% 的新知识；经过微调后，这一比例提升到 72%-74%。这说明，在某些稳定领域知识上，微调确实能够提升模型的内部化能力。

两类方法的取舍

论文总结了 RAG 与微调的不同成本结构。RAG 的初始成本较低，主要是构建嵌入和检索索引；它适合答案依赖上下文、知识更新快、需要引用证据的场景。但 RAG 会增加输入长度，回答可能更冗长，也更依赖检索质量。 微调的初始成本较高，需要训练资源和高质量数据；但它可以让模型形成领域技能，输出更简洁、更符合任务风格，在稳定知识和固定流程上表现更好。真正的工程选择不是“只用哪一个”，而是根据知识更新速度、数据规模、成本预算、延迟约束和可解释要求组合二者。

3 Edge-Cloud Hierarchical Language Model Design

动机

第 3 章转向部署。一个领域适配模型如果只能在理想云环境中工作，就很难服务真正需要它的人。农业用户可能在弱网地区，企业用户可能受隐私约束，移动端用户可能受设备资源和延迟限制。论文因此提出边缘-云层次化语言模型设计。

架构设计

系统分为三层：前线边缘设备运行小模型并存储本地上下文；后端边缘服务器运行中等模型；云端运行大模型。模型选择器根据网络连接、设备负载、查询难度、延迟要求和上下文可用性决定由哪一层回答。

这种架构的关键是把“能力”和“可用性”一起纳入设计。简单问题可以本地回答，保护隐私并降低延迟；需要更强推理或更大上下文时，系统再升级到边缘服务器或云端。论文还讨论了用户特定上下文和行业特定上下文的预生成与同步，使得本地设备在离线情况下也能用缓存知识继续回答。

查询处理

运行时，用户通过文本、语音或图像支持界面提交问题。系统先检索本地或行业上下文，再由模型选择器决定使用本地小模型、边缘中模型还是云端大模型。若小模型无法满足准确率或延迟阈值，查询可以逐级上交；如果网络不可用，系统则尽量在本地上下文范围内完成响应。 这部分的贡献不在于某一个模型，而在于把模型选择、上下文缓存、连接状态和服务质量放入同一个推理路径中。对于真实部署，这常常比追求单一最大模型更重要。

4 Framework for Language Model Copilot Development

框架概览

第 4 章把农业适配管线进一步抽象为可复用的语言模型 Copilot 开发框架。框架包含两个层次：离线数据管线和在线 Copilot 运行时。 离线管线负责获取领域数据、抽取文档结构、生成问答对、评估问答质量、创建微调数据，并构建检索索引。在线运行时则托管或调用语言模型，通过工具解析器暴露插件，让模型可以访问外部 API、文档索引、数据库和领域服务。

知识资源构建

论文将“知识资源”定义为领域 Copilot 的核心资产。它不仅是一个向量数据库，而是包括原始资料、结构化抽取结果、元数据、问答数据、评测标准、微调模型和检索索引的组合。这样做的好处是，适配结果可以跨应用复用：同一套资源既能支撑 RAG，也能支撑微调，还能服务插件工具。

插件式运行时

插件架构让 Copilot 不只是生成文本，而是能连接外部能力。用户查询进入系统后，LLM 接收可用工具描述，工具解析器决定调用哪个插件，插件通过 REST API 接入数据摄取、工具执行或管理服务，再把结果返回给模型生成最终回答。 这种设计特别适合企业和行业场景，因为领域能力往往分布在多个服务中。与其把所有知识硬塞进模型，不如让模型成为自然语言接口和决策层，围绕它构建可审计、可替换、可扩展的工具生态。

5 Crafting Interpretable Embeddings for Language Neuroscience by Asking LLMs Questions

方法思想

第 5 章讨论可解释表征。传统 embedding 通常是黑箱向量，维度没有明确语义。QA-Emb 的想法很直观：给定一段文本，向 LLM 提出一组自然语言是/否问题，例如“句子是否包含数字信息”“句子是否描述物理动作”“句子是否语法复杂”。每个问题的答案映射为 0/1，所有答案组成一个 embedding。 这样，每个维度天然可读。训练的核心变成选择哪些问题最有用，而不是解释一个不可读的隐藏向量。论文将 QA-Emb 用于 fMRI 语言响应预测，也扩展到信息检索和文本聚类等简单 NLP 任务。

语言神经科学实验

在 fMRI 响应预测任务中，QA-Emb 的表现超过经典可解释基线 Eng1000，并与黑箱 BERT 基线相当，但低于表现最强的 LLaMA 表征。论文报告，QA-Emb 相比 Eng1000 提升 26%，并且随着问题数量增加，性能快速上升；用 29 个问题就能接近 985 维 Eng1000 基线的效果。

可解释权重

QA-Emb 还可以把语义问题映射到脑区选择性。例如，与物理动作、物理环境、语法复杂度相关的问题，在不同受试者上学到的权重呈现一定一致性。相比黑箱 embedding，这种表示更容易被研究者用于提出神经科学假设。

局限与扩展

论文也强调 QA-Emb 并非万能。它依赖 LLM 对是/否问题的回答质量，构造大量问题可能带来计算成本，问题选择也会影响最终表征。为降低成本，作者还研究了把多次 LLM 调用蒸馏为单次前向模型，结果显示蒸馏不会显著损害性能。 在信息检索任务中，QA-Emb 单独使用表现一般，但与 BM25 结合时能带来小幅显著改进；在文本聚类中，利用 GPT-4 为任务选择相关问题可以进行零样本适配。这说明 QA-Emb 更像是一种可解释补充层，适合与已有检索或表示方法组合，而不是完全替代黑箱 embedding。

6 Conclusion 结论

统一观点

论文最后回到中心论点：把 LLM 适配到真实领域，不是选择一个模型技巧，而是设计一整套系统。完整系统必须决定如何收集领域资料、如何把知识写入或检索出来、如何评估开放回答、如何在真实约束下部署，以及如何在需要理解的场景中构造可解释表示。 第 2 章说明，RAG 和微调各自解决不同问题。RAG 擅长接入外部证据和动态知识，微调擅长内化领域模式和稳定技能，组合使用往往更强。第 3 章说明，部署架构决定模型能力能否真正触达用户。第 4 章说明，领域 Copilot 应当围绕知识资源和插件运行时构建，而不是只围绕一个模型端点。第 5 章说明，可解释性可以从表征设计阶段内置，而不是事后再补解释。

局限与未来方向

论文提出的限制也很有启发。首先，所有系统都依赖初始数据抽取质量。复杂 PDF 和多模态文档解析错误会级联影响问答生成、检索和微调。其次，用 LLM 生成训练对或评测输出会受到基础模型能力限制，合成监督可能遗漏罕见边界情况。第三，边云架构虽然缓解连接问题，但引入了复杂编排权衡，需要持续平衡数据本地性、存储限制、计算开销和延迟。第四，QA-Emb 的问题集合仍然依赖问题生成质量和回答可信度。 未来值得推进的方向包括：更强的文档结构抽取与多模态资料解析；能自动发现知识缺口并自我修正的领域模型；更细粒度的模型路由与上下文同步策略；可解释 embedding 与 RAG 系统结合，让检索结果不仅“相关”，还可以说明相关原因。

总结

这篇博士论文最重要的启示是：模型只是 LLM 系统的一部分。真正决定系统能做什么的，是围绕模型的文档、解析器、生成数据、检索索引、微调过程、评测器、插件、服务基础设施、缓存上下文和可解释特征。 通用 LLM 要进入具体世界，必须被接到正确知识上，用正确标准评价，在正确约束下服务，并在需要时给出可读解释。论文从混乱领域文档走向适配模型，从适配模型走向可部署 Copilot，再从黑箱向量走向可解释表示，给出了一条非常完整的工程与研究路线。