@brianinzz 我们也是搞了一个大宽表，在数据资产的建设上下功夫

@goodryb 确实，当前准确性是 AI 在 BI 领域面临的比较大的挑战，数据问答层面，能选择到正确的数据来源是第一个要面临的问题

@levelworm 哈哈哈哈，我倒也想，目前 ai 在 BI 领域最大的难题就是准确性问题或者信任问题，这块恰恰是 BI 最看重的问题

@red13 是的，如何把复杂的业务逻辑和关系型数据库中的库表之间的联系建立起来是个问题

@irockytan 首先感谢大佬的恢复，第一条路目前在研究这个，通过比较详细的 table schema 信息+相似问题的输出 sql 来一起给到 LLM 。第二条之前确实没有怎么考虑，这个我研究研究

@neptuno 大佬你的想法应该和下面 yrzs 提出的类似？

@lambdaq 就是问过了，然后感觉还是不太清晰，wwwww

@FriedRiceNoodles 感谢，我研究一下

@Depth 感谢 我看下一下

@yrzs 其实还一点困惑在于，sever 返回的 tools 列表，其中关于 input_schema 是不是没有严格要求，只要能返回 name, description 还有 inputSchema 的三元组就可以了，具体 inputSchema 的组织形式没有严格定义。因为还没看过 mcp 协议的原始论文规范，所以这一块有点模糊。

@Tink 看了 openManus 中关于 client 端的调用实现以及官方给的使用示例( https://modelcontextprotocol.io/quickstart/client)， 其实就是 client 向 server 查询 list_tools ，然后把这些 tools 转换成了 LLM 调用时的 tool 列表。对于不同的 LLM 模型，可能要自己做 adapter

@yrzs 这个是 client 调用 server 进行执行 tool 的时候么，这个我倒可以理解； mcp server 不是还要支持 toolList 这种的获取么，这种是如何把我们项目中的接口转换成 mcp server 认为的 tools 的呢

@superliy 我们这里是有专门的团队来维护开发，同类型的用的比较少，pg/ck 等只是简单的用过几次，没法给出对比

@Jim2Chen 有空了写个文章分享下，目前整理的方案和公司的数据结合的比较多，不方便直接发，主要步骤就是：
1 、如何识别会话
通过窗口函数，计算相邻两次行为的时间间隔，按照规定的 sessionPeriod 切割会话
2 、识别会话后，如何实现路径的裁剪
通过窗口函数，找到路径的起始或者结束节点，然后进行一次裁剪
再次通过窗口函数，对每个会话的行为节点编号，进行一次深度上的裁剪
3 、最终返回给展示层的数据格式
这里有两种返回形式，一种是直接返回路径，然后业务层做计算，另一种是返回节点对之间的统计信息。可以根据业务需求自由选择

@Jim2Chen 用 4 层窗口函数实现了一个版本，但是查询性能感觉不是很好.. 4 个行为，13E 数据要 30s

@levelworm 大佬搞出来了吗，我用 4 层的窗口函数写了一个版本，但是性能比较差...

手抖点错了，删掉删掉

@leimu012 什么公司，让兄弟们避避坑

@Duanpei 这个确实，领导还会觉得你很重要...