先观察一个有趣的现象：编写代码时，测试用例能精确覆盖所有逻辑，固定的输入对应固定的输出，清晰明了。但大模型完全不同，它处理的是自然语言，而自然语言的特点就是变化多端，各种千奇百怪的输入随时可能出现。 这就引出了几个现实需求： - 产品研发阶段，需要调试大模型的输入输出，验证任务拆解能力是否达标； - 业务上线后，要评估大模型在实际场景中的表现，确认是否真正解决了问题； - 日常运营中，还需要对所有交互内容进行合规审计，确保安全可控。 简而言之，我们需要一套能力，能够对大模型应用的输入和输出进行有效评判，支持检索、分析、评估，确保应用的整体行为符合预期。 ## 语义分析：从多角度理解大模型输入输出 为了更好地处理大模型日志，理解用户需求并评估模型表现，日志管理工具必须具备面向自然语言的搜索、处理和分析能力。具体来说，包括以下几个方面： - **语义富化**：提炼结构化信息，如用户意图、主题、情绪等。 - **向量检索**：一站式集成 embedding 和 vector_index，开箱即用。除了传统的关键字匹配，还能根据意图进行搜索。 - **混合检索**：结合关键字精确匹配和向量近似匹配，满足多字段的复杂查询需求。 - **聚类**：从更高视角对自然语言进行归类，快速识别热点和异常点。 ### （1）语义富化 在RAG领域，常规做法是将文件处理成结构化Markdown，然后切分chunk、构建向量索引。但这里存在一个问题：传统的文档处理流程会带来信息损耗。 解决思路是通过多模态特征提取，构建一个多维度的语义特征空间，从不同角度观察LLM的输入输出。这些角度包括： - **用户意图**：用户到底想做什么——是翻译、技术咨询、法律咨询，还是查询检索？ - **所属主题**：对话涉及哪个领域——教育、云计算，还是法律？ - **总结**：复杂的上下文容易让人困惑，用一句话概括整个会话，用户搜索总结即可快速命中。 - **情绪**：用户情绪是正面、负面，还是中性？ - **关键词**：抽取对话中的核心词汇。 - **问题**：针对会话主动生成几个问题，把会话本身变成这些问题的答案。用户用问题去召回历史会话时，可直接命中。 - **实体抽取**：提取国家、地名、人名等实体信息。 简单来说，就是借助LLM评估和向量索引，为Prompt和Response提取结构化信息，并以可视化的方式呈现。基于评估结果，你可以了解用户意图、情绪、关注点和常见问题，清楚LLM的响应质量，方便后续调优，同时还能进行合规审计，规避法律风险。 在实现上，可以利用日志服务SLS的语义处理能力。它在数据加工过程中提供了开放式的接口方案，能够对接百炼托管模型API或自研LLM API，从而实现基于LLM的语义富化。 整个LLM评估架构包含几个关键组件： - **通用HTTP函数**：数据加工SPL语法内置了通用的HTTP调用函数，传入URL、Body、Header等，即可调用外部服务处理数据并拿到结果。 - **调用Qwen模型**：在通用HTTP函数之上，封装了针对Qwen的AIGC函数。传入Qwen地址、百炼access-key、system prompt、user prompt，就能调用百炼的Qwen模型。 - **系统/自定义Prompt库**：SLS提供了评估专用的Evaluation System Prompt模板库。你可以选择需要的功能，然后把日志中的prompt/response作为普通文本传入User Prompt。当然，也可以自己写Prompt，自定义处理逻辑。 这样一来，通过可自定义的Prompt、endpoint和model，就能满足各种独特的业务需求。下面是一个SLS内置的语义富化语句示例（日志服务SPL语法）： ``` * | extend "__tag__:__sls_qwen_user_tpl__" = replace(replace(replace(replace(replace(replace(replace(replace("__tag__:__sls_qwen_user_tpl__", '', "output.value"), '', '\'), '"', '"'), chr(8), 'b'), chr(12), 'f'), chr(10), 'n'), chr(13), 'r'), chr(9), 't') | extend "__tag__:__sls_qwen_sys_tpl__" = replace(replace(replace(replace(replace(replace(replace("__tag__:__sls_qwen_sys_tpl__", '', '\'), '"', '"'), chr(8), 'b'), chr(12), 'f'), chr(10), 'n'), chr(13), 'r'), chr(9), 't') | extend request_body = replace(replace("__tag__:__sls_qwen_body_tpl__", '', "__tag__:__sls_qwen_sys_tpl__"), '', "__tag__:__sls_qwen_user_tpl__") | http-call -method='post' -headers='{"Authorization": "Bearer xxxxxx", "Content-Type": "application/json", "Host": "dashscope.aliyuncs.com", "User-Agent":"sls-etl-test"}' -timeout_millis=60000 -body='request_body' 'http://dashscope.aliyuncs.com/api/v1/services/aigc/text-generation/generation' as status, response_body | extend tmp_content = json_extract_scalar(response_body, '$.output.choices.0.message.content') | extend output_enrich = regexp_replace(regexp_replace(tmp_content, '^([^{]|s)+{', '{'), '}([^}]|s)+$', '}') | project-away "__tag__:__sls_qwen_sys_tpl__", "__tag__:__sls_qwen_user_tpl__", "__tag__:__sls_qwen_body_tpl__", trimed_input, tmp_content, request_body , response_body ``` 执行后，就能得到结构化的语义评估结果。 ### （2）向量检索 在实际落地时，向量检索存在不少工程上的“坑”： - 要做向量检索，得先把文本embedding成向量，再建索引。工程复杂度本身就高，还需要维护数据导入、embedding模块、向量索引模块、查询模块等一系列组件。 - 召回率受embedding模型和索引类型影响较大，研发代价不低。 - 成本更是一个硬伤。embedding转换、建索引都依赖GPU。向量的存储空间很大，查询时还特别占内存。这些因素叠加，成本很难降下来。 不过，SLS提供了一站式的向量检索能力，有效降低了这些门槛。Prompt/Response写入SLS后，系统会自动完成embedding和向量索引构建。查询时，自动把查询语句转成向量，然后从索引里查找近似向量，根据命中的docID读取原始数据。开发者无需关心中间的技术细节，只管写入和查询文本即可。 SLS提供了向量查询语法，使用时需要注意几个关键点： - 用 `similarity` 语法表达近似度。 - 指定搜索哪个字段下的向量索引。 - 指定查询语句。 - 指定查询距离——0表示最相似，1表示最不相似。 语法模板： ``` similarity(Key,query) < distance ``` ### （3）混合检索 在某些场景下，仅有近似检索还不够，还需要精确匹配某些字段。例如，查询某个特定uid的Prompt，需要同时精确命中uid，又近似查询Prompt列。这时混合检索就派上了用场。 混合检索使用and条件连接，会分别查询关键字倒排索引和向量索引，然后将两者结果合并： ``` uid:123 and similarity(key,query) < distance ``` ### （4）向量聚类 面对各种各样的用户输入和大模型输出，如何找到热点问题？哪些是离群点？如果只有文本，因为文本之间各不相同，分析起来很困难。 但将文本转成向量后，就能根据空间距离进行聚类。聚类依赖于SQL函数，`cluster_centroids` 函数接收一个二维数组和聚类个数，生成对应的聚类结果： ``` clustering_centroids(array(array(double)) samples, integer num_of_clusters) ``` 高维向量在空间里无法直接观察，SLS提供了降维函数，把高维向量转成二维向量用于可视化。从下图可以直观地看到语义聚类和降维后的可视化效果。 ``` t_sne(array(array(double)) ``` ## LLM Prompt/Response 语义洞察的工程实践 从原始Prompt和Response中提取出语义信息后，结合关键字检索、向量检索、语义聚类，可以实现以下几个业务目标： ### 基于检索的合规审计 检索特定关键字，就能发现是否存在不合规行为。例如，将一些违禁词设为关键字，再查找它们的近似词。这可以通过 `similarity` 语法实现，调整距离参数即可控制相似性的宽严程度。 示例： ``` similarity("input_semantic.summary","恶意关键词") < 0.4 ``` ### 基于检索的主题、情绪筛选 在语义处理阶段，评估引擎已经对自然语言做了分类，提取了主题、情绪等信息。在Chatbot应用中，可以方便地查看特定主题的会话历史。 示例： ``` input_semantic.topic : database ``` ### 内容聚类 基于聚类，可以把相似的内容归为一类，清晰展示话题之间的相关性和距离。例如下图右上角的聚类效果，每种颜色代表一个类别，有些话题与其他话题的距离较远，一目了然。 ## 总结 无论是用户画像构建（识别长尾需求）、模型迭代优化（基于Bad Case提升准确率），还是合规风险管理（提升检测效率、降低误报率），核心思路都是一致的：通过语义富化和搜索，更精准地理解并引导大模型的输出，最终打造出真正“懂”自然语言的应用。