Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Jump to content

Talk:LangChain

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Vitreology (talk | contribs) at 10:55, 1 February 2024 ("LangChain tools" table: Reply). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

"Use" section possibly redundant

In its current state the "Use" section seems largely redundant with the lead and the definition of a "software development framework". Maybe it should be removed unless/until more secondary sources expound on use-cases and development patterns that aren't standard integration framework fare. I think it's probably appropriate to treat this article much like any other integration framework, like Apache Camel or OpenESB. StereoFolic (talk) 16:12, 18 April 2023 (UTC)[reply]

Please keep it for now. I'm hoping to expand it with more developer-focused overview info, once I get some more experience with it myself. Sandizer (talk) 16:25, 18 April 2023 (UTC)[reply]
After having tried to use LangChain and found it considerably more difficult than doing identical work without it, I no longer have an opinion on this one way or the other. Sandizer (talk) 11:27, 13 May 2023 (UTC)[reply]

"Use Cases" overlap with AI in general

Coincidentally related to the above thread, User:Tensieal I think the new "Use Cases" section may need a rework or deletion. Since LangChain is just an Large Language Model oriented integration framework its use cases are necessarily almost identical with LLM use cases. These use cases are also already apparent in the "Integrations" section. StereoFolic (talk) 03:34, 6 May 2023 (UTC)[reply]

And for context to other editors, I've just seen that User:Tensieal is a paid editor on behalf of ActiveLoop, the sole non-primary source added in this section. StereoFolic (talk) 03:36, 6 May 2023 (UTC)[reply]
@StereoFolic, I see your point regarding the LLM use cases, but I feel like it's important to address how the framework can be used beyond "oh you can connect LLMs to memory and do some operations on top". Tensieal (talk) 03:40, 6 May 2023 (UTC)[reply]
I've condensed this section into one sentence and placed it in the lead.StereoFolic (talk) 13:51, 13 May 2023 (UTC)[reply]

"LangChain tools" table

@Vitreology, I see that you do not agree with my rationale that the integrations table does not belong in this article, so I will explain further without reverting it myself, and put the discussion here so others can weigh in. LangChain supports over 200 integrations, and frequently adds more, so I think we can agree it would be excessive to include all of them in the article. It is unclear to me what standard is being used to determine what goes in the table. As it stood before, the article already mentioned quite a few integrations so readers can get an idea of the sort of integrations available. This article is not a substitute for the official documentation, so it is unclear to me what benefit is offered by listing even more integrations in a massive table that dominates the article's size when readers can instead visit the full official integrations listing.

My main concern with including the table is maintainability - such a large table includes many data points that will drift with time and quickly become out of date. Even going through it and verifying it once would take considerable time, and would involve looking almost exclusively at primary sources, which feels like original research. If there was a clear benefit to including the table, this could be worthwhile, but again I don't see how this could be a substitute for readers going directly to the docs, so I struggle to see the upside.

Last, I will briefly mention that my decision to revert the additions was textbook BRD practice, and to describe it is as 'bordering on vandalism' and cautioning me against warring is unnecessarily combative and not assuming good faith. I understand it's frustrating to spend so much time on work that ends up not panning out, but that's just inevitable on a collaborative project like Wikipedia. If you had raised this idea on this Talk page before going ahead, we could have discussed this earlier. You didn't go that route, and that's fine, but it comes with the risk of BRD, which is also very normal. Cheers - StereoFolic (talk) 00:38, 31 January 2024 (UTC)[reply]

Thank you, @StereoFolic, for sharing your perspective. I appreciate your concerns about the maintainability and relevance of the LangChain integrations table in our Wikipedia article. However, I would like to draw attention to the significant practical value this table offers, as evidenced by the positive feedback from numerous developers. This aligns with Wikipedia's policy of providing verifiable and notable information, as stated in Wikipedia:Verifiability and Wikipedia:Notability.
The inclusion criteria for the table are directly linked to the integrations listed in the official LangChain documentation, ensuring the table's relevance and accuracy, in line with Wikipedia's Wikipedia:Reliable sources policy. This table saves time and effort for those seeking a concise summary of available tools, which is not readily available elsewhere.
Addressing the maintainability concern, I propose a collaborative approach to regularly update the table, following the guidelines of Wikipedia:Maintenance. Such community-driven efforts are a cornerstone of Wikipedia's model, as outlined in Wikipedia:Community portal. I encourage fellow editors to contribute by adding tools not currently listed, thus making the table a dynamic and evolving resource.
Regarding the application of the BRD (Bold, Revert, Discuss) policy, while I understand its necessity, the positive response from the developer community suggests that the table is more than just a mere list; it's a valued resource. This situation presents an opportunity for us to reflect on the Wikipedia:Consensus policy, ensuring that our decisions are in the best interest of all users.
In conclusion, I advocate for a balanced approach that considers both the utility of the table and the principles of Wikipedia's policies. Our collective goal should be to enhance the article's value for our readers, in line with Wikipedia's mission of providing accessible and accurate information. I hope we can engage in a constructive dialogue to find the best way forward, respecting each other's contributions and viewpoints in the spirit of Wikipedia's Wikipedia:Assume good faith guideline.
Kind regards, Vitreology (talk) 03:24, 31 January 2024 (UTC)[reply]
I don't understand your argument. "However, I would like to draw attention to the significant practical value this table offers, as evidenced by the positive feedback from numerous developers" - what feedback and what developers? This table was just added and as far as I can tell the only feedback has been mine. Your second paragraph does not actually answer the question of how you are choosing which integrations to include or not. Your third paragraph is very generic and not helpful at demonstrating how we could keep this up to date, and does not address OR concerns. In your fourth paragraph, you again repeat the strange claim that there has been a "positive response from the developer community". StereoFolic (talk) 12:10, 31 January 2024 (UTC)[reply]
The CrewAI Discord server Vitreology (talk) 10:55, 1 February 2024 (UTC)[reply]