Teng Tu

好嘞 那稍等我一会儿

> 赞同Keldos说的～ 感谢你的工作！不过，我clone了你的代码，并没有发现有改动诶，是还没push到GitHub上吗？ 因为我的代码风格很糟糕，所以还没有push ~

因为近期代码进行了很大的重构工作，而我的开发基于4天前的版本，merge恐怕会有较多conflict，所以麻烦再给我一点点时间~

来检查作业吧~，我的api-key不知道为什么不好使了，所以今天就写到这了

1. 我并没能复现出这个报错，这个报错看起来是chunk解析问题？我没有改动这块的代码，不知是否是网络问题或没有填写api_key 2. 事实上，这些改动并没有“真的改”，均可以通过命令行参数复原，也可以通过修改argparser的默认值来复原 3. 本身预计修改的“History and chatbot have some repetitions”“The function of summarizing the text”在master分支中已经有了很好的实现，所以不再需要改动 4. 接下去还会实现一个log功能，自动地记录每次对话的全过程以备部署者查看。(这主要是由于预期的应用场景不同，您们的项目旨在为所有拥有 api-key 的用户提供 WebUI 服务，我更倾向于提供给有api-key的人部署后分享给不拥有 api-key 的朋友使用）该功能也将可以由命令行参数来决定是否开启 5. 关于如何merge，我的建议是这样的： i. 我修改argparse的默认值，使其在默认情况下不对master做任何变动 ii. 您们挑选一些确实有必要的功能,...

关于token超出上限的情况这里给出另一套实现思路： 1. 在predict函数中，首先统计history的长度，如果history超出某一个上限~3000，那么先行进行精简 2. 非流式地生成精简结果后，从头扫描一遍history，直到token达到~2000，删除这部分history，并以固定地Prompt替换： > user：[ChatGPT刚刚给出的结果]（刚刚我们谈到了……），你了解了吗？ > assistant: 我了解了。 > user: [原来的2000~3000聊天内容] 相比原来的实现，具有以下优势： 1. 更加稳定，当前情况下，是在生成后再精简，如果用户本段token太长，除非用户先手动精简，否则将在触发一次“error”后被动地触发精简，用户体验差。 2. 精简必将损失一些信息，用户对于最近的信息的精确性要求比聊天最开始的信息精确性要求更高 3. 利于用户继续进行追问，否则上一条信息中的细节将因精简而消失，且由于该精简为被动触发，用户完全没有机会避免。 古早版本代码的修改建议如下： ``` for index, data in enumerate(history): tmp = {}...

不好意思，麻烦您了，我之前没有开源社区的开发经验，我会好好学的 是说应该每个feature单开一个branch，写好之后提交PR，在通过后，如果需要继续修改，就再拉取master，checkout -b，再提PR这样对吗？ 另外，我没有特别理解这一部分： ``` 如果你有更多修改，请在你的仓库另建至少两个对应的分支，然后 > git reset --hard d759751 > git pull upstream -f tt/ui (或tt/argparse) 之后在对应分支上修改对应的功能需求（尽量原子化提交commit），然后在这里向对应的分支提交pull request。 ``` 前半部分是我该在我的仓库里做的，请问为什么是要回到 d759751 这个commit，是因为 tt/ui 是从这个commit上分出去的吗？ 后半部分“然后在这里向对应的分支提交pull request”是怎么做呢？我看PR里只能在一个仓库之内merge各个branch，可以大概告诉我一下该怎么做吗？另外，我现在完成了包括上述的log 和 精简token的修改，那么我是该：...

感谢耐心解答！最后这里我没太明白： ``` 在你的仓库里分别新建两个分支 从你的仓库直接提交PR到这个仓库的main，提交时选择你的仓库对应的分支。 ```  这里我好像并不能在提交PR是选择新的分支。 比如我有一个tuteng0915/ChuanhuChatGPT::tt/log，我该如何提交到GaiZhenbiao/Ch....GPT::tt/log呢？ 在GaiZhenbiao仓库里我该如何进行新建分支的操作？还是说我提交到我的其他分支比如tt/ui？

ok 我理解了，也是说： 如果我是这个项目的管理者，我该每做一个feature单开一个branch，然后项目内提PR merge到master。 我现在Fork了这个项目，那么我就在我的仓库里每做一个feature单开一个branch然后同样在这个项目内提PR merge到master 然后PR是针对branch而言的，而非commit，所以我在开着一个PR的情况下，在merge之前，是可以继续往里commit的

由于涉及的feat已悉数提交PR，close