其次需要对大模型的技术评价有一系列的指标体系，从实际应用的角度，通过测评报告做一轮初筛，然后考虑它的license是否可以开源商用，比如说同样是某品牌的大模型，1.5版本之前可以商用，最新的版本不可以，需要留意。再次，对中文的支持是否友好。
市面上很多大模型的研发企业在不断的快速更新版本，但对于行业企业应用，没必要对底层技术的发展追踪太紧，更没必要从底层开始研发。
接下来，第二步，以此为基础，将现有的通用模型与特定领域的需求相结合，训练特定语料，通过调整参数和技术路由来实现目标。当然在这一步，有很多的技术路线可选，从浅到深，从易到难，从效果差到效果好。
比较浅层次的调优或者客制化方式是提示工程，是通过改变问题的描述方式去影响模型内部的运行，从而改变它的输出。提示工程并没有改变模型本身，或者挖掘模型里蕴含的知识，本质上没有改变模型知识的边界。
再往前一步，做Embedding，就是在问问题的同时，将私有语料当做问题的上下文，一起发送给大模型，大模型基于这些上下文材料回答问题。这种方式也不会扩展基础模型的知识边界。
再往前一步，进入微调的阶段，对于一般企业来讲就稍微有点深了。类似于知识载体的回炉再造，在具备通识的基础上，将专业领域的语料大量输入，做小型的模型训练。从微调这一步开始，就需要GPU资源做数据处理了。
再往前一步，大多数企业就已经达不到了，几乎重建，这个在资源投入和技术难度身上要求太高。所以从应用层面，一般前面三步相对更实用。
五、考虑到实用性和竞技性，以技术路线二为例，继续推进，有哪些进一步的建议吗？
走第二种路线，科学道理很简单，但真正上手做的时候，会发现这是一个巨大的工程问题。除了刚才提到的底层大模型的选择，还有几个问题：
首先，准备语料。一般语料都是一个整体，为了能够把语料变成问题能参考的上下文，就要将语料做预处理，放到向量数据库，把它向量化，成为行业数据模型。这里就涉及语料怎么切分整理。各种word文档中，有一些文字语义相近，有一些语义关联较远，并不能通过一种完全自动化的方式去做，所以预处理的过程中，人的参与度还是很高。特别在梳理的过程中，会碰到以前的一些周边技术和老技术融到一起，会消耗非常多的精力。当然，全靠人工去做也做不完，还是有相应的一些工具和能力去辅助专家。语料本身质量的高低也会对工作量有一定的影响。
其次，刚才说的底层大模型是一种引擎，向量数据库也是一种数据存储引擎，那么还需要一个框架，把技术整合到一起，把分词的预处理结果管起来，然后基于一定的词库，给向量化存下来。这一步，基本上工程问题会大于科学问题。
