Talk:LangChain

"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)

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)

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)

"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)

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)

@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)

I've condensed this section into one sentence and placed it in the lead.StereoFolic (talk) 13:51, 13 May 2023 (UTC)

"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)

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)

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)

The CrewAI Discord server Vitreology (talk) 10:55, 1 February 2024 (UTC)

Would you care to elaborate on this and the many other points I've made? How has this community found this more useful than the official docs, which list integrations much more thoroughly? What standards are we supposed to use to determine what goes in this table? How do we ensure the table is not Original Research, given every single source it cites is a primary source? StereoFolic (talk) 14:05, 1 February 2024 (UTC)

Since I haven't heard back, I've gone ahead and removed the table again. If you disagree I recommend seeking a third opinion by the process at WP:3O StereoFolic (talk) 03:42, 15 February 2024 (UTC)

3O: OR is the wrong angle to look at it from, in my opinion. The real reason for the OR rules to exist is verifiability, but I don't think that's an issue here.

That said, I'm weakly in favor of removing it. It reproduces some arbitrary subset of https://python.langchain.com/docs/integrations/providers/ (it's not clear to me how that subset is chosen, and it's not clear from the article alone that it is a subset) and I'm not sure it provides value over just linking to that page, or over the similar information in the prose section just above it. ℰmi1y_⧼T·C⧽ 22:16, 16 February 2024 (UTC)

Your view on the OR angle makes sense to me, thanks. These other points are things I've raised above, but the other editor has repeatedly declined to engage with. Vitreology, can you please help us resolve these concerns? StereoFolic (talk) 12:34, 17 February 2024 (UTC)

It is not an arbitrary subset of the langchain tools, I went through every one of the tools published on the langchain site to summarise the points for all of them. This table is an invaluable quick reference guide and there is not currently any way to filter langchain tools by particular characteristics, besides this table. It is a starting point not an endpoint and I encourage all authors to build upon it in a constructive manner to make it even more useful and practical that it already is. Thank you Vitreology (talk) 13:20, 17 February 2024 (UTC)

"I went through every one of the tools published on the langchain site to summarise the points for all of them." - There are over 200 integrations, and this table lists about 60. And still, you are not addressing any of the other concerns we're raising. If LangChain needs to improve their integration discoverability, they should do so. It's not Wikipedia's job to substitute for disorganized documentation. StereoFolic (talk) 14:23, 17 February 2024 (UTC)

If you want to add a comprehensive table describing all 200 integrations with their licenses and key access requirements, you are free to open a pull request on the docs directly. StereoFolic (talk) 14:28, 17 February 2024 (UTC)

Introductory sentence is ambiguous

The first sentence in the article can be interpreted in two ways: "LangChain is a framework designed to simplify the creation of applications using large language models (LLMs)."

Does it simplify the creation of applications that use LLMs or creation of applications by using LLMs in development. 2001:999:250:D56B:C76:3131:D5BC:2837 (talk) 20:49, 24 September 2024 (UTC)

Yeah, that wasn't clear before. You are correct, it is a framework for software that uses LLMs, not a tool for having an LLM build your app for you. I did a little follow-up editing from your change in this direction, and I think it's in a better state now. Thanks! StereoFolic (talk) 19:38, 28 September 2024 (UTC)