在没有特定领域和背景知识的情况下，大模型在理解用户意图会从通识方向理解。然而在无线网络投诉处理领域，很多自然语言词汇与通知语义存在差异，比如“小区”等。

解决以上问题可以从以下两方面着手：

•  微调大模型

通过将特定领域的知识以微调训练的方式，增加通用大模型在特定领域和背景下的知识，从而增强通用大模型在特定领域的推理和生成结果的准确性。

•  在提示词中限定

通过在提示词中增加背景知识、限定角色、特定词汇定义说明等方式形成特定对话下上下文知识，从而提高大模型推理和生产结果的准确性。

在与大模型对话的过程中，通常会有很多关键信息大模型识别的准确性非常重要。为了提高准确性，除了采用以上两种手段外，还可以采用开发特定工具来解决。比如时间识别工具、物点识别工具、场景识别工具、小区名称识别工具等。这些工具本身可能也会与大小模型交互，但在限定范围的背景下，识别准确性会大大提高。

大模型推理生成token长度限制会出现以下问题：

•  非流式调用情况下推理生成速度变慢

此问题通常可以通过更换为流式调用解决。但在需要等待大模型返回完整结果后才能进行后续处理的情况下，就需要寻找其他方法解决。因此利用增加调用次数换时间的策略不失为一种解决方案：通过将长token单次交互拆解成短token多次交互。这种情况下，需要对业务进行一定的设计和细分，对设计和开发人员有相对高的要求。

•  token长度超长无法返回结果或返回结果不完整

此问题可以从业务需求侧优化。精简让大模型推理生成的内容来解决，比如：整个工单内容的推理总结精简为必要的工单内容推理总结；总结内容精简和长度限制等。

大多数的大模型技术框架支持多轮问答上下文记忆的方式通常是将历史的问和答的内容全部记忆下来每次与大模型交互时附加上这些历史问答内容。这种方式有如下问题：

•  多轮问答内容多且冗余

比如问题里的时间、网元、指标、意图指令等关键，多轮问答中都有可能出现。但通常情况下，仅上一次提到的这些关键信息才在多轮问答的上下文中才有用，更早的这些信息就是冗余信息。

•  无法无限制轮次地问答

大模型token限制的原因，叠加了多轮问答的上下文，就无法无限制轮次地问下去。极端情况下，可能造成大模型推理生成异常，对计算资源也是一种浪费。

•  问答中带有业务数据，占用了大量上下文和token长度

在投诉处理场景中，工单识别环节的工单内容就会占用大量上下文记忆的空间。

针对以上问题，需要对大模型技术框架在上下文记忆的处理上做一些优化，比如：仅记忆问题不记忆回答、仅记忆问答中的关键信息不记忆全部内容等。

在投诉处理场景中，有区域（省、地市、区县）名称、小区名称、场景名称等的识别，这些数据量都比较大，大模型token限制的原因无法放到提示词中作为大模型推理生成的输入。这种由于具体业务场景出现的问题，需要结合Embedding小模型、向量库、RAG知识库等技术解决实际遇到的问题。