大模型使用中遇到的坑——HTTP query 参数探讨

大模型就像是一个无所不知的助手，给它的任何任务都可以快速的完成。通过收集一些和大模型交互过程中不符合预期的案例，既可以提升和大模型的协作效率，也可以对自己的知识进行检验。
最近遇到的一个案例是，需要提供一个HTTP服务的接口，同事使用大模型给出的接口定义示例是：

1. GET /path?a=1&b=2&a=2&a=3

复制代码

这里的问题，在query参数中出现了a的多次赋值。这个接口很可能是大模型结合代码中实际使用的服务框架给出来的，服务框架中对query参数重复时，可能会返回所有的值而非第一个或者最后一个。本文章就对HTTP的query参数进行说明吧。
协议约定

HTTP的结构在rfc3986#page-16中约定如下所示，query部分，也就是URI中?之后、#之前的这部分，则是我们要关注的。但是在[rfc3968]中没有进一步的对qeury的约定。

1.   foo://example.com:8042/over/there?name=ferret#nose
2.   \_/   \______________/\_________/ \_________/ \__/
3.    |           |            |            |        |
4. scheme     authority       path        query   fragment
5.    |   _____________________|__
6.   / \ /                        \
7.   urn:example:animal:ferret:nose

复制代码

对HTTP/1.1的约定则可以在rfc7230中找到，其中定义的HTTP协议如下的（1）所示。通过对HTTP-message继续拆解，本次我们关注的query则是在request-target部分。

1. （1）
2. HTTP-message   = start-line
3.                  *( header-field CRLF )
4.                  CRLF
5.                  [ message-body ]
7. （2）
8. start-line     = request-line / status-line
10. （3）
11. request-line   = method SP request-target SP HTTP-version CRLF
13. （4）
14. +---------+-------------------------------------------------+-------+
15. | Method  | Description                                     | Sec.  |
16. +---------+-------------------------------------------------+-------+
17. | GET     | Transfer a current representation of the target | 4.3.1 |
18. |         | resource.                                       |       |
19. | HEAD    | Same as GET, but only transfer the status line  | 4.3.2 |
20. |         | and header section.                             |       |
21. | POST    | Perform resource-specific processing on the     | 4.3.3 |
22. |         | request payload.                                |       |
23. | PUT     | Replace all current representations of the      | 4.3.4 |
24. |         | target resource with the request payload.       |       |
25. | DELETE  | Remove all current representations of the       | 4.3.5 |
26. |         | target resource.                                |       |
27. | CONNECT | Establish a tunnel to the server identified by  | 4.3.6 |
28. |         | the target resource.                            |       |
29. | OPTIONS | Describe the communication options for the      | 4.3.7 |
30. |         | target resource.                                |       |
31. | TRACE   | Perform a message loop-back test along the path | 4.3.8 |
32. |         | to the target resource.                         |       |
33. +---------+-------------------------------------------------+-------+
35. （5）
36. request-target = origin-form
37.                / absolute-form
38.                / authority-form
39.                / asterisk-form
40.                
41. （6）
42. origin-form    = absolute-path [ "?" query ]
44. 请求 http://www.example.org/where?q=now 的 HTTP-message 为：
45. GET /where?q=now HTTP/1.1
46. Host: www.example.org

复制代码

对request-target部分在定义在rfc7230#5.3，这里列举了四种request-target类型。一般业务使用时填充的是origin-form，在设置了代理的情况下会使用absolute-form。
这里的问题是，HTTP原始约定中没有对query的格式进行约定。query的具体解析方式依赖于http-server的具体实现，这就会产生一些细微的差异。
http-server 实现

通过大模型的汇总，常见的处理模式如下：
处理方式示例典型框架最后值优先a=1&a=2 → a=2PHP（默认）、Express.js第一值优先a=1&a=2 → a=1较少见数组/列表a=1&a=2 → a=[1, 2]Python、Ruby、Java Spring合并为字符串a=1&a=2 → a="1,2"某些旧系统报错返回 400 Bad Request严格验证的 API可以看到，具体的语言、框架可能对query中重复参数的处理不同。
影响

这个重复参数的接口约定没有实际使用，我们最终采取了POST+json request body的方式来约定了一版新的接口，使用了更为确定且清晰的约定。假设使用了大模型给出的原始版本，可能客户端的大模型会按照接口的约定来设定请求、服务端的大模型大模型按照接口的约定来进行处理。假设未来对这个服务的接口进行重构，新的语言/框架对于重复参数仅取最后一个值，而客户端感知不到这一变更，这就会产生功能上的混淆。
或许在使用大模型进行编程时，至少需要对接口的约定进行详尽的沟通，或者让大模型判断下潜在的兼容性影响。可能添加一些SKILL会好一些。大模型使用带来的一个影响是代码量的膨胀、服务数量的膨胀，在宏观角度下、大模型的SKILL不完全相同，一些细微的概念或者约定的差异可能就会给系统带来影响。又或者，未来程序员需要维护大模型的统一SKILL，其他的agent则在这一共享SKILL的共识下进行协作。

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！