大模型量化 是一种模型压缩技术，其核心思想是使用更低精度的数据类型（如8位整数INT8）来表示和计算原本更高精度的数据类型（如32位浮点数FP32或16位浮点数BF16/FP16）的模型参数和激活值。目前发现不使用4字节FP32精度转而使用2字节FP16半精度可以获得几乎相同的推理结果,这样就可以部署在存储空间不大,计算速度不快的设备上了(如手机,嵌入式设备,边缘计算);如果每个参数占的字节数少点

生成包含工具调用的消息(如tool_calls: [{“name”: “add”, “args”: {“a”:3, “b”:4}, “id”: “call_1”}]）。判断要不要调用工具 若需要调用工具, 则进入tool_node节点, 执行工具,messages追加 工具消息ToolMessage , 并更新状态。此时状态更新为messages追加模型消息(除了用户消息, 系统消息 还有大模型第

网上说, 这个可以做成一个agent更简单,我还不会,下一篇就学一下怎么弄agent。先 安装模型插件,然后在设置中配置密钥和api;密钥需要去平台申请,要花钱的;本地模型安装Ollama和vllm, 还是花钱省事,安装大模型特别费劲。模型最好使用通义千问, 比较全,如果配置有问题,切换一下插件版本。主页面面板有四个table: 探索,工作室,知识库,工具。: 可以创建自己的应用,包括聊天助手,

流式 ASR:实时采集音频，按固定时长(200-500ms)切分「音频块」,每处理一个音频块，就输出增量更新的识别文本。FunASR实时输出有个特性 ：每次解码后输出「中间结果」（实时更新），静音时输出「最终结果」，完成一句话的识别闭环；非流式 ASR:麦克风采集到语音生成语音文件(wav/mp3),ASR模型读取语音文件,然后输出识别结果。核心技术是: ASR (语音识别)+ LLM (推理和内

LangChain:企业级 RAG 系统、适用于复杂场景（多数据源、多 LLM、Agent 集成）、二次开发需求高。RAG 原理： 检索（从知识库获取相关信息）→ 增强（将信息作为上下文输入模型）→ 生成（模型基于上下文回答）RAG策略下，Prompt的设计变得尤为重要。简洁性： 在保证明确性的前提下，Prompt应尽可能简洁明了，避免引入不必要的冗余信息。②Agentic RAG（智能体式 RA

参考: https://milvus.io/docs/zh/build-rag-with-milvus.md。demo中各个包版本, 当前python3.10(3.10兼容的包版本最多)嵌入式模型: bge-small-zh-v1.5从魔搭上下载。python 包版本是一个很大的坑。文档: 使用milvus中文文档。

NDCG@K（归一化折损累积增益）: 考虑 “片段相关性程度”（如 “非常相关”“一般相关”）和 “排名位置”，衡量排序的整体质量。召回率和精确率需要基于“标注数据集”—— 即提前为每个查询标注出 “所有相关的文档片段”,然后再对比检索结果和标注的匹配情况。单次检索耗时:从 “接收查询” 到 “返回 Top-K 片段” 的总时间;MRR（平均倒数排名）: 对多个查询，计算 “第一个相关片段的排名倒

自定义LLM需要继承 from langchain.llms.base import LLM。(我windows系统,本地chromadb无法执行下去,连报错都没有就结束了)直接调用豆包的API, 本地部署大模型太费电。文档向量化后存入数据库。整个demo工两个文件。

会给模型带来巨大的处理负担，使模型难以准确地捕捉和理解其中的关键内容，容易出现混淆和错误的关联，进而影响其对意图和槽位的准确识别和抽取。通过提示词设计，无需添加复杂的额外算法或模型架构，就可使 AI 智能体快速具备意图识别和槽位抽取能力。目的是需要智能体能够理解准确各种各样、形式各异但意思相近的问题,（比如方言类、反问语气、情绪化语气等），这就要求 LLM 节点得有很强的泛化和识别能力。但比较贵,

按照流程图, 使用add_edge 连接节点和节点,并行节点也使用add_edge,条件分支要使用add_conditional_edges。状态是一个类型化字典(TypedDict),用于存储各个节点的结果,加上输入问题 一共9个。全局的 “数据容器”, 用于在节点间传递信息（如上下文、工具结果、中间节点的结果数据)节点间的 “流转规则”, 决定了 “执行完当前节点后，下一步该去哪里”(节点0A