当向量的语料库准备好，工作基本上算完成了。最后还需要测试一下，如果效果不好，还要从两方面去考虑，就是提示词工程和上下文工程。在提问的过程中，就会出现一些提示词，去向量数据库中做检索，找到相关的上下文信息后，再调用大模型的API，把提示词和它的相关上下文信息作为输入，底层的大模型会结合这些信息，最终给出反馈结果作为回答。
如果涉及追问，那还会有一些上下文工程的工作，工程量的大小取决于选取的大模型本身记忆的长短。如果大模型相对健忘，那可能就要自己去做一些上下文的工程，让交流更自然或者延续性更好，最终找到一个解决方案。如果模型相对记忆性比较好，理解能力又很强，那相对来说就会简单一些。
六、大模型不会反向推理，这个模型的缺陷会导致在设备故障预测等场景中不能很好的落地吗？
大模型本质上还是一个概率模型，并不具备我们认为的推理能力。从实践角度来说，确实会限制大模型的一些使用场景。它能够作为一个好的辅助角色，顾问或者助手，帮助你来厘清思路，但如果期待它自己来做反控，就不现实。
工业系统是一个精确的系统，而大模型会犯错，就是ChatGPT，通过几个误导性的问题，回答也会完全不一样。不排除以后大模型具备复杂的推理能力，但现在还不适合这种场景。
当前比较理想的情况是，在故障诊断场景下，大模型以一个辅助的方式，把定性的规程的标准的信息和曾经实在发生过的历史档案，以及已经加工处理好的特征、KPI等指标类的信息调取出来，工程师自己再做判断。让大模型用编程语言去操作一个数据系统，在技术上是可行的，比自然语言要更精确一些。
工业企业应用大模型，在完成前述基本框架后，进一步工程化演进，可以考虑：第一，怎么让分词分得更好，可以尝试进一步丰富语义库；第二，提示词工程，怎么能够让提示工程的质量更高，让答案的反馈效率和准确性更好；第三，能不能去做多模态融合，把大模型的输出和一些其他信息化数字化系统的输出融合起来，给用户一个标准化的答案。这三步做到一定程度，对于企业应用大模型的投入产出比，就具有一定可行性了。
