【问题来源】【必填】星网【问题简要】【必填】Web接口直接访问Cell直接走了失败出口，是不是平台需要配置啥地方【问题类别】【必填】GSL【AICC解决方案版本】【必填】平台版本号:ICDV300R008C25SPC211SCE开发工具版本：ICDV300R008C20SPC002【期望解决时间】【选填】尽快【问题现象描述】【必填】其他项目验证过的IVR流程测试也是直接走失败出口IVR服务器访问接口的端口是通的【日志或错误截图】【可选】【附件】【可选】 

人工智能和呼叫中心如何打通。做个HWD呼叫中心助理,我们呼叫中心系统和人工智能对接，在哪里有接口，或者界面。南京德视伟业软件技术有限公司

【问题来源】【必填】    民生银行         【问题简要】希望得到AICC 24.200匹配的openeye webdom【问题类别】【必填】       Openeye H5 SDK【AICC解决方案版本】【必填】      AICC 24.200    【期望解决时间】尽快【问题现象描述】 当前论坛中的openeye webmo最高版本位23.300， 其内容与24.200产品中描述的开发接口中的demo code具体有区别现在23,200, 23.300的demo中的代码截图如下：配套24.200的webdemo是否能提供一下？

问题来源】    百信银行    【问题简要】客户想要在与asr交互过程中同时识别按键【问题类别】【必填】  ivr(gsl)【AICC解决方案版本】【必填】   AICC 8.12.0【期望解决时间】2023/11/08【问题现象描述】【必填】     同asr交互过程中同时识别按键，也可以打断识别

先明确智能硬件中声学（麦克风）使用的三个场景，避免简单的问题复杂化。第一个场景，通话使用。这是大部分智能硬件设计麦克风的主要原因，很多声学做起来感觉很简单的错觉也来源于此。第二个场景，较安静环境下人机交互。复用第一个场景的声学硬件，第二个场景马马虎虎也能用，虽然部分情况下效果不理想，但是，还没到完全不能用的状态。第三个场景，高噪环境下人机交互。主要是户外和人流量较多的环境下使用人机交互，第一个场景的声学硬件完全不能使用。对于第一个场景，通话使用，现在的主流芯片基本上已经内置了通话降噪算法，再加上绝大部分通话都是在安静场景下，因此，只要麦克风的性能指标不是太拉跨、电路设计没有硬伤，第一个场景中智能硬件的声学部分并不用做额外的测试。但是，很多开发者带着这样的惯性开发第二个和第三个场景的智能硬件时，就完全走不通了，售后问题比比皆是，基本都集中在声音处理上。那么，对于第二个和第三个场景，应该如何科学地自测声学部分呢？怎么判断声学部分是否符合量产条件呢？下面分享声学自测的规范。测试环境准备：环境安静，噪音<40dB,如无条件，选安静会议室设备周围无遮挡物测试工具准备：待测设备---预留50MB存储空间专业声压计--- 条件有限可使用手机app(例:手机应用市场-- Sound Meter HD)音频分析软件---Audition高保真音箱---条件有限可使用蓝牙音箱,无蓝牙音箱可使用电脑密封材料---淘宝购买 EVA海绵密封胶带10mm厚度测试音频准备：密封性测试音频(白噪声)1khz音频信号质量测试音频测试附件准备：单独提供测试记录表格《声学测试结果目标》测试音频附件测试方法一、自播自录制测试1-10项测试只录制一个音频：（1）设备调节到100%音量（2）设备先开始录制音频并保存，然后设备播放信号质量测试音频(3) 自播自录后，人正常说话，测试mic处人声音量为65db，保存原始音频和识别音频1、mic和回采幅度检查最低幅度检查1.用Audition软件打开音频，检查采样值。识别引擎要求采样值>2k，确保mic处65db人正常说话时峰值振幅采样值>2k。否则需要提高mic增益截幅检查检查每个声道振幅最大部分，确保每个声道无截幅鼠标中间放大波形,保证波形连续,且无削顶整改方式：减小增益或降低最大音量，让设备最大音量播放歌曲时，音频不截幅2、幅度一致性（单麦免测）（1）确保所有mic声道的幅度均值差值≤3db示例：1声道（-12db ），2声道（-9db），相差3db合格（2）回采的增益不能太小,最大音量时在[-1,-9] DBFS之间（3）双回采平均幅度差≤3db3、通道顺序稳定性检查多次录音, 同一个mic对应软件中的声道要固定。可以多次录音按相同顺序用手轻触麦克风，录音上会有比较明显的振幅，检查多次录音的麦序4、底噪检查（1）不播放音乐时,回采底噪<-65dbfs安静环境下,设备底噪 < -50dbfs操作方法:最右侧数字区域鼠标右键选择Decibels（2）运行时底噪检查（设备运行时自噪较大的设备才需要测，比如投影仪运行时有风扇噪声，扫地机工作时的噪声，其他免测。）让设备运行应用，使cpu占用>70%， 此时用声压计测量mic处噪声≤50db5、丢数据检查查看音频的长度（Duration）是否为21.6秒丢数据可能原因:(1)重采样算法异常(2)驱动异常2.在频谱上找一竖一竖的地方， 看时域波形采样点是否减少，如下图的频域波形，对应的时域少了5个采样点6、最大音量检查设备最大音量播放音频进行测试。AEC算法消除量为30db左右, 建议麦克风口处最大音量<=85dB,打断唤醒效果较好特殊场景,例如全双工, 建议麦克风口处最大音量<=75db,打断唤醒效果较好7、回采信号检查（1）回采信号提前于mic信号，时间差<80ms（2）每次录制时，回采和MIC时延差稳定（3）回采与原信号波形基本一致,无畸变（4）回采不能截幅反例： （1）回采比MIC慢（2）回采和MIC信号的时间差太长（3）电视盒子外接电视的喇叭，时延差不可控，效果会受很大的影响8、波形失真原因：音量太大导致失真质量测试音频原始波形（下图）设备回采波形失真（下图）注:轻微型波形失真也算失真9、单双回采检查如果有2个喇叭，2回采信号效果更好10、喇叭主观听感测试方法：最大音量播放0dB 20Hz-20kHz的扫描信号，有无POP噪声/失真感/破音/共振音/杂音11、麦克风阵列角度检查二、相位一致性检查（单麦免测）正常情况：麦克风同一时刻的相位一致（波形一致）回采同一时刻可以一致或者反向检查方法：找原始音频正弦波的位置进行检查异常情况三、密封性和通道顺序测试1、录制音频     1.音箱和待测设备距离20~30cm 2.音箱播放，调节音量使待测设备麦克风（Mic）处音量为80~90dB（估算）     3.设备录音并保存文件，命名为 sealing_test.pcm      4.使用EVA海绵胶带10mm厚度（淘宝可购买）按逆时针顺序逐个密封mic，密封后停顿5~10秒，然后换下一个mic堵住继续该操作至结束。2、 导入音频文件1.结束录音，导出录音文件,确保格式为wav。2.拖动文件到audition软件中,根据设备情况选择采样率和声道数由于白噪声能量较高，可以清楚看到被堵mic的频段，同时也能看到mic的顺序。如下图所示，实际mic顺序和测试顺序一致，时域谱中每个通道振幅明显较大的部分（或者频域谱中每个通道中暗的部分）即为被堵住mic的部分。3.、对比声道振幅      1.单击鼠标左键不松开,拖动选择区域后松开鼠标左键, 选中声道1中堵住mic停顿5s~10s区间的部分        注意:在选择扫描选区的时候，请选择停顿 5~10s 的中间的平坦部分，不要将有信号残留的部分选中，这部分会影响最后的结果！     2.依次点击窗口(Window),振幅统计(Amplitude Statistics),扫描选区(Scan Selection)    3.查看平均RMS振幅(Average RMS Amplitude)，声道1密封 -57.26dB，其他声道未密封为-28dB，差值30dB>气密标准10dB，单声道气密性合格。要求设备所有mic气密性合格反例：第2和第6声道气密性不合格四、算法效果测试使用降噪测试工具处理保存的质量测试音频，检查降噪后的音频回声残留量，残留噪声低于-30dbfs以上，是整个声学部分自测的全部流程。

我们先讲一下智能硬件做语音识别的基本链路：声音（目标声音和噪音）一起被智能硬件的麦克风（阵列）采集到，在智能硬件的芯片上通过预处理之后，然后再送往云端进行ASR（语音转文字）。而很多智能硬件识别效果不好的主要原因是因为预处理，也就是声学处理没有做好，才导致识别效果不好。就像人耳朵一样，没听清楚讲话内容，可不得乱猜一通！现在，云端的语音识别（ASR）可以通过SDK/API进行调用，大厂提供的识别接口背后所使用的算法和效果基本都差不多。毕竟，开源算法和大数据训练一起结合，在安静场景下，或者说送给云端一段干净的音频，准确率保持在98%以上都没有任何问题。识别效果不好，问题出就出在了声学处理上。如果声学处理没有做好，送给云端的就是一段带噪声的音频，如果是人与人通话还好，毕竟人的判别能力很强。但如果给语音识别算法来处理噪声没有处理好的音频，输出的结果就会差强人意，而且，即便如何优化云端识别算法，像热词、大模型下打小模型这些做法，依然不能有效优化识别的准确率。那要如何才能做好智能硬件的声学处理呢？首先，我们要了解，麦克风（阵列）采集到的声音里面都有那些音源。从组成类型来看，包括：目标人声音：希望提出出来转成文字的语音，越干净越好，专业术语是信噪比（SNR）越高越好，至少5dB及以上；混响声音：主要是在室内，目标人讲话的声音通过墙壁、地板、天花板等反弹之后的声音，类似山谷里面的回声；背景音：目标人所在环境的一些噪音，如室外的鸣笛声、风噪、行人交谈声音；室内常见的是电视播放的声音、风扇空调工作声音等等；设备自发声：如音箱播放的音乐声，机器人的语音播报声等等。然后，根据不同的类型音源，就需要采用不同的算法来进行处理。设备自发声，可以通过回声消除算法来进行解决，通过设计硬回采电路，把喇叭的声音连回麦克风，叠加相反的波形实现设备自发声的消除。不过，要想回声消除效果好，在做结构设计的时候，建议喇叭和麦克风离得越远越好。部分芯片支持软回采，也就是硬件方案上不用单独设计回采电路，不过，从效果上来看，硬回采优于软回采。混响声音，可以通过去混响算法进行解决。一般来说，基本的去混响算法就可以达到不错的效果，不过，对于一些复杂的环境，去混响的算法尽可能在实际场景中进行实验和调试，以保证最佳效果。还要注意的是，去混响之后，对本身音频也会产生副作用，如失真或声音质量降低，这些不利的影响也要纳入整体效果的考虑中来。背景音，就需要用到预处理中的最重要的降噪算法了。降噪一般分为通话降噪和环境降噪，最简单的区分是通话降噪后的音频是给人听的，环境降噪后的音频是喂给语音识别模型的。人的判断力远远强于语音识别模型，因此，环境降噪的要求比通话降噪高得多。但是，越难的地方也越容易被应付，很多智能硬件的项目，要么觉得降噪不重要，要么觉得做降噪的时间成本和金钱成本都太高而应付了事，最终，却因为产品效果之后售后投诉太多反而得不偿失。那么，要怎么样才能做好降噪呢？从工程和产品来说，要做好以下三件事：第一件事，确定场景和要求。比方说，主要使用的场景是哪里，室内和室外所要面临的降噪要求就完全不同。同时，还要确定要求有多高，是近场交互还是远场交互，需要多少颗麦克风的阵列，理论上讲，麦克风的数量越多，对芯片的算力要求越高，产品的成本也就越高，成本太高是否要向利润妥协，产品的目标用户能支持多高的价格区间等等，这些都是需要在项目立项的时候有基本的数据指标。第二件事，找算法原厂沟通。一定要找算法原厂沟通，用芯片自带或者降噪模组，最后的理想的结果就是产品能用但不那么好用，甚至很多产品量产后根本就没办法用。硬件项目的周期一般小则半年，长则二三年，因为降噪的原因而失败就得不偿失了。最最关键的是，降噪效果还不能后期通过软件OTA来进行升级，因为之前做ID设计和硬件设计的时候，降噪效果的天花板就已经确定了，算法如何调优都是徒劳。找算法原厂沟通，了解清楚麦间距、性能指标、芯片算力占用情况、功耗、适配周期、麦克风喇叭选型指标、硬件结构设计细节规范等等，才能真正保证后期产品的使用效果。第三件事，实验室系统测试。没有测试就投产绝对是在搞破坏，声学这一块，同样需要进行系统科学的测试，评估满足量产标准后再进行量产，否则就应该按照测试结果进行整改。实在无法整改的部分，与算法原厂沟通性能恶化情况，可接受范围内可继续量产，不可接受范围内，一定要及时叫停进行整改。否则，一旦量产后，就再无回头路可言。而声学方面，实验室系统测试的数据，包括以下部分：麦克风：频率响应、底噪、灵敏度、信噪比、总谐波失真、密封性、阵列频响一致性等喇叭测试：频率响应、总谐波失真、R&B、灵敏度等。当然，有些指标不需要到实验室测试，自测也能发现问题。

【问题来源】百信银行【问题简要】调用icd 座席修改接口【问题类别】智能外呼 ICD 技能队列、CCBCS【AICC解决方案版本】ICD V300R008C25 CCBCS【问题现象描述】调用icd 座席修改接口ccbcs／rs/agents／modify／｛ccid｝／｛vdnid｝／｛agentid｝这个接口本地调试‘返回120620不知道该错误码对应什么含义  可否提供全部错误码列表并且想问一下 此接口是否可以修改 技能队列和座席的对应关系感谢

【问题来源】百信银行【问题简要】调用icd 座席修改接口【问题类别】智能外呼 ICD 技能队列、CCBCS【AICC解决方案版本】ICD V300R008C25 CCBCS【问题现象描述】调用icd 座席修改接口ccbcs／rs/agents／modify／｛ccid｝／｛vdnid｝／｛agentid｝这个接口本地调试‘返回120612不知道该错误码对应什么含义  可否提供全部错误码列表并且想问一下 此接口是否可以修改 技能队列和座席的对应关系感谢

【问题来源】百信银行【问题简要】GUID 动态鉴权方式 签入报错【问题类别】AICC【AICC解决方案版本】AICC解决方案开发指南22.100.0 【问题现象描述】GUID 动态鉴权方式 签入报错https://ip：port／agentgateway／resource／onlineagent／agentid调用上述接口 PUT 方法 使用mainTest 工具类 或者 httpProxyHelper 工具类一致报错000-003   no right to invite resource 没有任何思路并且查询了环境日志 agentway－rest.log message=success retCode=0不知道怎么去解决，agentid 、 password、num 填写都是对的

调用icd 技能队列创建接口 总是返回12005 配置项校验失败，想问配置指的是什么 如何接口调通请求头中的authorization token已经正确获取uri /ccbcs/rs/skillqueues/add/1/1/新增idjson 传入的是 示例 请求报文 json

【问题来源】百信银行【问题简要】调用icd 技能队列创建接口 总是返回12005 配置项校验失败，想问配置指的是什么 如何接口调通【问题类别】智能外呼 ICD 技能队列、CCBCS【AICC解决方案版本】ICD V300R008C25 CCBCS【问题现象描述】调用icd 技能队列创建接口 总是返回12005 配置项校验失败，想问配置指的是什么 如何接口调通请求头中的authorization token已经正确获取uri /ccbcs/rs/skillqueues/add/1/1/新增idjson 传入的是 示例 请求报文 json

盘古大模型要如何提交申请，为什么不让我申请？我这个账号是通过了企业认证的。现在提交申请的时候提示：账号受限，请切换账号，或申请解除受限。处理完成后请重新登录刷新。麻烦帮我看看，感谢！

主要用于分析行情数据，购买哪一款比较好。

中午我在思考一个问题，既然华为自己的盘古大模型开发出来之后，有没有机会能服务到我们的c端用户呢？眼看鸿蒙3.0已经逐渐走向成熟，但是我还是感觉给用户带来的震撼不够。用户需要ai加持，这是必然的趋势不是吗？可能在语言回复功能上胡说八道的可能性还是会有，但是我觉得可以先从特定的几个方向研究，比如已经成熟的AI1.0的小艺小艺，我觉得可以适当的加持部分功能，比如天气预警，事务提醒，外卖点餐等，以及多维度得思维辨析，都是可能带来不一样得感觉的。这是我对移动端得感想，再来谈谈我对智能家居得看法。我还记得华为得万物互联当时给我带来的震撼，无与伦比，这真的是对于真正互联网技术得顶尖理解，才能做出这样得伟大壮举，但是，大模型时代已经到来，万物互联的时代真正要来临了。可以单卡即可运行得模型并非没有，在微调得当得情况之下，难道，智能家居与大模型结合得方法还会没有吗？智能加持得智能床，随时传输给大模型数据，实时关注身体健康，可以及时预警。智能加持得智能房间，随时关注天气变化，实时帮助我们开关窗帘，提醒出门带伞等等等等，能大模型加持得地方太多太多，根本想不过来。如果可以，我更希望大模型对于教育不均衡地区得孩子们带来的意义更大，这就是科技得初衷不是吗？

问题来源】  内蒙银行项目【问题简要】  在IVR中需要将随路数据赋值到一个变量了，例如userdata {key1:value1,key2:value2,key3:value3.....}【问题类别】UAP、IVR【AICC解决方案版本】【AICC可选择版本：AICC 8.15.1.SPC3】【UAP可选择版本：UAP9600 V100R005C00SPC028】【CTI可选择版本：ICD V300R008C23SPC005】【期望解决时间】 9月9日【问题现象描述】方案咨询类问题【截图信息】赋值变量：日志中ani取值不是aani的value, 日志如下：怎样能得到：userdata {ani:88880009,.....}