在使用 LLM(大语言模型) 调用工具方法时，可能会在运行时才会将类似 用户ID 的数值传递给工具。 大多数情况下，此类值不应由 LLM 控制。允许 LLM 控制 用户ID 可能会导致安全风险。 相反，LLM 应该只控制本应由 LLM 控制的工具参数，而其他参数（如用户ID）应由应用程序逻辑固定。 本文将向您展示：如何防止大模型生成某些工具参数并在运行时直接注入它们。 本文使用 llama3.1 和 MFDoom/deepseek-r1-tool-calling:7b 进行演练。 deepseek-r1 不支持 langchain 的 bind_tools 方法。 ...
本文将实践如何在 LLM(大语言模型) 调用工具函数时进行审核，即由人来确定是否应该调用工具函数。 本次使用 llama3.1 和 MFDoom/deepseek-r1-tool-calling:7b 进行演练。 deepseek-r1 不支持 langchain 的 bind_tools 方法。 ...
在使用 LLM(大语言模型) 时，经常需要调用一些自定义的工具方法完成特定的任务，比如：执行一些特殊算法、查询天气预报、旅游线路等。 很多大模型都具备使用这些工具方法的能力，Langchain 也为这些调用提供了便利。 之前的文章介绍了 llama3.1 与工具方法交互的实际例子，不过可惜 langchain 对 deepseek 支持还不够，导致： llm.bind_tools 根据用户问题生成的工具方法签名与 llama3.1 不同，在后续在调用工具方法时报错 deepseek 返回的结果中包含了思考过程内容，显然 Langchain 还不能正确解析出最终结果，这会导致 langchain 的很多方法不能正常运行 这次我们将尝试通过以下两种方法解决 Langchain 使用 deepseek 时产生的上述问题： 使用提示词让大模型推理调用工具的方法名称和参数 使用自定义的 JsonOutputParser 处理 deepseek 返回的信息 这里使用 llama3.1 和 deepseek 等不同模型做对比，并不是为了说明孰优孰劣，而是仅仅为了技术演示需要。 ...
某些模型能够进行工具方法调用：生成用户自定义的方法的签名并调用它。一般来说，此交互过程主要包含下面几个步骤： LLM(大语言模型) 根据用户的问题推理生成调用工具方法的名称和参数 调用工具，返回简单的结果 再次调用 LLM ，生成自然流畅的回答 下面我们来说明这一过程。 应该是因为 langchian 对 deepseek 的支持还完善，使用 deepseek-r1 无法生成工具方法签名，使用 MFDoom/deepseek-r1-tool-calling:7b 可以生成工具方法签名，但是在调用工具方法时不成功。 所以本文仅使用 llama3.1。 ...
本文将实现一个比较完善的聊天机器人的主要功能。包括： 使用 LangGraph 构建聊天机器人 自动裁剪聊天历史 管理聊天会话的方法 以流的方式输出回复 我们将同时使用 llama3.1 和 deepseek 做演示。由于 langchain 可能对不同大模型支持程度不同以及其它限制，所以这个对比并不能说明哪个模型更好。 ...